Hvorfor din VPN-tunneladresse ikke åbner en indgående port
En tunneladresse identificerer din klient over for peers, der kan route til den, og opretter aldrig en lytter. Kontrollér bindingen, returruten og derefter politikken.
Forbind til kontorets VPN, start en lille tjeneste på port 8443, send tunneladressen til en kollega, og se forbindelsen fejle, mens klienten stadig rapporterer, at den er forbundet. Intet er i stykker i tunnelen: adressen er udleveret, sessionen er oppe, og de pakker, der skulle bære svaret, bliver simpelthen aldrig godkendt. Udfør de tre kontroller nedenfor i rækkefølge, og stands ved den, der fejler, fordi hver har sin egen rettelse, og kun én af dem handler om VPN.
Begynd med, hvor socketen faktisk er bundet
Før noget routes, skal noget lytte på en adresse, som den kaldende kan nå. Udviklingsservere er den sædvanlige synder, fordi mange af dem som standard binder til loopback og kun accepterer forbindelser, der stammer fra samme maskine. En tunneladresse ændrer ikke den binding, og operativsystemet vil afvise forbindelsen længe før, VPN er involveret.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Læs kolonnen for den lokale adresse frem for tilstanden. 127.0.0.1:8443 betyder kun loopback, og rettelsen er en binding til 0.0.0.0 eller til selve tunneladressen. 0.0.0.0:8443 accepterer på alle grænseflader, hvilket er bredere, end de fleste tilsigter, når maskinen også har en offentlig adresse; 10.64.7.15:8443 er den smalle version, der kun lytter, hvor kollegaen kan nå den. Læg også mærke til procesnavnet i samme output, fordi en fremmed instans fra en tidligere test er en hyppig årsag til, at porten ser åben ud og svarer med det forkerte indhold.
Spørg derefter, om noget kan route til den adresse
En tunneladresse er kun meningsfuld for peers, der er konfigureret til at sende det præfiks ind i tunnelen. Kollegaens maskine har sin egen tabel, og medmindre den har en rute til tunnelsubnettet, går pakken til standardgatewayen og dør på et sted, der ikke aner, at adressen findes. Det er et routing-spørgsmål på den kaldendes side, ikke en tilladelse på din.
| 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 mellem de to klienter betyder lige så meget. I det sædvanlige fjernadgangsdesign åbner hver klient en udgående forbindelse til gatewayen, og gatewayen holder tilstand for disse flows, så svar kommer tilbage ad en vej, den allerede kender. En forbindelse fra én klient til en anden er et nyt flow, som gatewayen skal acceptere og videresende, og mange udrulninger slår det bevidst fra for at holde klienterne isoleret fra hinanden. Forbruger-VPN-tjenester isolerer normalt som standard; virksomhedsgateways tillader det nogle gange pr. gruppe.
Kontrollér retningen, før du ændrer noget på værten. Hvis tunneladressen svarer fra gatewayen selv men ikke fra en peer, er forskellen gatewayens indstilling for klient-til-klient, og ingen redigering af den lokale firewall kan erstatte den.
Find til sidst den politik, der tillader flowet
Tre politiklag ligger mellem en routet pakke og en tjeneste, der svarer: VPN-serverens videresendelsesbeslutning, værtsfirewallen og enhver cloud-sikkerhedsgruppe foran instansen. Alle tre skal være enige, og de fejler på forskellige måder, og derfor er symptomet i tabellen ovenfor mere nyttigt end fejlmeddelelsen i browseren.
Værtsfirewallen er det lag, folk glemmer efter en vellykket binding, fordi en regel, der tillader porten på LAN-grænsefladen, ikke automatisk tillader den på tunnelgrænsefladen. Regler begrænset til en grænseflade er korrekt design og også den sædvanlige årsag til en tjeneste, der virker fra kontoret og ikke fra hjemmet. Læs reglens omfang frem for dens portnummer.
Stateful filtrering forklarer det omvendte tilfælde. En udgående forbindelse fra din bærbare skaber tilstand, og svar på den godkendes uden en indgående regel. Kollegaens forbindelse er et helt nyt flow uden tilstand bag sig, så det kræver en udtrykkelig tilladelse. Den asymmetri er hele grunden til, at en fungerende browsersession på din egen maskine intet siger om, hvorvidt tjenesten kan nås udefra.
Når én kontrol fejler, ændr designet i stedet for tunnelen
Hvis kravet er, at en kollega skal åbne din lokale tjeneste, er det ærlige svar som regel en mekanisme bygget til indgående adgang. En omvendt SSH-tunnel er den mindste: din maskine forbinder udgående til en vært, som kollegaen allerede kan nå, og lytteren findes på den vært.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Relæet kræver GatewayPorts clientspecified i sin SSH-serverkonfiguration, ellers binder den videresendte lytter til loopback på relæet, og kollegaen møder samme afvisning som før. Til alt, der holder længere end en eftermiddag, er en lastbalancer eller ingress med sundhedstjek og certifikat til det offentliggjorte navn det bedre værktøj, og en tunnel fra site til site med ruter til begge subnets er det rigtige svar, når to netværk virkelig skal tale sammen.
Hvert af disse designs gør eksponeringen eksplicit, og det er pointen. En VPN flytter pakker mellem netværk, du allerede var autoriseret til at bruge; den publicerer ikke en tjeneste og forvandler ikke en bærbar til en vært vendt mod internettet. Opgaven er at afgøre, hvilket af de tre lag der skal ændres, og tunnelen er sjældent et af dem.