VPN-tunnel maakt nooit verbinding: waar de pakketten echt stoppen

De client blijft het opnieuw proberen, het logboek stopt voordat de handshake voltooid is, en de server registreert helemaal niets. Dat patroon wijst weg van inloggegevens en naar het pad: iets tussen de twee uiteinden weigert het protocol te dragen dat de tunnel nodig heeft. Bepaal waar de pakketten stoppen voordat u een van beide configuraties aanraakt, want een gefilterd protocol en een verkeerd wachtwoord geven in de meeste clients dezelfde vriendelijke fout. De tests zijn op kosten geordend, de goedkoopste eerst.

Bewijs waar het verkeer stopt

Leg tegelijkertijd vast op de uitgaande interface van de client en op de server. Vergelijk wat vertrok met wat aankwam, en noteer in welke richting het verschil verschijnt.

Niets op de server betekent dat het pad of de eerste NAT verkeer laat vallen, terwijl aankomsten zonder antwoorden wijzen op een firewall op de server of een retourroute die niet bestaat. Een router die vaak tunnels beëindigt, houdt zelden een bruikbaar logboek bij, dus de opname wordt het verslag. Noteer de doelpoort en het protocolnummer, want beide fouten zien er in een clientdialoog hetzelfde uit.

PPTP sterft zonder protocol 47

PPTP draagt besturing over TCP 1723 en zijn gegevens in GRE, dat IP-protocol 47 is en geen poortnummer. Alleen 1723 doorsturen levert het klassieke resultaat: de verbinding authenticeert en wordt dan stil, omdat er geen regel bestaat voor het protocol dat de payload draagt. De client kan dat niet van een geweigerd wachtwoord onderscheiden, daarom moet de opname vóór de configuratiewijzigingen komen.

Passthrough loopt in de tegenovergestelde richting van een inkomende doorstuur, en firmware gebruikt vaak genoeg één label voor beide om iedereen in de war te brengen. Op een Linux-client kan de lokale firewall GRE lang voordat de router erbij betrokken is, laten vallen, dus protocol 47 heeft zijn eigen regel nodig en de conntrack-helper moet geladen zijn. Ubuntus ufw bewaart die regels in het before-bestand, omdat gewone allow-regels geen protocolnummer kunnen uitdrukken. Herlaad daarna de firewall in plaats van de machine opnieuw op te starten.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP en IPsec achter twee NAT's

L2TP binnen IPsec heeft UDP 500 nodig voor de sleuteluitwisseling, UDP 4500 zodra NAT wordt gedetecteerd, en ESP als protocol 50. Elk daarvan wordt afzonderlijk gefilterd, dus een regel die er één toestaat bewijst niets over de andere twee. Twee routers in serie vertalen elk pakket twee keer, en de uiteinden zijn het niet meer eens over wat er is onderhandeld.

Brug de buitenste modem, of schakel NAT uit op de binnenste router, zodat het openbare adres het apparaat bereikt dat de tunnel beëindigt. Waar geen van beide mogelijk is, moet de tunnel van binnen de dubbele NAT-grens worden gestart, niet daar worden beëindigd.

Mobiele netwerken en gedeelde adressen

Een WAN-adres binnen 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 of 100.64.0.0/10 betekent dat de router geen openbaar adres heeft en geen inkomende doorstuur van internet hem kan bereiken. Carrier-grade NAT filtert bovendien protocollen die het niet verwacht, en GRE is op mobiele verbindingen een veelvoorkomend slachtoffer. Vergelijk het WAN-adres op de router zelf, niet het adres dat een opzoeksite voor een client erachter meldt.

Dezelfde router op een bekabelde lijn draaien scheidt een carrierbevinding in één test van een configuratiefout. Waar de carrier het protocol weigert, zijn de overgebleven opties een ander transport op 443 of een tunnel die van binnenuit wordt gestart.

Lees de lijst met luisteraars voordat u poorten sluit

Een alarmerende poortscan is vaak alleen de functieset die standaard actief is. Inventariseer de luisteraars, koppel elke socket aan een functie en schakel dan de functie uit in plaats van de poort te blokkeren, zodat de twee weergaven niet uit elkaar lopen.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

De standaardwaarden van SoftEther zijn een goed voorbeeld: TCP 443, 992 en 5555, waarbij de functies L2TP/IPsec en DNS-tunnel hun eigen sockets toevoegen. Die functies uitschakelen verwijdert de luisteraars in plaats van ze te verbergen, en de test vanaf een externe host vertelt of de carrier de poort überhaupt doorlaat. Een luisteraar die lokaal antwoordt, kan stroomopwaarts nog steeds gesloten zijn, dus vergelijk het eigen WAN-adres van de router met wat een externe dienst meldt.