Gerouteerde VPN-client bereikt de server maar niet de LAN-hosts

De tunnel komt op, de client pingt de VPN-server, en een gedeelde map op een machine één hop verder antwoordt nooit. Niets in de clientconfiguratie verklaart dat, want het verzoek heeft de client wel verlaten en is wel aangekomen. Wat faalde is de terugreis, en het apparaat dat faalde is meestal de LAN-gateway en niet de VPN-host. Het antwoordpakket volgen verklaart de hele klasse van symptomen.

Volg het antwoord, niet het verzoek

De VPN-server ontsleutelt het clientpakket en stuurt het door naar het LAN met het clientadres nog in het bronveld. De bestemmingshost antwoordt op dat adres, en nu bepaalt zijn eigen routetabel alles. Zijn standaardgateway weet niets van de tunnelpool, dus het antwoord vertrekt richting de internetprovider en wordt ergens op dat pad weggegooid.

Op de client is het symptoom een stille time-out: geen weigering, geen reset, gewoon niets. Een gedeelde map bladeren hangt, een ping meldt geen antwoord, en de serverlogs zien er gezond uit omdat de server zijn werk deed.

Zet de retourroute waar de hosts kijken

Elke LAN-host raadpleegt zijn standaardgateway, dus de gateway is het enige apparaat dat moet weten waar de tunnelpool staat. Voeg daar een statische route toe en elke host erft het juiste pad zonder te worden aangeraakt.

Als de gateway zijn eigen adres als DHCP-optie uitdeelt, verspreid de route dan op die manier zodat nieuwe machines hem automatisch overnemen. Anders leeft de route in één configuratiebestand en verdwijnt bij de volgende herbouw.

# 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

Waarom source-NAT het lijkt te repareren

Het clientpool maskeren achter het adres van de VPN-server haalt het probleem weg door het clientadres uit het pakket te halen. Antwoorden komen dan terug bij de server, die al weet hoe hij de tunnel bereikt, en alles werkt. De prijs is dat interne hosts niet meer kunnen zien wie de client is, en elke verbinding lijkt van één machine te komen.

Die ruil is soms juist, bijvoorbeeld wanneer een apparaat van een leverancier geen statische route kan krijgen. Maak de regel niet breder dan de huidige pool, want een regel die voor een /24 is geschreven, past niet meer op de dag dat de pool wordt hernummerd naar een /16, en het eerste teken is een reeks nieuwe clients die verbinden en niets bereiken.

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

Het cloudpad vereist drie instellingen

In een VPC komt dezelfde leemte in een andere vorm terug, omdat het subnet helemaal geen route voor de clientrange heeft. De routetabel heeft een vermelding nodig voor de tunnelpool die naar de netwerkinterface van de instantie wijst, en op de interface moet de bron- en bestemmingscontrole uit staan zodat het platform pakketten accepteert waarvan de bron niet zijn eigen adres is. Beveiligingsgroepen en netwerk-ACL's moeten de pool ook in beide richtingen toelaten.

Elke weglating levert een ander gedeeltelijk falen op. Sla de vermelding in de routetabel over en private instanties antwoorden in een subnet dat het antwoord niet terug naar de pool kan dragen. Met de controle nog aan gooit het platform het antwoord weg nadat de instantie het al heeft verzonden. Zonder de beveiligingsgroepregel komt het verzoek zelf nooit aan, en de client ziet de time-out een laag eerder.

Voer de controles in deze volgorde uit

Bevestig doorsturen en het filterbeleid voordat je het routeren de schuld geeft, want een host die niet doorstuurt, faalt op dezelfde stille manier. Lees daarna de effectieve instelling voor de omgekeerde route op de interface die de tunnel draagt, omdat een strikte filter antwoorden kan weggooien die uit een onverwachte richting komen.

Sluit af met een opname op de LAN-host terwijl de client die pingt. Een verzoek dat aankomt zonder bijpassend antwoord bewijst de terugweg, en een verzoek dat nooit aankomt schuift de fout terug naar de server of de tunnel.

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

De bron- en bestemmingscontrole is gedocumenteerd in de handleiding voor elastische netwerkinterfaces. Stel hem in op de interface die het tunnelverkeer werkelijk draagt, niet op een niet-verwante adapter die aan dezelfde instantie is gekoppeld.