Routad VPN-klient når servern men inte LAN-värdarna

Tunneln kommer upp, klienten pingar VPN-servern, och en delad mapp på en maskin ett hopp bort svarar aldrig. Inget i klientkonfigurationen förklarar det, för begäran lämnade faktiskt klienten och kom faktiskt fram. Det som misslyckades var resan tillbaka, och enheten som misslyckades är oftast LAN-gatewayen och inte VPN-värden. Spårning av svarspaketet förklarar hela den här klassen av symtom.

Följ svaret, inte begäran

VPN-servern dekrypterar klientpaketet och vidarebefordrar det till LAN:et med klientadressen kvar i källfältet. Destinationsvärden svarar på den adressen, och nu avgör dess egen routingtabell allt. Dess standardgateway vet inget om tunnelpoolen, så svaret går mot internetleverantören och kastas någonstans på den vägen.

På klienten är symtomet en tyst tidsgräns: ingen avvisning, ingen återställning, bara ingenting. Bläddring i en delad mapp hänger, ping rapporterar inget svar, och serverloggarna ser friska ut eftersom servern gjorde sitt jobb.

Lägg returvägen där värdarna tittar

Varje LAN-värd frågar sin standardgateway, så gatewayen är den enda enheten som behöver veta var tunnelpoolen finns. Lägg till en statisk väg där och varje värd ärver den korrekta vägen utan att röras.

Om gatewayen delar ut sin egen adress som DHCP-alternativ, distribuera vägen på det sättet så att nya maskiner tar upp den automatiskt. Annars lever vägen i en konfigurationsfil och försvinner vid nästa ombyggnad.

# 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

Varför käll-NAT verkar reparera det

Maskering av klientpoolen bakom VPN-serverns adress tar bort problemet genom att ta bort klientadressen från paketet. Svaren kommer då tillbaka till servern, som redan vet hur den når tunneln, och allt fungerar. Priset är att interna värdar inte längre kan se vem klienten är, och varje anslutning ser ut att komma från en enda maskin.

Det bytet är ibland korrekt, till exempel när en leverantörsenhet inte kan få en statisk väg. Gör inte regeln bredare än den nuvarande poolen, för en regel skriven för ett /24 slutar passa den dag poolen numreras om till ett /16, och det första tecknet är en grupp nya klienter som ansluter och inte når något.

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

Molnvägen kräver tre inställningar

I ett VPC återkommer samma lucka i en annan form, eftersom subnätet inte har någon väg för klientintervallet alls. Routingtabellen behöver en post för tunnelpoolen som pekar på instansens nätverksgränssnitt, och gränssnittet måste ha käll- och destinationskontrollen avstängd så att plattformen accepterar paket vars källa inte är dess egen adress. Säkerhetsgrupper och nätverks-ACL:er måste också släppa igenom poolen i båda riktningarna.

Varje utelämnande ger ett eget delvis fel. Hoppa över posten i routingtabellen och privata instanser svarar in i ett subnät som inte kan bära svaret tillbaka till poolen. Med kontrollen fortfarande på kastar plattformen svaret efter att instansen redan har skickat det. Utan säkerhetsgruppsregeln kommer själva begäran aldrig fram, och klienten ser tidsgränsen ett lager tidigare.

Kör kontrollerna i denna ordning

Bekräfta vidarebefordran och filterpolicyn innan du skyller på routingen, för en värd som inte vidarebefordrar misslyckas på samma tysta sätt. Läs sedan den gällande inställningen för omvänd väg på gränssnittet som bär tunneln, eftersom ett strikt filter kan kasta svar som kommer från en oväntad riktning.

Avsluta med en inspelning på LAN-värden medan klienten pingar den. En begäran som kommer in utan ett matchande svar bevisar returvägen, och en begäran som aldrig kommer in flyttar felet tillbaka till servern eller tunneln.

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

Kontrollen av källa och destination är dokumenterad i guiden för elastiska nätverksgränssnitt. Ställ in den på gränssnittet som faktiskt bär tunneltrafiken, inte på en orelaterad adapter kopplad till samma instans.