Hvorfor VPN-tunneladressen din ikke åpner en innkommende port
En tunneladresse identifiserer klienten din overfor peers som kan rute dit, og oppretter aldri en lytter. Kontroller bindingen, returruten og deretter policyen.
Koble til kontorets VPN, start en liten tjeneste på port 8443, send tunneladressen til en kollega og se forbindelsen feile mens klienten fortsatt rapporterer at den er tilkoblet. Ingenting er i stykker i tunnelen: adressen er delt ut, økten er oppe, og pakkene som skulle bære svaret blir rett og slett aldri sluppet inn. Gjør de tre kontrollene nedenfor i rekkefølge og stopp ved den som feiler, fordi hver har sin egen retting og bare én av dem handler om VPN.
Begynn med hvor socketen faktisk er bundet
Før noe rutes, må noe lytte på en adresse som den som ringer kan nå. Utviklingsservere er den vanlige synderen, fordi mange av dem som standard binder til loopback og bare godtar tilkoblinger som kommer fra samme maskin. En tunneladresse endrer ikke denne bindingen, og operativsystemet vil avvise tilkoblingen lenge før VPN er involvert.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Les kolonnen for den lokale adressen i stedet for tilstanden. 127.0.0.1:8443 betyr bare loopback, og rettingen er en binding på 0.0.0.0 eller på selve tunneladressen. 0.0.0.0:8443 godtar på alle grensesnitt, noe som er bredere enn de fleste mener når maskinen også har en offentlig adresse; 10.64.7.15:8443 er den smale versjonen som bare lytter der kollegaen kan nå den. Legg også merke til prosessnavnet i samme utdata, fordi en gjenglemt instans fra en tidligere test er en vanlig årsak til at porten ser åpen ut og svarer med feil innhold.
Spør deretter om noe kan rute til den adressen
En tunneladresse er bare meningsfull for peers som er konfigurert til å sende det prefikset inn i tunnelen. Kollegaens maskin har sin egen tabell, og uten en rute til tunnelsubnettet går pakken til standardgatewayen og dør på et sted som ikke aner at adressen finnes. Dette er et rutingspørsmål på den som ringers side, ikke en tillatelse på din side.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Serveren mellom de to klientene betyr like mye. I det vanlige designet for fjernaksess åpner hver klient en utgående forbindelse til gatewayen, og gatewayen holder tilstand for disse flytene, slik at svar kommer tilbake via en vei den allerede kjenner. En forbindelse fra én klient til en annen er en ny flyt som gatewayen må godta og videresende, og mange installasjoner slår det bevisst av for å holde klientene isolert fra hverandre. Forbruker-VPN-tjenester isolerer vanligvis som standard; bedriftsgatewayer tillater det noen ganger per gruppe.
Kontroller retningen før du endrer noe på verten. Hvis tunneladressen svarer fra gatewayen selv, men ikke fra en peer, er forskjellen gatewayens innstilling for klient-til-klient, og ingen redigering av den lokale brannmuren kan erstatte den.
Finn til slutt policyen som tillater flyten
Tre policylag ligger mellom en rutet pakke og en tjeneste som svarer: VPN-serverens videresendingsbeslutning, vertens brannmur og enhver skybasert sikkerhetsgruppe foran instansen. Alle tre må være enige, og de feiler på forskjellige måter, derfor er symptomet i tabellen over mer nyttig enn feilmeldingen i nettleseren.
Vertens brannmur er laget folk glemmer etter en vellykket binding, fordi en regel som tillater porten på LAN-grensesnittet ikke automatisk tillater den på tunnelgrensesnittet. Regler begrenset til grensesnitt er riktig design og også den vanlige årsaken til en tjeneste som virker fra kontoret og ikke hjemmefra. Les regelens omfang i stedet for portnummeret.
Stateful filtrering forklarer det motsatte tilfellet. En utgående forbindelse fra laptopen din skaper tilstand, og svarene på den slippes inn uten en innkommende regel. Kollegaens forbindelse er en helt ny flyt uten tilstand bak seg, så den trenger en uttrykkelig tillatelse. Denne asymmetrien er hele grunnen til at en fungerende nettleserøkt på din egen maskin ikke sier noe om tjenesten er tilgjengelig utenfra.
Når én kontroll feiler, endre designet i stedet for tunnelen
Hvis kravet er at en kollega skal åpne den lokale tjenesten din, er det ærlige svaret vanligvis en mekanisme bygget for innkommende tilgang. En omvendt SSH-tunnel er den minste: maskinen din kobler utgående til en vert som kollegaen allerede kan nå, og lytteren finnes på den verten.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Reléet krever GatewayPorts clientspecified i SSH-serverkonfigurasjonen, ellers binder den videresendte lytteren til loopback på reléet, og kollegaen møter samme avvisning som før. For alt som varer lenger enn en ettermiddag, er en lastbalanserer eller ingress med helsesjekk og sertifikat for det publiserte navnet det bedre verktøyet, og en tunnel fra sted til sted med ruter for begge subnettene er det riktige svaret når to nettverk virkelig trenger å snakke sammen.
Hvert av disse designene gjør eksponeringen eksplisitt, og det er poenget. En VPN flytter pakker mellom nettverk du allerede var autorisert til å bruke; den publiserer ikke en tjeneste og gjør ikke en laptop til en vert vendt mot internett. Oppgaven er å avgjøre hvilket av de tre lagene som skal endres, og tunnelen er sjelden ett av dem.