Kdyz se da vnitrni i vnejsi rozhrani do jednoho bridge, tak vznikne takovej stav, jako kdyby tam misto routeru byl obycejnej switch. Pokud navic zustal zapnutej dhcp server, tak se musi prat s dhcp serverem poskytovatele, protoze bridge udelal z vnitrni i vnejsi site jednu spolecnou sit. I kdyz vzhledem k tomu, ze je bliz a tudiz o chlup rychlejsi, tak ten dhcp server na routeru asi vyhraje. Pravidla ve firewallu pak postradaji smysl, protoze provoz pres bridge firewallem ve vychozim stavu vubec neprochazi (volitelne to jde zapnout). Takze soucasnej stav musi byt opravdu zajimavej a jestli to funguje, tak spis jen omylem. :)
Ja bych vrele doporucoval bridge zrusit a zacit znovu. A i kdyz je to kosmeticka zalezitost, zacal bych trosku inteligentnejsim pojmenovanim rozhrani. Mit wifinu, ktera dela vnitrni sit, pojmenovanou jako "WAN", pricemz pripojeni ven je ve skutecnosti pres eth1, proste neni vubec stastnej zacatek.
No a dal je to celkem jednoduchy. Pravidlo pro NAT bylo podle popisu spravne. Pokud to nefungovalo, tak RouterOS ma dostatek nastroju, pomoci kterych se da problem odhalit. Staci napr. na pocitaci na vnitrni siti spustit ping na libovolnou verejnou adresu (8.8.8.8 napriklad), a pak na routeru pomoci nastroje Torch zkontrolovat, ze pakety spravne behaj. Tj. na vnitrnim rozhrani musi byt videt prichazejici icmp pakety z vnitrni adresy pocitace na zadanou verejnou a na vnejsim pak uz znatovany, ktery budou mit jako zdrojovou adresu tu, kterou ma na vnejsim rozhrani router, tzn. tu 192.168.1.103. Pokud to tak bude, musi fungovat i vsechno ostatni. I kdyz teoreticky jsou mozny i dalsi scenare, napr. kdyby poskytovatel byl proti pripojeni vice zarizeni a hlidal si to podle ttl, ktery se pri pruchodu routerem meni. Ale nevim jestli jeste dneska nekdo takovy kraviny dela.
