Varför din VPN-tunneladress inte öppnar en inkommande port
En tunneladress identifierar din klient för parter som kan routa dit, och skapar aldrig en lyssnare. Kontrollera bindningen, returvägen och sedan policyn.
Anslut till kontorets VPN, starta en liten tjänst på port 8443, skicka tunneladressen till en kollega och se anslutningen misslyckas medan klienten fortfarande rapporterar att den är ansluten. Inget är trasigt i tunneln: adressen har delats ut, sessionen är uppe, och paketen som skulle bära svaret släpps helt enkelt aldrig in. Gör de tre kontrollerna nedan i ordning och stanna vid den som misslyckas, eftersom var och en har sin egen åtgärd och bara en av dem handlar om VPN.
Börja med var socketen faktiskt är bunden
Innan något routas måste något lyssna på en adress som anroparen kan nå. Utvecklingsservrar är den vanliga boven, eftersom många av dem som standard binder till loopback och bara accepterar anslutningar som kommer från samma maskin. En tunneladress ändrar inte den bindningen, och operativsystemet kommer att avvisa anslutningen långt innan VPN ens är inblandat.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Läs kolumnen för den lokala adressen i stället för tillståndet. 127.0.0.1:8443 betyder bara loopback, och åtgärden är en bindning till 0.0.0.0 eller till själva tunneladressen. 0.0.0.0:8443 accepterar på alla gränssnitt, vilket är bredare än de flesta avser när maskinen också har en offentlig adress; 10.64.7.15:8443 är den smala varianten som bara lyssnar där kollegan kan nå den. Lägg också märke till processnamnet i samma utdata, eftersom en kvarglömd instans från ett tidigare test är en vanlig orsak till att porten ser öppen ut och svarar med fel innehåll.
Fråga sedan om något kan routa till den adressen
En tunneladress är bara meningsfull för parter som är konfigurerade att skicka det prefixet in i tunneln. Kollegans maskin har sin egen tabell, och utan en väg till tunnelns subnät går paketet till standardgatewayen och dör på en plats som inte har en aning om att adressen finns. Det är en routingfråga på anroparens sida, inte en behörighet på din sida.
| 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 |
Servern mellan de två klienterna spelar lika stor roll. I det vanliga designet för fjärråtkomst öppnar varje klient en utgående anslutning till gatewayen, och gatewayen håller tillstånd för dessa flöden, så svar kommer tillbaka via en väg den redan känner. En anslutning från en klient till en annan är ett nytt flöde som gatewayen måste acceptera och vidarebefordra, och många installationer stänger av det medvetet för att hålla klienterna isolerade från varandra. Konsument-VPN-tjänster isolerar vanligen som standard; företagsgatewayer tillåter det ibland per grupp.
Kontrollera riktningen innan du ändrar något på värden. Om tunneladressen svarar från gatewayen själv men inte från en part, är skillnaden gatewayens inställning för klient-till-klient, och ingen redigering av den lokala brandväggen kan ersätta den.
Hitta till sist policyn som tillåter flödet
Tre policylager ligger mellan ett routat paket och en tjänst som svarar: VPN-serverns vidarebefordringsbeslut, värdens brandvägg och eventuell molnsäkerhetsgrupp framför instansen. Alla tre måste vara överens, och de misslyckas på olika sätt, därför är symtomet i tabellen ovan mer användbart än felmeddelandet i webbläsaren.
Värdens brandvägg är lagret som folk glömmer efter en lyckad bindning, eftersom en regel som tillåter porten på LAN-gränssnittet inte automatiskt tillåter den på tunnelgränssnittet. Regler begränsade till gränssnitt är korrekt design och också den vanliga orsaken till en tjänst som fungerar från kontoret men inte hemifrån. Läs regelns omfattning i stället för dess portnummer.
Stateful filtrering förklarar det omvända fallet. En utgående anslutning från din laptop skapar tillstånd, och svar på den släpps in utan en inkommande regel. Kollegans anslutning är ett helt nytt flöde utan tillstånd bakom sig, så det behöver ett uttryckligt tillstånd. Den asymmetrin är hela anledningen till att en fungerande webbläsarsession på din egen maskin inte säger något om tjänsten är nåbar utifrån.
När en kontroll misslyckas, ändra designen och inte tunneln
Om kravet är att en kollega öppnar din lokala tjänst är det ärliga svaret oftast en mekanism byggd för inkommande åtkomst. En omvänd SSH-tunnel är den minsta: din maskin ansluter utgående till en värd som kollegan redan kan nå, och lyssnaren finns på den värden.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Reläet behöver GatewayPorts clientspecified i sin SSH-serverkonfiguration, annars binder den vidarebefordrade lyssnaren till loopback på reläet och kollegan möter samma avvisning som tidigare. För allt som varar längre än en eftermiddag är en lastbalanserare eller ingress med hälsokontroll och certifikat för det publicerade namnet det bättre verktyget, och en tunnel från plats till plats med rutter för båda subnäten är rätt svar när två nätverk verkligen behöver prata med varandra.
Var och en av dessa designer gör exponeringen explicit, och det är poängen. Ett VPN flyttar paket mellan nätverk som du redan var behörig att använda; det publicerar ingen tjänst och gör inte en laptop till en värd vänd mot internet. Uppgiften är att avgöra vilket av de tre lagren som ska ändras, och tunneln är sällan ett av dem.