Established, related se neomezuje. Nemá to žádný smysl. Ty si jedním pravidlem povolíš navázaná spojení pokud přijdou z WAN a druhým pravidlem si povolíš vše co odchází přes WAN. To pravidlo se vlastně nemá šanci uplatnit, žádné takové spojení nebude, protože pak si to všechno zakážeš.
Princip má být (doma, či firmě) nejdřív povolit, pak zakázat. Čili obecně forward established,related accept. Forward accept in-interface LAN. forward drop.
Pokud tě napadnou povolovací pravidla, tak přijdou před ten drop. Ale vše co jde z vnitřku sítě je povolené sakumprásk.
Dobré je zakázat pakety ve stavu invalid.
Input máš správně. Co bys tam radši zakázal? Buď tu službu MK poskytuje a nejspíš ji z LAN budeš potřebovat a nebo neposkytuje a tím pádem není co zakazovat. Stejně je dobré se pojistit nastavením v ip/services (tím lze omezit přístup na všechny služby MK, kromě DNS a NTP).
Output drop? Čeho tím chceš dosáhnout? Zakázal jsi všechny pakety, co vznikají na tomto MK a chtějí odejít pryč ... To se nedělá, opět to nemá žádný smysl.
Myslím, že rady tohoto typu tu již byly asi stokrát.
Nezapomeň, že chainy input, output a forward jsou nezávislé. Paket co se objeví na inputu se nikdy neobjeví na forwardu. Atp.
Asi bych nepoužíval interface-list. Nějak cítím, že to není ideální řešení, že je to nějaký mikrotik výmysl. Stejně budeš mít doma jen dvě rozhraní ... wan a lan (lan bude switch, nebo bridge, nebo bridge ze dvou switchů).
U tplinku není nic. Ve výchozím stavu je to dokonce vypnuté.
Teorie, co je potřeba zakazovat, nebo dokonce jaký styl firewallu mít je vždy na dlouhé povídání. Nelze paušalizovat. Např. ve firmě bych byl podstatně tvrdší pro přístup stanic ven. Někdo omezuje pro jistotu zneužitelné služby (ssdp, chargen, qotd) a dokonce i povoluje jen některé ICMP. Jenže pokud budeš takto hodně omezující doma, tak budeš nejspíš hodně trpět a pak hledat co ti nefunguje.
