Odgovor site-to-site VPN-a ne prolazi kroz tunel

Proveo sam jutro na tunelu koji se čisto podigao i prenosio promet točno u jednom smjeru: podružnica je mogla doći do datotečnog poslužitelja u sjedištu, a svaka veza otvorena iz sjedišta prema podružnici umirala je na prvom SYN-u. SA-ovi su bili aktivni, brojači tunela su rasli, a rukovanje nikada nije bilo problem. Odgovor se usmjeravao negdje gdje tunel ne pokriva, a taj izbor pripada udaljenoj strani. Site-to-site VPN prenosi samo pakete koje host preda pristupniku, a svaki host tu odluku donosi zasebno, u svakom smjeru, iz svoje tablice usmjeravanja.

Oba se smjera usmjeravaju odvojeno

IP ne pamti smjer razgovora. Svaki host koji šalje paket radi vlastitu pretragu najduljeg prefiksa, odabire jedan sljedeći skok i zaboravlja odluku. Zahtjev i odgovor dva su nepovezana paketa koji slučajno pripadaju istoj vezi, a tunel je jedan skok koji bilo koji od njih može ili ne mora koristiti. Ništa u IKE razmjeni ne uči udaljeni poslužitelj kako da dosegne vašu podmrežu; pregovori se samo slažu koji se prefiksi smiju šifrirati.

Taj dogovor je druga vrata. Na strongSwanu selektori prometa su leftsubnet i rightsubnet, a paket čiji izvor ili odredište padne izvan dogovorenog para ne šifrira se, što god tablica usmjeravanja govorila. Prefiks koji se usmjerava u tunel, ali nedostaje u selektorima, tiha je jednosmjerna greška: ruta izgleda ispravno, paket ipak izlazi u čistom obliku ili se odbacuje, a samo se charonov zapis žali.

Udaljeni host ne zna ništa o vašem tunelu

Unutar udaljenog LAN-a odgovor je običan paket upućen vašem klijentu. Odredišni host ne vidi IPsec zaglavlje i nema razloga preferirati VPN pristupnik; traži vaš prefiks, ne nalazi ništa konkretnije od svoje zadane rute i slijedi je. Ako zadana ruta pokazuje na središnji vatrozid, vatrozid ili ima rutu natrag u tunel ili je nema. Kad je nema, dobivate tiho odbacivanje, ICMP nedostupnost ili odgovor koji izlazi kroz sučelje prema internetu i umire.

Drugo sučelje dovoljno je da to pokvari čak i kad ruta postoji. NAS s upravljačkom vezom na drugom VLAN-u, poslužitelj s rezervnim uplinkom, pravilo politike koje šalje jedan raspon izvora u drugu tablicu: bilo što od toga može uhvatiti odgovor. Na Linuxu ip rule show i ip route show table all otkrivaju pravila i tablice koje zadani popis skriva.

Pročitajte odluku na stroju koji šalje odgovor

Pitajte kernel prije nego išta promijenite i dajte mu izvorišnu adresu, jer pravila ovisna o izvoru mijenjaju odgovor.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Izlaz navodi odlazno sučelje i sljedeći skok. Ako sučelje nije ono okrenuto VPN pristupniku, pronašli ste kvar, a preostali je posao odabrati gdje ruta pripada. Ping s pristupnika ovdje malo dokazuje: odgovara adresom koju udaljeni host može smjestiti, a ne adresom vašeg prijenosnika.

Na Windowsu su ekvivalenti Find-NetRoute -RemoteIPAddress 10.10.5.10 za odluku i Get-NetRoute za tablicu. Ruta dodana s New-NetRoute koja nosi višu metriku od zadane gubi tiho, pa čitajte stupac metrike, a ne zapis. Zatim potvrdite paketima: tcpdump -ni any "host 10.10.5.10 and tcp port 445" na udaljenom LAN sučelju pokazuje zahtjev, a isti filtar na strani tunela pokazuje je li se odgovor vratio. Zahtjev vidljiv bez odgovora znači da je odgovor usmjeren drugamo ili odbačen; odgovor na pogrešnom sučelju daje vam krivca prije nego dotaknete rutu.

Kad pristupnik poslužitelja nije VPN završna točka

Mnoga mjesta stavljaju vatrozid između poslužitelja i koncentratora. Taj vatrozid prosljeđuje odgovor, pa mu treba ruta za prefiks vašeg klijenta prema VPN pristupniku i politika prosljeđivanja u oba smjera. Stanjni uređaji pogoršavaju stvar: zahtjev je prešao vatrozid s LAN hosta kojem je to dopustio, odgovor sada dolazi iz drugog smjera, a zapis praćenja veze više se ne podudara, pa se paket odbacuje kao nevaljan, a ne kao zabranjen. Zato popis politike izgleda prazan dok promet nestaje.

Pristupnik ima i svoj drugi filtar. Linux filtriranje obrnutog puta odbacuje pakete čiji izvor nije dostupan kroz sučelje na koje su stigli, a to je točno oblik zakonitog asimetričnog povratnog puta. strongSwanove smjernice za prosljeđivanje traže net.ipv4.ip_forward i ublažen net.ipv4.conf.all.rp_filter upravo iz tog razloga. Stroga vrijednost 1 na bilo kojem pristupniku tiho kvari ispravnu rutu, a nstat -az pokazuje odbacivanja ako znate gdje gledati.

Usmjerite ili prevedite, pa provjerite u oba smjera

Dva popravka nisu jednaka. Dodavanje rute čuva adresu klijenta netaknutom, pa pravila temeljena na izvoru, revizijski zapisi i aplikacije koje bilježe pozivatelja nastavljaju raditi; cijena je da svaki skok koji donosi odluku treba rutu, a to je više mjesta za pogrešku. Maskiranje na udaljenom pristupniku svodi povratni put na jedan skok, jer je odgovor sada upućen samom pristupniku, i skriva koji je klijent što učinio.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Odaberite ga namjerno: kad se klijenti počnu pojavljivati kao adresa pristupnika, ACL-ovi temeljeni na izvoru prestaju ih razlikovati, a conntrack mora držati mapiranje da bi se odgovor prepisao natrag u tunel. Ako selektori još uvijek isključuju prefiks klijenta, NAT ne mijenja ništa, jer zahtjev nikada nije ušao u tunel.

Prije nego što to proglasite popravljenim, potvrdite četiri stvari redom: rutu na hostu koji šalje odgovor, rutu na svakom skoku koji je prosljeđuje, selektore koji pokrivaju oba prefiksa i snimku koja pokazuje da odgovor ulazi u tunel s izvorom koji očekujete. Zatim ponovite test s drugog mjesta. Jedan smjer koji prolazi je poluotvoreni dizajn, a drugi smjer obično pada zbog drukčijeg razloga od onoga koji ste upravo popravili.