Tunel se dvigne, odjemalec pinga strežnik VPN, in skupna mapa na stroju en skok dlje nikoli ne odgovori. Nič v konfiguraciji odjemalca tega ne pojasni, ker je zahteva resnično zapustila odjemalca in resnično prispela. Kar je spodletelo, je pot nazaj, in naprava, ki je spodletela, je običajno prehod LAN in ne gostitelj VPN. Sledenje paketu z odgovorom pojasni celoten ta razred simptomov.

Sledite odgovoru, ne zahtevi

Strežnik VPN dešifrira paket odjemalca in ga posreduje v LAN, pri čemer naslov odjemalca ostane v polju vira. Ciljni gostitelj odgovori na ta naslov, in zdaj odloča vse njegova lastna usmerjevalna tabela. Njegov privzeti prehod ne ve ničesar o bazenu tunela, zato odgovor odide proti ponudniku interneta in je nekje na tej poti zavržen.

Na odjemalcu je simptom tiha časovna omejitev: brez zavrnitve, brez ponastavitve, preprosto nič. Brskanje po skupni mapi se ustavi, ping poroča, da ni odgovora, in dnevnik strežnika je videti zdrav, ker je strežnik opravil svoje delo.

Povratno pot postavite tja, kamor gledajo gostitelji

Vsak gostitelj v LAN vpraša svoj privzeti prehod, zato je prehod edina naprava, ki mora vedeti, kje je bazen tunela. Dodajte tam statično pot in vsak gostitelj podeduje pravilno pot, ne da bi se ga dotaknili.

Če prehod razdeljuje svoj naslov kot možnost DHCP, razdelite pot na ta način, da jo nove naprave prevzamejo samodejno. Sicer pot živi v eni konfiguracijski datoteki in izgine ob naslednji ponovni gradnji.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Zakaj se zdi, da izvorni NAT to popravi

Maskiranje bazena odjemalcev za naslovom strežnika VPN odpravi težavo tako, da odstrani naslov odjemalca iz paketa. Odgovori se nato vrnejo na strežnik, ki že ve, kako doseči tunel, in vse deluje. Cena je, da notranji gostitelji ne morejo več videti, kdo je odjemalec, in vsaka povezava je videti, kot da prihaja z enega stroja.

Ta izmenjava je včasih pravilna, na primer ko napravi dobavitelja ni mogoče dati statične poti. Pravila ne naredite širšega od trenutnega bazena, ker pravilo, napisano za /24, preneha ustrezati na dan, ko se bazen preštevilči v /16, in prvi znak je skupina novih odjemalcev, ki se povežejo in ne dosežejo ničesar.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Pot v oblaku zahteva tri nastavitve

V VPC se ista vrzel vrne v drugi obliki, ker podomrežje sploh nima poti za obseg odjemalcev. Usmerjevalna tabela potrebuje vnos za bazen tunela, ki kaže na omrežni vmesnik primerka, in na vmesniku je treba izklopiti preverjanje vira in cilja, da platforma sprejme pakete, katerih vir ni njegov lastni naslov. Varnostne skupine in omrežni ACL morajo bazen spustiti tudi v obe smeri.

Vsaka izpustitev ustvari drugačno delno napako. Izpustite vnos v usmerjevalni tabeli in zasebni primerki odgovarjajo v podomrežje, ki ne more prenesti odgovora nazaj v bazen. Ob vklopljenem preverjanju platforma odgovor zavrže, potem ko ga je primerek že poslal. Brez pravila varnostne skupine sama zahteva nikoli ne prispe, in odjemalec vidi časovno omejitev eno plast prej.

Preverjanja izvedite v tem vrstnem redu

Potrdite posredovanje in politiko filtriranja, preden krivite usmerjanje, ker gostitelj, ki ne bo posredoval, spodleti na enak tih način. Nato preberite veljavno nastavitev povratne poti na vmesniku, ki nosi tunel, saj lahko strogi filter zavrže odgovore, ki prihajajo iz nepričakovane smeri.

Končajte s posnetkom na gostitelju v LAN, medtem ko ga odjemalec pinga. Zahteva, ki prispe brez ustreznega odgovora, dokazuje povratno pot, in zahteva, ki nikoli ne prispe, premakne krivdo nazaj na strežnik ali tunel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Preverjanje vira in cilja je dokumentirano v priročniku za elastične omrežne vmesnike. Nastavite ga na vmesniku, ki dejansko nosi promet tunela, ne na nepovezanem vmesniku, priključenem na isti primerek.

Sorodni članki