Ruta VPN-klient når tenaren, men ikkje LAN-vertane

Tunnelen kjem opp, klienten pingar VPN-tenaren, og ei delt mappe på ein maskin eitt hopp lenger borte svarar aldri. Ingenting i klientkonfigurasjonen forklarar det, for førespurnaden forlét faktisk klienten og kom faktisk fram. Det som svikta, er turen tilbake, og eininga som svikta, er vanlegvis LAN-gatewayen og ikkje VPN-verten. Sporing av svarpakken forklarar heile denne klassen av symptom.

Følg svaret, ikkje førespurnaden

VPN-tenaren dekrypterer klientpakken og sender han vidare til LAN-et med klientadressa framleis i kjeldefeltet. Destinasjonsverten svarar på den adressa, og no avgjer hans eigen rutetabell alt. Standardgatewayen hans veit ingenting om tunnelbassenget, så svaret går mot internettleverandøren og blir kasta ein stad på den vegen.

På klienten er symptomet ein stille tidsavbrot: inga avvising, inga tilbakestilling, berre ingenting. Bla gjennom ei delt mappe heng, ping rapporterer ingen svar, og tenarloggane ser sunne ut fordi tenaren gjorde jobben sin.

Legg returruta der vertane ser

Kvar LAN-vert spør sin standardgateway, så gatewayen er den einaste eininga som må vita kvar tunnelbassenget ligg. Legg til ei statisk rute der, og kvar vert arvar den rette vegen utan å bli rørt.

Viss gatewayen deler ut si eiga adresse som eit DHCP-alternativ, distribuer ruta på den måten slik at nye maskinar tek henne opp automatisk. Elles lever ruta i éi konfigurasjonsfil og forsvinn 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

Kvifor kjelde-NAT ser ut til å reparera det

Maskering av klientbassenget bak adressa til VPN-tenaren fjernar problemet ved å fjerna klientadressa frå pakken. Svara kjem då tilbake til tenaren, som allereie veit korleis han når tunnelen, og alt fungerer. Prisen er at interne vertar ikkje lenger kan sjå kven klienten er, og kvar tilkopling ser ut til å koma frå éin maskin.

Den byttehandelen er nokre gonger rett, til dømes når ei leverandøreining ikkje kan få ei statisk rute. Ikkje gjer regelen breiare enn det noverande bassenget, for ein regel skriven for eit /24 sluttar å passa den dagen bassenget blir omnummerert til eit /16, og det første teiknet er ei gruppe nye klientar som koplar til og ikkje når noko.

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

Skyvegen treng tre innstillingar

I ein VPC kjem den same mangelen tilbake i ei anna form, fordi subnettet ikkje har noka rute for klientområdet i det heile. Rutetabellen treng ei oppføring for tunnelbassenget som peikar på nettverksgrensesnittet til instansen, og grensesnittet må ha kjelde- og destinasjonskontrollen slått av slik at plattformen godtek pakkar kjelda ikkje er hans eigen adresse. Tryggingsgrupper og nettverks-ACL-ar må også sleppa bassenget gjennom i båe retningar.

Kvar utelating gir ein eigen delvis feil. Hopp over oppføringa i rutetabellen, og private instansar svarar inn i eit subnett som ikkje kan bera svaret tilbake til bassenget. Med kontrollen framleis på kastar plattformen svaret etter at instansen allereie har sendt det. Utan tryggingsgrupperegelen kjem sjølve førespurnaden aldri fram, og klienten ser tidsavbrotet eitt lag tidlegare.

Køyr kontrollane i denne rekkjefølgja

Stadfest vidaresending og filterpolitikken før du klandrar rutinga, for ein vert som ikkje vil vidaresenda, sviktar på same stille måten. Les deretter den gjeldande innstillinga for omvendt veg på grensesnittet som ber tunnelen, sidan eit strengt filter kan kasta svar som kjem frå ei uventa retning.

Avslutt med eit opptak på LAN-verten medan klienten pingar han. Ein førespurnad som kjem utan eit samsvarande svar, provar returvegen, og ein førespurnad som aldri kjem, flyttar feilen tilbake til tenaren 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 kjelde og destinasjon er dokumentert i rettleiinga for elastiske nettverksgrensesnitt. Set han på grensesnittet som faktisk ber tunneltrafikken, ikkje på ein uvedkomande adapter knytt til den same instansen.