VPN-tunneln ansluter aldrig: var paketen faktiskt stannar

Klienten fortsätter att försöka igen, loggen stannar innan handskakningen slutförs, och servern registrerar ingenting alls. Det mönstret pekar bort från inloggningsuppgifterna och mot vägen: något mellan de två ändarna vägrar att bära det protokoll som tunneln behöver. Bestäm var paketen stannar innan du rör någon av de två konfigurationerna, eftersom ett filtrerat protokoll och ett felaktigt lösenord ger samma vänliga fel i de flesta klienter. Testerna är ordnade efter kostnad, den billigaste först.

Bevisa var trafiken stannar

Fånga samtidigt på klientens utgående gränssnitt och på servern. Jämför det som lämnade med det som kom fram, och notera i vilken riktning skillnaden syns.

Ingenting på servern betyder att vägen eller den första NAT:en släpper trafiken, medan ankomster utan svar pekar på en brandvägg på servern eller en returväg som inte finns. En router som ofta avslutar tunnlar för sällan en användbar logg, så fångsten blir registreringen. Skriv ned målporten och protokollnumret, eftersom båda felen ser likadana ut i en klientdialog.

PPTP dör utan protokoll 47

PPTP bär kontroll på TCP 1723 och sina data inuti GRE, som är IP-protokoll 47 och inte ett portnummer. Att vidarebefordra bara 1723 ger det klassiska resultatet: anslutningen autentiserar och blir sedan tyst, eftersom det inte finns någon regel för det protokoll som bär nyttolasten. Klienten kan inte skilja det från ett avvisat lösenord, därför måste fångsten komma före konfigurationsändringarna.

Passthrough går i motsatt riktning mot en inkommande vidarebefordran, och firmware använder ofta nog samma etikett för båda för att förvirra alla. På en Linux-klient kan den lokala brandväggen släppa GRE långt innan routern är inblandad, så protokoll 47 behöver sin egen regel och conntrack-hjälparen måste vara laddad. Ubuntus ufw håller dessa regler i before-filen, eftersom vanliga allow-regler inte kan uttrycka ett protokollnummer. Ladda sedan om brandväggen i stället för att starta om maskinen.

# /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 och IPsec bakom två NAT

L2TP inuti IPsec behöver UDP 500 för nyckelutbytet, UDP 4500 när NAT upptäcks, och ESP som protokoll 50. Var och en av dem filtreras separat, så en regel som tillåter en bevisar ingenting om de andra två. Två routrar i serie översätter varje paket två gånger, och ändpunkterna är inte längre överens om vad som förhandlades.

Brygga det yttre modemet, eller stäng av NAT på den inre routern, så att den offentliga adressen når enheten som avslutar tunneln. Där ingen av dem är möjlig måste tunneln initieras inifrån den dubbla NAT-gränsen, inte avslutas där.

Mobilnät och delade adresser

En WAN-adress inom 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 eller 100.64.0.0/10 betyder att routern inte har någon offentlig adress och att ingen inkommande vidarebefordran från internet kan nå den. Carrier-grade NAT filtrerar dessutom protokoll som det inte förväntar sig, och GRE är ett vanligt offer på mobila länkar. Jämför WAN-adressen på själva routern, inte adressen som en slagningstjänst anger för en klient bakom den.

Att köra samma router på en kabelansluten linje skiljer ett operatörsfynd från ett konfigurationsfel i ett enda test. Där operatören vägrar protokollet är de återstående valen en annan transport på 443 eller en tunnel som startas inifrån.

Läs lyssnarlistan innan du stänger portar

En alarmerande portskanning är ofta bara den funktionsuppsättning som levereras aktiverad. Inventera lyssnarna, koppla varje socket till en funktion och stäng sedan av funktionen i stället för att blockera porten, så att de två vyerna inte glider isär.

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

SoftEthers standardvärden är ett bra exempel: TCP 443, 992 och 5555, där funktionerna L2TP/IPsec och DNS-tunnel lägger till egna sockets. Att stänga av dessa funktioner tar bort lyssnarna i stället för att dölja dem, och provet från en extern värd säger om operatören släpper igenom porten alls. En lyssnare som svarar lokalt kan fortfarande vara stängd längre upp, så jämför routerns egen WAN-adress med vad en extern tjänst rapporterar.