Maršrutizuotas VPN klientas pasiekia serverį, bet ne LAN mazgus

Tunelis pakyla, klientas pingina VPN serverį, o bendrinamas aplankas kompiuteryje vienu šuoliu toliau niekada neatsako. Niekas kliento konfigūracijoje to nepaaiškina, nes užklausa tikrai paliko klientą ir tikrai atvyko. Nepavyko grįžimo kelias, o nepavykęs įrenginys paprastai yra LAN tinklų sietuva, o ne VPN mazgas. Atsakymo paketo sekimas paaiškina visą šią simptomų klasę.

Sekite atsakymą, o ne užklausą

VPN serveris iššifruoja kliento paketą ir persiunčia jį į LAN, palikdamas kliento adresą šaltinio lauke. Paskirties mazgas atsako į tą adresą, ir dabar viską lemia jo paties maršrutų lentelė. Jo numatytoji tinklų sietuva nieko nežino apie tunelio baseiną, todėl atsakymas išvyksta interneto tiekėjo link ir kažkur tame kelyje numetamas.

Kliente simptomas yra tyli laiko riba: jokio atmetimo, jokio atstatymo, tiesiog nieko. Bendrinamo aplanko naršymas užstringa, ping praneša, kad atsakymo nėra, o serverio žurnalai atrodo sveiki, nes serveris atliko savo darbą.

Įdėkite grįžimo maršrutą ten, kur žiūri mazgai

Kiekvienas LAN mazgas konsultuojasi su savo numatytąja tinklų sietuva, todėl tinklų sietuva yra vienintelis įrenginys, kuris turi žinoti, kur yra tunelio baseinas. Pridėkite ten statinį maršrutą ir kiekvienas mazgas paveldės teisingą kelią jo neliesdami.

Jei tinklų sietuva dalija savo adresą kaip DHCP parinktį, paskirstykite maršrutą tuo būdu, kad nauji kompiuteriai jį paimtų automatiškai. Priešingu atveju maršrutas gyvena viename konfigūracijos faile ir dingsta per kitą perrinkimą.

# 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

Kodėl šaltinio NAT atrodo, kad tai ištaiso

Klientų baseino maskavimas už VPN serverio adreso pašalina problemą pašalindamas kliento adresą iš paketo. Tada atsakymai grįžta į serverį, kuris jau žino, kaip pasiekti tunelį, ir viskas veikia. Kaina ta, kad vidiniai mazgai nebegali matyti, kas yra klientas, ir kiekvienas ryšys atrodo kilęs iš vieno kompiuterio.

Šis mainas kartais yra teisingas, pavyzdžiui, kai tiekėjo įrenginiui negalima suteikti statinio maršruto. Nedarykite taisyklės platesnės už dabartinį baseiną, nes taisyklė, parašyta /24 tinklui, nustoja tikti tą dieną, kai baseinas pernumeruojamas į /16, o pirmasis požymis yra naujų klientų grupė, kurie prisijungia ir nieko nepasiekia.

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

Debesų kelias reikalauja trijų nustatymų

VPC atveju ta pati spraga grįžta kita forma, nes potinkis visai neturi maršruto klientų diapazonui. Maršrutų lentelei reikia įrašo tunelio baseinui, nukreipto į egzemplioriaus tinklo sąsają, o sąsajoje turi būti išjungta šaltinio ir paskirties patikra, kad platforma priimtų paketus, kurių šaltinis nėra jos pačios adresas. Saugos grupės ir tinklo ACL taip pat turi praleisti baseiną abiem kryptimis.

Kiekvienas praleidimas sukuria atskirą dalinį gedimą. Praleiskite maršrutų lentelės įrašą ir privatūs egzemplioriai atsako į potinklį, kuris negali pernešti atsakymo atgal į baseiną. Kai patikra vis dar įjungta, platforma numeta atsakymą po to, kai egzempliorius jį jau išsiuntė. Be saugos grupės taisyklės pati užklausa niekada neatvyksta, o klientas laiko ribą mato vienu sluoksniu anksčiau.

Atlikite patikras tokia tvarka

Patvirtinkite persiuntimą ir filtravimo politiką prieš kaltindami maršrutizavimą, nes mazgas, kuris nepersiųs, žlunga taip pat tyliai. Tada perskaitykite galiojantį atgalinio kelio nustatymą sąsajoje, kuri neša tunelį, nes griežtas filtras gali numesti atsakymus, ateinančius iš netikėtos krypties.

Pabaikite su užfiksuotu įrašu LAN mazge, kol klientas jį pingina. Užklausa, kuri atvyksta be atitinkančio atsakymo, įrodo grįžimo kelią, o užklausa, kuri niekada neatvyksta, kaltę grąžina serveriui arba tuneliui.

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

Šaltinio ir paskirties patikra dokumentuota elastingos tinklo sąsajos vadove. Nustatykite ją sąsajoje, kuri iš tikrųjų neša tunelio srautą, o ne nesusijusiame adapteryje, prijungtame prie to paties egzemplioriaus.