VPN-tunnel koplar aldri til: kvar pakkane faktisk stoppar

Klienten held fram med å prøve på nytt, loggen stoppar før handtrykket er fullført, og tenaren registrerer ingenting i det heile. Det mønsteret peikar bort frå påloggingsinformasjon og mot vegen: noko mellom dei to endane nektar å bera protokollen tunnelen treng. Avgjer kvar pakkane stoppar før du rører nokon av dei to konfigurasjonane, fordi ein filtrert protokoll og eit feil passord gir den same venlege feilen i dei fleste klientar. Testane er ordna etter kostnad, den billegaste først.

Prov kvar trafikken stoppar

Ta opp samstundes på den utgåande grensesnittet til klienten og på tenaren. Samanlikn det som gjekk ut, med det som kom inn, og noter kva retning skilnaden viser seg i.

Ingenting på tenaren betyr at vegen eller den første NAT-en droppar trafikk, medan komande utan svar peikar på ein brannmur på tenaren eller ein returrute som ikkje finst. Ein ruter som ofte avsluttar tunnelar, fører sjeldan ein nyttig logg, så opptaket blir registreringa. Skriv ned målporten og protokollnummeret, fordi begge feila ser like ut i ein klientdialog.

PPTP døyr utan protokoll 47

PPTP ber kontroll på TCP 1723 og dataa sine inne i GRE, som er IP-protokoll 47 og ikkje eit portnummer. Å videresende berre 1723 gir det klassiske resultatet: sambandet autentiserer og blir så stille, fordi det ikkje finst noka regel for protokollen som ber nyttelasta. Klienten kan ikkje skilje det frå eit avvist passord, difor må opptaket kome før konfigurasjonsendringane.

Passthrough går i motsett retning av ei innkomande videresending, og fastvaren brukar ofte nok ei og same merkelapp for begge til å forvirre alle. På ein Linux-klient kan den lokale brannmuren droppe GRE lenge før ruteren er involvert, så protokoll 47 treng si eiga regel, og conntrack-hjelparen må vere lasta. Ubuntus ufw held desse reglane i before-fila, fordi vanlege allow-reglar ikkje kan uttrykkje eit protokollnummer. Last brannmuren på nytt etterpå i staden 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-ar

L2TP inne i IPsec treng UDP 500 for nøkkelutvekslinga, UDP 4500 når NAT blir oppdaga, og ESP som protokoll 50. Kvar av dei blir filtrert uavhengig, så ein regel som tillèt éin beviser ingenting om dei to andre. To rutarar i serie omset kvar pakke to gonger, og endepunkta er ikkje lenger samde om kva som vart forhandla.

Bro det ytre modemet, eller slå av NAT på den indre rutaren, slik at den offentlege adressa når eininga som avsluttar tunnelen. Der ingen av delane er mogleg, må tunnelen startast innanfrå den doble NAT-grensa i staden for å bli avslutta der.

Mobilnett og delte adresser

Ei WAN-adresse innanfor 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 eller 100.64.0.0/10 betyr at rutaren ikkje har noka offentleg adresse, og inga innkomande videresending frå internett kan nå henne. Carrier-grade NAT filtrerer i tillegg protokollar det ikkje ventar, og GRE er eit hyppig offer på mobile lenkjer. Samanlikn WAN-adressa på sjølve rutaren, ikkje adressa eit oppslagstad rapporterer for ein klient bak han.

Å køyre same rutar på ei kabel-linje skil eit carrier-funn frå ein konfigurasjonsfeil i éin einaste test. Der carrieren nektar protokollen, er dei attverande vala ein annan transport på 443 eller ein tunnel starta innanfrå.

Les lyttarlista før du lukkar portar

Ein alarmerande portskanning er ofte berre funksjonssettet som blir levert aktivert. Inventer lyttarane, knytt kvar socket til ein funksjon, og slå deretter funksjonen av i staden for å blokkere porten, slik at dei to visingane ikkje glid frå kvarandre.

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

Standardverdiane til SoftEther er eit godt døme: TCP 443, 992 og 5555, der funksjonane L2TP/IPsec og DNS-tunnel legg til eigne socketar. Å slå av desse funksjonane fjernar lyttarane i staden for å skjule dei, og prøven frå ein ekstern vert fortel om carrieren slepp porten gjennom i det heile. Ein lyttar som svarar lokalt, kan framleis vere lukka lenger oppe, så samanlikn den eigne WAN-adressa til rutaren med det ein ekstern teneste rapporterer.