Zašto VPN klijent na uredskoj mreži gubi svaki odgovor

Prijenosnik stoji na uredskoj mreži /24 preko Etherneta i istovremeno se pridružuje poslužitelju OpenVPN koji živi u istoj /24. Kolega pinga adresu tunela; zahtjev očito stiže, a natrag se ne vraća ništa. Dnevnik tunela je čist i pregledavanje još radi, pa je tunel pogrešan osumnjičeni. IPv4 provjera izvora na stroju koji prima baca paket prije nego što ga išta pročita.

Odbacivanje se dogodi prije nego što išta pročita paket

Provjera izvora postavlja jedno pitanje o svakom dolaznom paketu: da je ovaj host odgovorio tom izvoru, bi li odgovor otišao kroz sučelje na koje je paket upravo stigao? Kada je odgovor ne, kernel baca paket odmah po dolasku. Ni socket ni put prosljeđivanja ga nikad ne vide, zato snimka na tunelu još bilježi zahtjev koji aplikacija nikad ne primi.

Klijent ovdje drži 10.66.0.9 na svom tunelu, a poslužitelj OpenVPN odgovara s 192.168.80.10 unutar uredskog prefiksa. Kolega na 192.168.80.25 pinga adresu tunela, pa zahtjev prelazi LAN, poslužitelj ga usmjerava u tunel i on stiže na tunelsko sučelje klijenta noseći uredsku izvornu adresu. U usmjerivačkoj tablici tog stroja uredski prefiks pripada Ethernet uređaju, a ne tunelu. Provjera uspoređuje sučelje dolaska s rutom, nalazi nesklad i odbacuje paket, pa kolega vidi potpuni gubitak dok oba kraja prijavljuju zdrav tunel.

Zrcalni smjer ima isti oblik: kada klijent započne prema uredu, odgovori se mogu odbaciti na uredskoj strani iz istog razloga. Popravak potvrđen samo u jednom smjeru obično se vraća kao drugi tiket.

Dokažite važeći način rada prije nego dotaknete bilo koji sysctl

Čitajte stvarne vrijednosti umjesto da vjerujete zadanom izdanju distribucije, jer je postavka po sučelju samo polovica odluke. Važeći način rada je viša od vrijednosti sučelja i vrijednosti all, pa nula na tunelskom sučelju ne znači ništa dok je all jedan. Odluka strogog načina je odluka usmjeravanja, pa pokrenite pretragu koju pokreće kernel i usporedite njezin odgovor sa sučeljem na koje je paket stvarno stigao.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Zatim ponovite ping dok gledate brojač pogrešaka. Broj koji raste uz zahtjev koji snimka već pokazuje potpis je ovog odbacivanja, a ne rute koja nedostaje. Uključite marsijansko bilježenje dok ste tamo, da kernel imenuje izvor i sučelje koje je odbio. Zajedno isključuju šifru, vatrozid i iroute koji nedostaje kao objašnjenja.

Zapišite početno stanje prije nego što išta promijenite: obje vrijednosti, uređaj koji je pretraga odabrala i brojač koji ste gledali. Taj zapis je ono što vam kasnije kaže je li promjena učinila ono što mislite.

Što svaki rp_filter način stvarno prihvaća

Kernel izlaže tri vrijednosti po sučelju i to nisu tri nijanse jednog pravila. Nula isključuje provjeru. Jedan je strog i zahtijeva da se izvor usmjeri natrag kroz sučelje dolaska. Dva je labav i zahtijeva samo da u tablici postoji neka ruta do izvora, kamo god pokazivala.

Redak koji je ovdje važan je labavi i ono što i dalje odbija. Krivotvoreni izvor koji je usmjeriv bilo gdje u vašoj tablici prolazi, dok se izvor bez ikakve rute još odbija. Na prijenosniku je to uska ustupka; na usmjerivaču koji prosljeđuje promet drugih ljudi široka je. Način rada pripada hostu, pa isti broj nosi različitu težinu na dva mjesta.

Koji redak ova topologija treba slijedi iz tablice, a ne iz navike. Paket je legitiman i njegov izvor je usmjeriv, pa ga labavi prihvaća, a strogi ne. Ništa u ovom slučaju ne traži nulu, a odabir nule uklonio bi provjeru koja ovdje ništa ne stoji.

Odaberite najmanju promjenu koja uklanja dvosmislenost

Labavi način je najmanja promjena koja odgovara i pravo je smanjenje strogosti, a ne bezopasni prekidač. Bolja mogućnost postoji kad god topologija dopušta: uklonite preklapanje i dvosmislenost nestaje.

Gdje je uredski prefiks potreban samo preko Etherneta, izbacite ga iz ruta koje profil povlači i adresa postaje dostupna jednim putem. Kada dva puta doista moraju supostojati, prikvačite izvor i uređaj pravilom politike umjesto da popuštate provjeru na svakom sučelju. To zadržava strogo filtriranje za sve ostalo na stroju i dokumentira iznimku tamo gdje će je sljedeći inženjer tražiti.

Koji god put odabrali, zapišite ga u sysctl drop-in, a ne u živu naredbu. Postavite ključeve all i default zajedno, da ponovno povezivanje ne može tiho vratiti strogi način.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Što labavi način gubi i gdje

Labavi način još odbija izvor do kojeg nijedna ruta ne bi stigla i prestaje odbijati krivotvoreni izvor koji je slučajno usmjeriv. Na prijenosniku je to uska ustupka. Na uređaju koji prosljeđuje promet koji ne posjeduje, isti je odabir mnogo širi. Ista postavka zato nosi dva vrlo različita značenja ovisno o tome gdje radi.

Potpuno isključivanje provjere na hostu koji prosljeđuje promet drugih ljudi jedini je popravak koji treba izbjegavati. Nula odbacuje provjeru koju labavi način pažljivo čuva. Ako host prosljeđuje za druge, zauzmite se umjesto toga za mogućnost s pravilom politike iz prethodnog odjeljka.

Ostavite bilješku koja imenuje dva sučelja, prefiks koji se preklapa i točnu probu koja sada uspijeva. To je sljedećem inženjeru korisnije od retka koji kaže da je filtriranje prilagođeno.