Marsruuditud VPN-klient jõuab serverini, kuid mitte LAN-i hostideni

Tunnel tõuseb, klient pingib VPN-serverit ja ühe hüppe kaugusel asuva masina jagatud kaust ei vasta kunagi. Kliendi konfiguratsioonis ei selgita seda miski, sest päring lahkus kliendist ja jõudis kohale. Ebaõnnestus tagasitee ja ebaõnnestunud seade on tavaliselt LAN-i lüüs, mitte VPN-host. Vastupaketi jälgimine selgitab kogu seda sümptomite klassi.

Järgige vastust, mitte päringut

VPN-server dekrüpteerib kliendi paketi ja edastab selle LAN-i, kliendi aadress jääb allika väljale. Sihtkoha host vastab sellele aadressile ja nüüd otsustab kõik tema enda marsruutimistabel. Tema vaikelüüs ei tea tunnelite basseinist midagi, seega lahkub vastus internetiteenuse pakkuja poole ja visatakse sellel teel kuskil ära.

Kliendil on sümptomiks vaikne aegumine: ei keeldumist, ei lähtestamist, lihtsalt mitte midagi. Jagatud kausta sirvimine jääb rippuma, ping teatab, et vastust ei ole, ja serveri logid näivad terved, sest server tegi oma töö.

Pange tagasitee sinna, kuhu hostid vaatavad

Iga LAN-i host küsib oma vaikelüüsi käest, seega on lüüs ainus seade, mis peab teadma, kus tunnelite bassein asub. Lisage sinna staatiline marsruut ja iga host pärib õige tee ilma puutumata.

Kui lüüs jagab oma aadressi DHCP-valikuna, levitage marsruuti nii, et uued masinad võtaksid selle automaatselt üles. Muidu elab marsruut ühes konfiguratsioonifailis ja kaob järgmisel ülesehitamisel.

# 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

Miks lähtekomponendi NAT seda näiliselt parandab

Kliendibasseini maskeerimine VPN-serveri aadressi taha kõrvaldab probleemi, eemaldades paketist kliendi aadressi. Vastused tulevad siis tagasi serverisse, mis juba teab, kuidas tunnelini jõuda, ja kõik töötab. Hind on see, et sisemised hostid ei näe enam, kes klient on, ja iga ühendus näib pärinevat ühest masinast.

See vahetus on mõnikord õige, näiteks kui tarnija seadmele ei saa staatilist marsruuti anda. Ärge tehke reeglit praegusest basseinist laiemaks, sest /24 jaoks kirjutatud reegel lakkab sobimast päeval, mil bassein nummerdatakse ümber /16-ks, ja esimene märk on hulk uusi kliente, kes ühenduvad ja ei jõua kuhugi.

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

Pilvetee nõuab kolme seadistust

VPC-s naaseb sama lünk teisel kujul, sest alamvõrgul ei ole kliendivahemiku jaoks üldse marsruuti. Marsruutimistabel vajab kirjet tunnelite basseini jaoks, mis suunab eksemplari võrguliidesele, ja liidesel tuleb allika ning sihtkoha kontroll välja lülitada, et platvorm võtaks vastu pakette, mille allikas ei ole tema enda aadress. Turvagrupid ja võrgu-ACL-id peavad samuti basseini mõlemas suunas lubama.

Iga väljajätmine tekitab eraldi osalise tõrke. Jätke marsruutimistabeli kirje vahele ja privaatsed eksemplarid vastavad alamvõrku, mis ei suuda vastust basseini tagasi kanda. Kui kontroll on endiselt sees, viskab platvorm vastuse ära pärast seda, kui eksemplar on selle juba saatnud. Ilma turvagrupi reeglita ei jõua päring ise kunagi kohale ja klient näeb aegumist ühe kihi võrra varem.

Tehke kontrollid selles järjekorras

Kinnitage edastamine ja filtreerimispoliitika enne marsruutimise süüdistamist, sest host, mis ei edasta, ebaõnnestub samamoodi vaikselt. Seejärel lugege liidesel, mis tunnelit kannab, kehtivat pöördtee seadistust, kuna range filter võib ära visata vastuseid, mis saabuvad ootamatust suunast.

Lõpetage salvestisega LAN-i hostil, kui klient seda pingib. Päring, mis saabub ilma vastava vastuseta, tõestab tagasiteed, ja päring, mis ei saabu kunagi, viib süü tagasi serveri või tunneli juurde.

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

Allika ja sihtkoha kontroll on dokumenteeritud elastse võrguliidese juhendis. Seadistage see liidesel, mis tegelikult tunneliliiklust kannab, mitte samasse eksemplari kinnitatud kõrvalisel adapteril.