VPN-tunnel opretter aldrig forbindelse: hvor pakkerne faktisk stopper

Klienten bliver ved med at prøve igen, loggen stopper før håndtrykket er færdigt, og serveren registrerer slet intet. Det mønster peger væk fra legitimationsoplysninger og hen på vejen: noget mellem de to ender nægter at bære den protokol, tunnelen har brug for. Afgør, hvor pakkerne stopper, før du rører nogen af de to konfigurationer, fordi en filtreret protokol og en forkert adgangskode giver den samme venlige fejl i de fleste klienter. Testene er ordnet efter pris, den billigste først.

Bevis, hvor trafikken stopper

Optag samtidig på klientens udgående interface og på serveren. Sammenlign det, der forlod, med det, der ankom, og noter, i hvilken retning forskellen viser sig.

Intet på serveren betyder, at ruten eller den første NAT dropper trafik, mens ankomster uden svar peger på en firewall på serveren eller en returrute, der ikke findes. En router, der ofte afslutter tunneler, fører sjældent en brugbar log, så optagelsen bliver registreringen. Skriv destinationsporten og protokollnummeret ned, fordi begge fejl ser ens ud i en klientdialog.

PPTP dør uden protokol 47

PPTP bærer kontrol på TCP 1723 og data inde i GRE, som er IP-protokol 47 og ikke et portnummer. Videresendelse af kun 1723 giver det klassiske resultat: forbindelsen autentificerer og bliver så tavs, fordi der ikke findes nogen regel for den protokol, der bærer nyttelasten. Klienten kan ikke skelne det fra en afvist adgangskode, og derfor skal optagelsen komme før konfigurationsændringerne.

Passthrough kører i den modsatte retning af en indgående videresendelse, og firmware bruger ofte en etiket for begge, nok til at forvirre alle. På en Linux-klient kan den lokale firewall droppe GRE længe før routeren er involveret, så protokol 47 har brug for sin egen regel, og conntrack-hjælperen skal være indlæst. Ubuntus ufw holder disse regler i before-filen, fordi almindelige allow-regler ikke kan udtrykke et protokollnummer. Genindlæs firewallen bagefter i stedet for at genstarte 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 og IPsec bag to NAT

L2TP inde i IPsec kræver UDP 500 til nøgleudvekslingen, UDP 4500 når NAT opdages, og ESP som protokol 50. Hver af dem filtreres uafhængigt, så en regel, der tillader én, beviser intet om de to andre. To routere i serie oversætter hver pakke to gange, og endepunkterne er ikke længere enige om, hvad der blev forhandlet.

Bro den ydre modem, eller slå NAT fra på den indre router, så den offentlige adresse når den enhed, der afslutter tunnelen. Hvor ingen af delene er muligt, skal tunnelen startes indefra den dobbelte NAT-grænse i stedet for at blive afsluttet der.

Mobilnetværk og delte adresser

En WAN-adresse inden for 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 eller 100.64.0.0/10 betyder, at routeren ikke har nogen offentlig adresse, og ingen indgående videresendelse fra internettet kan nå den. Carrier-grade NAT filtrerer desuden protokoller, den ikke forventer, og GRE er en hyppig taber på mobile links. Sammenlign WAN-adressen på selve routeren, ikke den adresse, et opslagssted rapporterer for en klient bag den.

At køre samme router på en kablet linje adskiller et carrier-fund fra en konfigurationsfejl i én enkelt test. Hvor carrieren afviser protokollen, er de resterende muligheder en anden transport på 443 eller en tunnel startet indefra.

Læs lytterlisten, før du lukker porte

En alarmerende portscanning er ofte bare det funktionssæt, der leveres aktiveret. Lav en fortegnelse over lytterne, knyt hver socket til en funktion, og slå derefter funktionen fra i stedet for at blokere porten, så de to billeder ikke glider fra hinanden.

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 standardindstillinger er et godt eksempel: TCP 443, 992 og 5555, hvor funktionerne L2TP/IPsec og DNS-tunnel tilføjer deres egne sockets. At slå disse funktioner fra fjerner lytterne i stedet for at skjule dem, og prøven fra en ekstern vært fortæller, om carrieren overhovedet lader porten passere. En lytter, der svarer lokalt, kan stadig være lukket længere oppe, så sammenlign routerens egen WAN-adresse med det, en ekstern tjeneste rapporterer.