VPN od lokacije do lokacije: koji smjer zapravo treba pravilo?

Oba kraja prijavljuju uspostavljen tunel, udaljena podružnica odgovara sa gatewaya, a aplikacija i dalje ističe za korisnike na jednoj strani. Uobičajen savjet kaže da se doda firewall pravilo u oba smjera. Ponekad je to tačno, ponekad duplicira pravilo koje već postoji, a ponekad drugo pravilo kvari stanje. Koji slučaj vrijedi zavisi od toga gdje firewall vidi paket.

Povratni saobraćaj sa stanjem mijenja broj

Stateful firewall bilježi zahtjev i propušta odgovor bez drugog pravila, pa je dizajn kojem treba samo jedno pravilo normalan. Stateless pristupna lista nema takvu memoriju i odgovor se mora izričito dopustiti. Oba su ispravna na svojoj platformi, zbog čega se savjeti sukobljavaju.

Pročitajte dokumentaciju o prosljeđivanju za platformu pred sobom i provjerite je li politika koju uređujete stateful tamo gdje vidi paket. Izričito odbijanje uspostavljenog saobraćaja ili redoslijed pravila koji procjenjuje odgovor prije tablice stanja pretvara ispravan dizajn u zagonetan. Broj pravila je detalj implementacije, dok je zahtjev da se oba smjera dopuštenog razgovora mogu završiti.

Gdje firewall vidi dešifrirane pakete

U tunelu zasnovanom na politici firewall može procijeniti šifrirani paket prije dešifriranja, a dešifrirani paket poslije, na različitim interfejsima. Pravilo napisano za pogrešan interfejs prisutno je, ispravno i nikada se ne podudara. Tako skup pravila kopiran iz radne instalacije može zakazati na identičnom hardveru.

IPsec zasnovan na rutama i većina modernih implementacija predstavljaju tunelski interfejs, pa dešifrirani paket stiže tamo i primjenjuju se obična pravila interfejsa. Potvrdite koji model instalacija koristi prije nego što kopirate skup pravila iz vodiča napisanog za drugi. Tunelski interfejs je i mjesto na koje treba pogledati kada trebate znati je li paket uopće dešifriran.

Asimetrično rutiranje ruši pretpostavku

Stateful firewall pretpostavlja da vidi obje polovine razgovora. Ako se odgovor vrati kroz drugi gateway, taj uređaj ne drži stanje za zahtjev i odbacuje ga prema vlastitoj politici. Simptom je jednosmjerni kvar koji nijedno pravilo na strani pošiljaoca ne može popraviti. Pratite putanju odgovora prije nego što bilo šta izmijenite.

Provjerite rutu odgovora prije dodavanja širokog pravila dopuštanja na obje strane. Tolerisanje svega na svakom interfejsu skriva grešku rutiranja i istovremeno proširuje pristup, što je najgore moguće kombinacije.

Provjerite oba smjera sa stvarnim izvornim adresama

Testirajte adresom koju udaljena strana zaista vidi, jer prevođenje može učiniti da se pravilo izvora ne podudara ni sa čim. Pokrenite snimanje na oba gatewaya istovremeno.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Zahtjev koji se na udaljenom gatewayu pojavi s neočekivanom izvornom adresom objašnjava pravilo koje se nikada ne podudara, a odgovor koji stiže na pogrešan interfejs objašnjava nesklad stanja. Zatim testirajte jednu destinaciju unutar odobrenog obuhvata i jednu izvan njega, kako bi granica bila pokazana, a ne pretpostavljena.

Zabilježite izvornu adresu nakon prevođenja, interfejs koji je dešifrirani paket koristio i pravilo koje se podudarilo. Te tri činjenice odgovaraju na sljedeći tiket bez ponavljanja cijele istrage.