VPN-tunnel kobler aldri til: hvor pakkene faktisk stopper

Klienten fortsetter å prøve på nytt, loggen stopper før håndtrykket er fullført, og serveren registrerer ingenting i det hele tatt. Det mønsteret peker bort fra påloggingsinformasjon og mot veien: noe mellom de to endene nekter å bære protokollen tunnelen trenger. Avgjør hvor pakkene stopper før du rører noen av de to konfigurasjonene, fordi en filtrert protokoll og et feil passord gir den samme vennlige feilen i de fleste klienter. Testene er ordnet etter kostnad, den billigste først.

Bevis hvor trafikken stopper

Ta opp samtidig på klientens utgående grensesnitt og på serveren. Sammenlign det som gikk ut, med det som kom inn, og noter hvilken retning forskjellen vises i.

Ingenting på serveren betyr at veien eller den første NAT-en dropper trafikk, mens ankomster uten svar peker på en brannmur på serveren eller en returrute som ikke finnes. En ruter som ofte avslutter tunneler, fører sjelden en nyttig logg, så opptaket blir registreringen. Skriv ned destinasjonsporten og protokollnummeret, fordi begge feilene ser like ut i en klientdialog.

PPTP dør uten protokoll 47

PPTP bærer kontroll på TCP 1723 og dataene sine inne i GRE, som er IP-protokoll 47 og ikke et portnummer. Å videresende bare 1723 gir det klassiske resultatet: forbindelsen autentiserer og blir så stille, fordi det ikke finnes noen regel for protokollen som bærer nyttelasten. Klienten kan ikke skille det fra et avvist passord, derfor må opptaket komme før konfigurasjonsendringene.

Passthrough går i motsatt retning av en innkommende videresending, og fastvaren bruker ofte nok én etikett for begge til å forvirre alle. På en Linux-klient kan den lokale brannmuren droppe GRE lenge før ruteren er involvert, så protokoll 47 trenger sin egen regel, og conntrack-hjelperen må være lastet. Ubuntus ufw holder disse reglene i before-filen, fordi vanlige allow-regler ikke kan uttrykke et protokollnummer. Last brannmuren på nytt etterpå i stedet for å starte maskinen på nytt.

# /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 bak to NAT-er

L2TP inne i IPsec trenger UDP 500 for nøkkelutvekslingen, UDP 4500 når NAT oppdages, og ESP som protokoll 50. Hver av dem filtreres uavhengig, så en regel som tillater én beviser ingenting om de to andre. To rutere i serie oversetter hver pakke to ganger, og endepunktene er ikke lenger enige om hva som ble forhandlet.

Bro det ytre modemet, eller slå av NAT på den indre ruteren, slik at den offentlige adressen når enheten som avslutter tunnelen. Der ingen av delene er mulig, må tunnelen startes innenfra den doble NAT-grensen i stedet for å avsluttes der.

Mobilnett og delte adresser

En WAN-adresse innenfor 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 eller 100.64.0.0/10 betyr at ruteren ikke har noen offentlig adresse, og ingen innkommende videresending fra internett kan nå den. Carrier-grade NAT filtrerer i tillegg protokoller det ikke forventer, og GRE er et hyppig offer på mobile lenker. Sammenlign WAN-adressen på selve ruteren, ikke adressen et oppslagsted rapporterer for en klient bak den.

Å kjøre samme ruter på en kablet linje skiller et carrier-funn fra en konfigurasjonsfeil i én enkelt test. Der carrieren nekter protokollen, er de gjenværende valgene en annen transport på 443 eller en tunnel startet innenfra.

Les lyttelisten før du lukker porter

En alarmerende portskanning er ofte bare funksjonssettet som leveres aktivert. Inventer lytterne, knytt hver socket til en funksjon, og slå deretter funksjonen av i stedet for å blokkere porten, slik at de to visningene ikke glir fra hverandre.

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 standardverdier er et godt eksempel: TCP 443, 992 og 5555, der funksjonene L2TP/IPsec og DNS-tunnel legger til egne sockets. Å slå av disse funksjonene fjerner lytterne i stedet for å skjule dem, og prøven fra en ekstern vert forteller om carrieren slipper porten gjennom i det hele tatt. En lytter som svarer lokalt, kan fortsatt være lukket lenger oppe, så sammenlign ruterens egen WAN-adresse med det en ekstern tjeneste rapporterer.