jjrsk:
Odpověď jsem pročetl, promyslel a zkonfrontoval se svým nastavením. Zabývám se částí kdy pakety příchozí na wan mají dst je v interní síti (a ne src).
.a nesedí mi tam tvoje odpověď vše co má interní rozsah zahodit -- Pokud si dám pravidlo DROP na -d 192.168.1.0/24, tak defacto odříznu internet. Pokud dám -d 10.0.0.45 (adresa na routeru na wanu), toto pravidlo je tam uplně hluché(souzeno dle counterů )
On totiž conntrack v PREROUTING vrátí zpět natované adresy, takže už FORWARD u (všech spojení?) vidí interní adresy , ačkoli MASQUERADEP/SNAT je definován v POSTROUTING. (A drop nejde dát do prerouting, a do mangle se to taky nedává)
reálný výpis: (iptables -nvL FORWARD - výtah)
26 1560 DROP all -- * * 85.207.103.194
192.168.1.7
0 0 DROP all -- * * 85.207.103.194 10.1.0.42
Nebo jsem něco přehlédl? (pokud to nebude conntracku známé spojení, přepis se nekoná, ale stejně si takto odříznu kontektivitu) Simuloval jsem to spojením iniciovaným ze své sítě(klasicky curl 85....). Je možné, že pokud by mi 85.207... a záleží asi zase na pořadí pravidel...
řeší to tedy?
A FORWARD -d 192.168.1.0/24 -i waneth0 -o lan1 -m conntrack --ctstate !RELATED,!ESTABLISHED -j DROP (opět negované, za předpokladu P ACCEPT . Je to už správně?
Neřeším teď pakety co mají src interní rozsah (což to taky nechces), a navíc to řeší rp_filter. (akorát by mě zajímalo, jestli když mám k rp_filtru i odpovíjící pravidlo DROP v FORWARD, co účinkuje dřív: zda)
Možná jsem to nepředvedl, ale router(čistý linux) mám nastaven bezpečně, ale je to tím, že mám -P FORWARD DROP, takže pravidla diskutovaná nejsou 1:1, mají jiné pořadí, záměna ACCEPT-DROP, nevidím celý obrázek, všechna pravidla . Tady se diskutuje jen minimální příklad - jak zablokovat spojení s adresou obashující vnitřní síť na WAN. Ale s policy ACCEPT se to dá přepsat na komfortní ctstate ESTABLISHED -jACCEPT
64 Odpovědí
32920 Zhlédnutí