Odjemalec VPN na strežniku LAN: zakaj odgovori odhajajo po napačni poti

Simptomi sledijo enemu vzorcu: gostitelj deluje, nato se kot odjemalec poveže z VPN in zdaj ga odjemalci LAN dosežejo, medtem ko njegovi odgovori izginjajo. Zajem na gostitelju pokaže, da odgovori odhajajo skozi tunelsko napravo namesto skozi vmesnik LAN. Na tunelu ni nič pokvarjeno, popravek pa je pot, ne ponovna povezava. Izvedite štiri preverjanja spodaj po vrsti in ustavite se pri prvem, ki ne uspe.

Odgovor je nov paket, ne obrat poti

Pomaga opustiti idejo, da se odgovor vrača po poti, po kateri je šla zahteva. Usmerjanje se odloča za vsak paket in vsako smer na gostitelju, ki pošilja. Zahteva, ki je prispela z 10.64.0.23 znotraj tunela, ne ustvari nobene povratne poti; ko gostitelj odgovori, se ta odgovor primerja s tabelo kot nov paket in odide po poti, ki zmaga.

Zato odjemalec s polnim tunelom na stroju, ki služi tudi LAN, povzroči tako zmedeno okvaro. Odjemalec namesti privzeto pot ali dve polovični privzeti poti, ki jih imajo raje nekateri odjemalci, in odgovor odjemalcu LAN se zdaj ujema s tunelom. Odide k ponudniku, ki nima razloga, da bi ga posredoval, odjemalec LAN pa vidi potek časa, čeprav gostitelj dela in odgovarja lokalno. Zajem to razkrije, usmerjevalna tabela pa to razloži.

Med branjem preostanka imejte v mislih dve podomrežji. Eno je nabor naslovov VPN, od koder prihajajo oddaljeni odjemalci, v tem primeru 10.64.0.0/24. Drugo je LAN, ki mora delovati naprej, 172.16.24.0/24 z usmerjevalnikom na 172.16.24.1. Napaka je v tem, da promet med njima odloča privzeta pot.

Dokažite to z zajemom in poizvedbo

Preden karkoli spremenite, potrdite, katero napravo bo uporabil odgovor. Poizvedba je hitrejša od zajema in odgovori točno na vprašanje, na katero bo odgovorilo jedro ob sestavljanju paketa.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Preberite odgovor v dveh delih. Če navaja dev tun0, bo gostitelj odgovor zapakiral in ga izročil ponudniku, odjemalec LAN pa ga ne bo nikoli videl. Če navaja dev eth0, a odjemalec vseeno dobi potek časa, je pot že pravilna in paket se zavrže pozneje, kar je druga težava z drugim popravkom.

Zajem v istem koraku razreši dvom, ki ga ping ne more. Odgovor odmeva, ki prispe do odjemalca LAN, dokazuje, da neka pot deluje, ne kateri vmesnik ga je prenesel, zato izvedite zajem na gostitelju samem in opazujte, od kod odhajajo okviri. Tiskalnik v istem podomrežju še naprej odgovarja, ker je njegova neposredna pot bolj specifična od privzete poti tunela. Preusmerjena vrata ne uspejo enako kot vsak drug tok, ker vmesnik izbere tabela, ne povezava.

Namestite najožjo pot, ki preseže tunel

Odloča dolžina predpone, ne metrika, zato pot za nabor odjemalcev prek usmerjevalnika LAN premaga vsako privzeto pot, ki jo namesti odjemalec VPN. Kirurgija metrike ni potrebna, privzeta pot pa lahko ostane točno tam, kamor jo je odjemalec postavil.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Uporabite replace namesto add, ker je odjemalec, ki se znova poveže, že namestil svoj vnos in drugi add ne uspe z napako o obstoječi poti, ki se bere kot težava z dovoljenji. Na gostitelju Windows je ustreznica route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, kjer -p ohrani vnos med ponovnimi zagoni, saj lahko odjemalec tabelo znova sestavi, ko se tunel vrne. Na sodobnem gostitelju Windows je podprta ustreznica New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, starejši ukaz route pa ostaja kot starejša oblika.

En podatek odloči, ali je to pravilno ali le verjetno: naslednji skok mora biti usmerjevalnik, ki res ima pot nazaj do odjemalcev. Usmeritev poti na naslov, ki je sam dosegljiv skozi tunel, ustvari zanko, ki se kaže kot občasna izguba, ne kot čista okvara. Preden potrdite vrstico, preverite, da je naslednji skok v podomrežju LAN.

Ohranite odgovor po ponovni povezavi

Ročno dodana pot preživi v najboljšem primeru do naslednje povezave. Če je nabor odjemalcev dinamičen, ga pripnite v konfiguracijo strežnika, da predpona, ki ste jo usmerili, ostane predpona, ki jo prejmejo odjemalci; sicer vnos kaže na prazen razpon in simptom se vrne tedne pozneje brez očitnega vzroka. Zapis poti v odjemalčevo lastno skripto up je druga zanesljiva možnost, ker se izvede potem, ko je odjemalec prepisal tabelo.

Požarni zid s stanjem lahko še vedno premaga pravilno pot. Če zajem zdaj kaže, da odgovor odhaja skozi eth0, odjemalec pa vseeno dobi potek časa, preverite, ali gostitelj paket zavrže pred pošiljanjem. Strogo filtriranje povratne poti in net.ipv4.conf.all.rp_filter, nastavljen na 1, zavržeta pakete, katerih vir ne bi bil usmerjen nazaj skozi vmesnik, po katerem so prispeli, in to je natanko tisti asimetrični primer, ki ste ga pravkar ustvarili in nato popravili, stanje conntrack pa pripoveduje isto zgodbo za preusmerjena vrata.

Zadnje preverjanje je tisto, ki ga ljudje preskočijo: ponovite poizvedbo potem, ko je tunel padel in se znova dvignil. Štiri vrednosti se morajo ujemati s tem, kar ste zapisali: cilj, naslednji skok, naprava in izbrani vir. Če se je katera premaknila, je odjemalec prepisal tabelo in popravek spada v njegove kavlje, ne v zgodovino lupine.