Rutet VPN-klient når serveren, men ikke LAN-vertene

Tunnelen kommer opp, klienten pinger VPN-serveren, og en delt mappe på en maskin ett hopp lenger borte svarer aldri. Ingenting i klientkonfigurasjonen forklarer det, for forespørselen forlot faktisk klienten og ankom faktisk. Det som sviktet, er turen tilbake, og enheten som sviktet, er vanligvis LAN-gatewayen og ikke VPN-verten. Sporing av svarpakken forklarer hele denne klassen av symptomer.

Følg svaret, ikke forespørselen

VPN-serveren dekrypterer klientpakken og videresender den til LAN-et med klientadressen fortsatt i kildefeltet. Destinasjonsverten svarer på den adressen, og nå bestemmer dens egen rutetabell alt. Standardgatewayen vet ingenting om tunnelbassenget, så svaret forlater mot internettleverandøren og kastes et sted på den veien.

På klienten er symptomet en stille tidsavbrudd: ingen avvisning, ingen tilbakestilling, bare ingenting. Bla gjennom en delt mappe henger, ping rapporterer ingen svar, og serverloggene ser sunne ut fordi serveren gjorde jobben sin.

Legg returruten der vertene ser

Hver LAN-vert spør sin standardgateway, så gatewayen er den eneste enheten som må vite hvor tunnelbassenget ligger. Legg til en statisk rute der, og hver vert arver den riktige veien uten å bli rørt.

Hvis gatewayen deler ut sin egen adresse som et DHCP-alternativ, distribuer ruten på den måten slik at nye maskiner tar den opp automatisk. Ellers lever ruten i én konfigurasjonsfil og forsvinner ved neste gjenoppbygging.

# 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 kilde-NAT ser ut til å reparere det

Maskering av klientbassenget bak VPN-serverens adresse fjerner problemet ved å fjerne klientadressen fra pakken. Svarene kommer da tilbake til serveren, som allerede vet hvordan den når tunnelen, og alt fungerer. Prisen er at interne verter ikke lenger kan se hvem klienten er, og hver tilkobling ser ut til å komme fra én maskin.

Den byttehandelen er noen ganger riktig, for eksempel når en leverandørenhet ikke kan få en statisk rute. Ikke gjør regelen bredere enn det nåværende bassenget, for en regel skrevet for et /24 slutter å passe den dagen bassenget omnummereres til et /16, og det første tegnet er en gruppe nye klienter som kobler til og ikke når noe.

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

Skyveien trenger tre innstillinger

I en VPC kommer den samme mangelen tilbake i en annen form, fordi subnettet ikke har noen rute for klientområdet i det hele tatt. Rutetabellen trenger en oppføring for tunnelbassenget som peker på instansens nettverksgrensesnitt, og grensesnittet må ha kilde- og destinasjonskontrollen slått av slik at plattformen godtar pakker hvis kilde ikke er dens egen adresse. Sikkerhetsgrupper og nettverks-ACL-er må også slippe bassenget gjennom i begge retninger.

Hver utelatelse gir en egen delvis feil. Hopp over oppføringen i rutetabellen, og private instanser svarer inn i et subnett som ikke kan bære svaret tilbake til bassenget. Med kontrollen fortsatt på kaster plattformen svaret etter at instansen allerede har sendt det. Uten sikkerhetsgrupperegelen kommer selve forespørselen aldri fram, og klienten ser tidsavbruddet ett lag tidligere.

Kjør kontrollene i denne rekkefølgen

Bekreft videresending og filterpolicyen før du klandrer rutingen, for en vert som ikke vil videresende, svikter på samme stille måte. Les deretter den gjeldende innstillingen for omvendt vei på grensesnittet som bærer tunnelen, siden et strengt filter kan kaste svar som kommer fra en uventet retning.

Avslutt med en opptak på LAN-verten mens klienten pinger den. En forespørsel som ankommer uten et samsvarende svar, beviser returveien, og en forespørsel som aldri ankommer, flytter feilen tilbake 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 av kilde og destinasjon er dokumentert i veiledningen for elastiske nettverksgrensesnitt. Sett den på grensesnittet som faktisk bærer tunneltrafikken, ikke på en uvedkommende adapter knyttet til den samme instansen.