Rutet VPN-klient når serveren, men ikke LAN-værterne

Tunnelen kommer op, klienten pinger VPN-serveren, og en delt mappe på en maskine et hop længere væk svarer aldrig. Intet i klientens konfiguration forklarer det, for anmodningen forlod faktisk klienten og ankom faktisk. Det, der fejlede, er turen tilbage, og den enhed, der fejlede, er normalt LAN-gatewayen og ikke VPN-værten. Sporing af svarpakken forklarer hele denne klasse af symptomer.

Følg svaret, ikke anmodningen

VPN-serveren dekrypterer klientpakken og videresender den til LAN'et med klientadressen stadig i kildefeltet. Destinationsværten svarer på den adresse, og nu bestemmer dens egen rutetabel alt. Dens standardgateway ved intet om tunnelpuljen, så svaret forlader mod internetudbyderen og kasseres et sted på den vej.

På klienten er symptomet en tavs timeout: ingen afvisning, ingen nulstilling, bare ingenting. En gennemgang af en delt mappe hænger, en ping rapporterer intet svar, og serverloggene ser sunde ud, fordi serveren gjorde sit arbejde.

Læg returruten der, hvor værterne kigger

Hver LAN-vært spørger sin standardgateway, så gatewayen er den eneste enhed, der skal vide, hvor tunnelpuljen bor. Tilføj en statisk rute der, og hver vært arver den korrekte vej uden at blive rørt.

Hvis gatewayen uddeler sin egen adresse som en DHCP-indstilling, så distribuér ruten på den måde, så nye maskiner tager den op automatisk. Ellers bor ruten i én konfigurationsfil og forsvinder ved næste genopbygning.

# 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

Hvorfor Source NAT ser ud til at reparere det

Maskering af klientpuljen bag VPN-serverens adresse fjerner problemet ved at fjerne klientadressen fra pakken. Svarene kommer så tilbage til serveren, som allerede ved, hvordan tunnelen nås, og alt virker. Prisen er, at interne værter ikke længere kan se, hvem klienten er, og hver forbindelse ser ud til at komme fra én maskine.

Den byttehandel er nogle gange rigtig, for eksempel når en leverandørs enhed ikke kan få en statisk rute. Gør reglen ikke bredere end den nuværende pulje, for en regel skrevet til et /24 holder op med at passe den dag, puljen omnummereres til et /16, og det første tegn er en bunke nye klienter, der forbinder og ikke når noget.

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

Cloudvejen kræver tre indstillinger

I en VPC vender den samme mangel tilbage i en anden form, fordi undernettet slet ikke har nogen rute til klientområdet. Rutetabellen skal have en post for tunnelpuljen, der peger på instansens netværksgrænseflade, og grænsefladen skal have slået kontrol af kilde og destination fra, så platformen accepterer pakker, hvis kilde ikke er dens egen adresse. Sikkerhedsgrupper og netværks-ACL'er skal også lukke puljen ind i begge retninger.

Hver udeladelse giver en særskilt delvis fejl. Spring rutetabellens post over, og private instanser svarer ind i et undernet, der ikke kan bære svaret tilbage til puljen. Med kontrollen stadig slået til kasserer platformen svaret, efter at instansen allerede har sendt det. Uden sikkerhedsgruppereglen ankommer anmodningen slet ikke, og klienten ser timeouten et lag tidligere.

Kør kontrollerne i denne rækkefølge

Bekræft videresendelse og filterpolitikken, før du bebrejder routing, for en vært, der ikke vil videresende, fejler på samme tavse måde. Læs derefter den effektive indstilling for omvendt sti på den grænseflade, der bærer tunnelen, da et strengt filter kan kassere svar, der ankommer fra en uventet retning.

Afslut med en optagelse på LAN-værten, mens klienten pinger den. En anmodning, der ankommer uden et matchende svar, beviser returvejen, og en anmodning, der aldrig ankommer, flytter fejlen tilbage til serveren eller tunnelen.

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

Kontrollen af kilde og destination er dokumenteret i vejledningen om elastiske netværksgrænseflader. Sæt den på den grænseflade, der faktisk bærer tunneltrafikken, ikke på en uvedkommende adapter, der er knyttet til den samme instans.