VPN ruta ili pravilo firewall-a: šta odbacuje paket?

Dvije nezavisne odluke donose se o istom paketu i svaka od njih može tiho prekinuti zahtjev. Pretraga rute bira interfejs i sljedeći hop, a zatim filter paketa odlučuje je li ta kombinacija dopuštena. Istek vremena vam kaže da je jedno od dva odbilo, ne koje. Prođite faze redom i popravak obično prestaje biti nagađanje.

Dvije odluke, jedan paket, dva vlasnika

Pretraga rute prvo konsultuje pravila politike, zatim tablicu na koju upućuju i bira najspecifičniji prefiks koji odgovara odredištu. Klijent koji je instalirao tunelsku rutu posjeduje tu odluku i ništa u pravilu firewall-a ne može je zamijeniti. Kada pretraga pokaže na neočekivano mjesto, svaka kasnija faza radi na pogrešnom paketu.

Filtriranje je odvojeno. Na Linux hostu netfilter kuke dijele saobraćaj prema tome za koga je paket: izlaz napušta mašinu, ulaz završava na njoj, prosljeđivanje prolazi kroz nju. Gateway koji prihvata VPN klijente i usmjerava ih na LAN treba put prosljeđivanja, a to je upravo lanac koji većina zadanih konfiguracija ostavlja prazan.

Odabir izvora pripada istoj odluci i tu se krije većina neusklađenosti. Kernel bira izvornu adresu sa odlaznog interfejsa osim ako ruta ne navede neku, pa pravilo filtera napisano za LAN podmrežu nikada ne odgovara paketu koji izlazi sa adresom tunela.

Pročitajte šta je pretraga zaista odabrala

Odštampajte odluku umjesto da je izvodite. Komanda ispod razrješava rutu koju bi kernel koristio za to odredište, uključujući interfejs i izvor koji bi odabrao:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN klijenti često instaliraju pravila politike na prioritetima ispod glavne tablice, pa čista glavna tablica sama po sebi ništa ne dokazuje. Uporedite prioritete pravila sa tablicama koje biraju i provjerite preživljava li tunelska ruta ponovno povezivanje umjesto da se jednom dodaje ručno.

IPsec zasnovan na politici dodaje treću fazu podudaranja koju rutiranje ne pokriva, kako opisuju strongSwan-ove napomene o prosljeđivanju za tunelske i transportne postavke. Sigurnosna politika bira saobraćaj po prefiksu i protokolu, dok ruta samo odlučuje kuda bi nezaštićeni paket otišao. Podmreža koja je rutirana ali nema odgovarajući selektor ili ostaje nezaštićena ili se odbacuje, zavisno od konfiguracije, i nijedan ishod ne izgleda kao problem firewall-a. Odštampajte politiku i uporedite njene selektore sa prefiksima za koje ste očekivali da ih tunel nosi.

Filtriranje se primjenjuje na kuki, ne na ruti

Pravilo koje dopušta VPN listener je pravilo o saobraćaju upućenom samom gatewayu. Ono ne govori ništa o klijentima koji dosežu hostove iza tog gatewaya, jer proslijeđeni saobraćaj prolazi kroz drugi lanac. Čitanje skupa pravila kao jedne ravne liste uobičajen je razlog zašto ispravno pravilo nikada ne reaguje.

Brojači brzo rješavaju pitanje. Pravilo s nultim brojem paketa nikada nije dosegnuto, što ukazuje na pogrešan lanac, pogrešan interfejs ili ranije odbacivanje. Pravilo s rastućim brojem pod politikom odbacivanja je granica koju ste tražili, a paket se odbacuje, a ne pogrešno rutira.

Pošaljite probu putem koji klijent koristi

Testovi pokrenuti na samom gatewayu prolaze kroz izlaz i ulaz, sa vlastitom izvornom adresom gatewaya. To je drugačiji put od klijentovog proslijeđenog zahtjeva, pa uspješan lokalni curl dokazuje manje nego što izgleda. Provjeravajte sa mašine koja ne uspijeva ili eksplicitno prikvačite interfejs i izvor.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Snimanje na oba kraja razdvaja preostale slučajeve. SYN koji napusti klijenta i nikada ne stigne znači rutiranje, enkripciju ili uzvodnu pristupnu listu. SYN koji stigne i ne dobije odgovor znači uslugu ili njen host filter, a tunel nikada nije bio problem.

Povratni saobraćaj zaslužuje poseban pogled. Asimetrično rutiranje plus filtriranje obrnutog puta odbacuje odgovore koji stižu na pogrešan interfejs, što se pokazuje kao jednosmjerna veza, a ne kao blokiran port. Provjerite vrijednost sysctl prije nego okrivite firewall za simptom koji nije izazvao.

Logovanje radi kao drugo mišljenje, ne kao prvi korak. Privremena log izjava na lancu prosljeđivanja imenuje interfejs i adrese koje su ga pogodile, a lako se uklanja kasnije. Ostavite li je trajno, napravili ste problem obima logova umjesto odgovora.

Stavite svaku promjenu tamo gdje preživljava ponovno povezivanje

Ruta dodana sa ip route add živi dok interfejs ne padne. Sačuvajte je u profilu veze: NetworkManager prihvata dodatne rute na vezi, a netplan ih čuva između podizanja. Isto pravilo važi za izuzetak firewall-a na strani klijenta, koji nestaje nakon sljedećeg ponovnog učitavanja.

Pravila na strani servera pripadaju konfiguracijskoj datoteci koju usluga učitava pri pokretanju, a ne interaktivnoj sesiji koja završava kad je zatvorite. Napišite pravilo, ponovo učitajte i potvrdite da se brojač pomaknuo, jer ponovno učitavanje koje je odbilo sintaksu tiho ostavlja stari skup pravila na mjestu.

Zatim ponovite originalni zahtjev aplikacije od početka do kraja i zabilježite koji se sloj promijenio. Popravka rute kojoj je trebala i promjena filtera ipak će propasti, a drugi se neuspjeh čita mnogo lakše kada znate da je prvi nestao. Zabilježite datum i verziju klijenta pored rezultata, jer se zadane postavke rutiranja i filtriranja mijenjaju između izdanja. Držite tu bilješku na tiketu da sljedeća osoba počne gdje ste stali umjesto da ponavlja dvostepenu šetnju.