Odziv VPN med lokacijama ne gre skozi tunel

Dopoldne sem preživel ob tunelu, ki se je čisto dvignil in prenašal promet točno v eno smer: podružnica je dosegla strežnik datotek v sedežu, vsaka povezava, odprta iz sedeža v podružnico, pa je umrla ob prvem SYN. SA so bile aktivne, števci tunela so rasli in rokovanje nikoli ni bilo težava. Odziv se je usmerjal nekam, česar tunel ne pokriva, in ta izbira pripada oddaljeni strani. VPN med lokacijama prenaša le pakete, ki jih gostitelj izroči prehodu, in vsak gostitelj to izbiro naredi ločeno, v vsaki smeri, iz svoje usmerjevalne tabele.

Obe smeri se usmerjata ločeno

IP si ne zapomni smeri pogovora. Vsak gostitelj, ki pošlje paket, izvede svoje iskanje najdaljše predpone, izbere en naslednji skok in odločitev pozabi. Zahteva in odziv sta dva nepovezana paketa, ki po naključju pripadata isti povezavi, tunel pa je en skok, ki ga lahko uporabi kateri koli od njiju ali ne. Nič v izmenjavi IKE ne uči oddaljenega strežnika, kako doseči vašo podomrežje; pogajanja se le dogovorijo, katere predpone se smejo šifrirati.

Ta dogovor so druga vrata. V strongSwanu sta prometna selektorja leftsubnet in rightsubnet, paket, katerega vir ali cilj pade izven dogovorjenega para, pa ni šifriran, kar koli pravi usmerjevalna tabela. Predpona, ki se usmerja v tunel, a je v selektorjih ni, je tiha enosmerna napaka: pot je videti pravilna, paket vseeno odide v jasnem ali se zavrže, in pritožuje se le dnevnik charona.

Oddaljeni gostitelj ne ve nič o vašem tunelu

Znotraj oddaljenega LAN je odziv običajen paket, naslovljen na vašega odjemalca. Ciljni gostitelj ne vidi nobene glave IPsec in nima razloga, da bi dajal prednost prehodu VPN; poišče vašo predpono, ne najde ničesar bolj določnega od svoje privzete poti in ji sledi. Če privzeta pot kaže na osrednji požarni zid, ima ta bodisi pot nazaj v tunel bodisi ne. Ko je nima, dobite tiho zavrženje, ICMP unreachable ali odziv, ki odide skozi vmesnik proti internetu in umre.

Drugi vmesnik zadostuje, da to pokvari, tudi ko pot obstaja. NAS z upravljalno povezavo v drugem VLAN, strežnik z rezervnim uplinkom, pravilo politike, ki pošlje en obseg virov v drugo tabelo: karkoli od tega lahko ujame odziv. V Linuxu ip rule show in ip route show table all pokažeta pravila in tabele, ki jih privzeti seznam skriva.

Preberite odločitev na stroju, ki pošlje odziv

Vprašajte jedro, preden karkoli spremenite, in mu dajte naslov vira, ker pravila, odvisna od vira, spremenijo odziv.

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 )"

Izhod navaja odhodni vmesnik in naslednji skok. Če vmesnik ni tisti, ki gleda proti prehodu VPN, ste našli napako, in ostane le izbira, kam sodi pot. Ping s prehoda tu malo dokaže: odgovori z naslovom, ki ga oddaljeni gostitelj zna umestiti, ne z naslovom vašega prenosnika.

V Windowsu sta ustreznici Find-NetRoute -RemoteIPAddress 10.10.5.10 za odločitev in Get-NetRoute za tabelo. Pot, dodana z New-NetRoute, ki nosi višjo metriko od privzete, tiho izgubi, zato berite stolpec metrike, ne vnosa. Nato potrdite s paketi: tcpdump -ni any "host 10.10.5.10 and tcp port 445" na oddaljenem vmesniku LAN pokaže zahtevo, isti filter na strani tunela pa pokaže, ali se je odziv vrnil. Zahteva, vidna brez odziva, pomeni, da je bil odziv usmerjen drugam ali zavržen; odziv na napačnem vmesniku vam da krivca, preden se dotaknete poti.

Ko prehod strežnika ni končna točka VPN

Mnoge lokacije postavijo požarni zid med strežnike in koncentrator. Ta požarni zid posreduje odziv, zato potrebuje pot za predpono vašega odjemalca proti prehodu VPN in politiko posredovanja v obeh smereh. Naprave s stanjem stvar poslabšajo: zahteva je prešla požarni zid z gostitelja LAN, ki mu je to dovolil, odziv zdaj prihaja iz druge smeri in vnos sledenja povezav se ne ujema več, zato se paket zavrže kot neveljaven, ne kot prepovedan. Zato je dnevnik politike videti prazen, medtem ko promet izginja.

Prehod ima svoj drugi filter. Linuxovo filtriranje obratne poti zavrže pakete, katerih vir ni dosegljiv skozi vmesnik, po katerem so prispeli, in to je natanko oblika zakonite asimetrične povratne poti. vodnik strongSwana za posredovanje zato zahteva net.ipv4.ip_forward in omiljen net.ipv4.conf.all.rp_filter. Stroga vrednost 1 na katerem koli prehodu tiho pokvari pravilno pot, nstat -az pa pokaže zavrženja, če veste, kam pogledati.

Usmerjajte ali prevajajte, nato preverite v obeh smereh

Dve popravili nista enakovredni. Dodajanje poti ohrani naslov odjemalca nedotaknjen, zato pravila, ki temeljijo na viru, revizijski dnevniki in aplikacije, ki beležijo klicatelja, še naprej delujejo; cena je, da vsak skok, ki sprejme odločitev, potrebuje pot, torej več mest za napako. Maskiranje na oddaljenem prehodu stisne povratno pot v en skok, ker je odziv zdaj naslovljen na prehod sam, in skrije, kateri odjemalec je kaj storil.

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

Izberite ga zavestno: ko se odjemalci začnejo kazati kot naslov prehoda, jih ACL, ki temeljijo na viru, ne ločujejo več, in conntrack mora držati preslikavo, da se odziv prepiše nazaj v tunel. Če selektorji še vedno izključujejo predpono odjemalca, NAT ne spremeni ničesar, ker zahteva nikoli ni vstopila v tunel.

Preden to razglasite za popravljeno, po vrsti potrdite štiri stvari: pot na gostitelju, ki pošlje odziv, pot na vsakem skoku, ki jo posreduje, selektorje, ki pokrivajo obe predponi, in posnetek, ki kaže odziv, kako vstopa v tunel z virom, ki ga pričakujete. Nato poskus ponovite z druge lokacije. Ena smer, ki gre skozi, je na pol odprta zasnova, druga smer pa običajno odpove iz drugačnega razloga od tistega, ki ste ga pravkar popravili.