Nå en arbetsstation bakom NAT utan portvidarebefordran
En arbetsstation utan inkommande port är ändå nåbar via en hubb, en relä eller en applikationsmäklare. Jämför vad varje design garanterar innan du väljer en.
Två ändpunkter bakom operatörens NAT och en låst kontorsrouter lämnar ingen inkommande port att vidarebefordra, och reflexen är att begära en ändå. Den bättre frågan är vilken sida som kan ringa ut och vilken nåbar tjänst som får bära trafiken. Fyra designer svarar på den frågan olika, och de misslyckas på olika sätt när en väg blockeras. Att välja mellan dem är en jämförelse av garantier, inte av protokollnamn.
Fyra designer, fyra olika löften
Tabellen nedan är kortversionen. Läs den mellersta kolumnen som löftet du kan testa, och den högra kolumnen som löftet ingen gav.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
Vilken rad som gäller beror på uppgiften och inte på preferensen. En fjärrskrivbordssession, ett administrativt skal och åtkomst till ett helt privat delnät är tre krav som inte behöver samma ingångspunkt, även när de råkar gälla samma maskin.
En hubb ändrar vem som ringer ut, inte vad som är tillåtet
I en design med routad hubb öppnar den externa laptopen och arbetsstationen, eller platsens gateway framför den, var sin utgående tunnel till en tjänst som båda kan nå. Inget tar emot en oombedd anslutning på arbetsstationens router, och det är just därför denna design överlever NAT och fortfarande fungerar när platsen saknar statisk adress. Därefter routar hubben trafik mellan de två inre adresserna enligt sin egen policy.
Priset är att hubben måste finnas, vara nåbar från båda sidor och drivas av någon. Utgående filtrering måste tillåta transporten, och ett nätverk som blockerar den kommer att besegra designen även om ingen portvidarebefordran behövdes.
Den subtila delen är att nåbarhet och auktorisering är separata beslut som fattas på olika ställen. En rutt in i ett prefix säger ingenting om vilken tjänst på arbetsstationen identiteten får använda, och en brandväggsregel som tillåter tunneln säger ingenting om kontot kan logga in. Konfigurera båda, testa båda och behåll auktoriseringsbeslutet hos systemet som äger resursen i stället för hos routingtabellen.
Traversering fungerar bara när båda stackarna implementerar den
Peer-traversering är en förmåga hos ett visst system, inte en inställning som förbättrar en VPN. Interactive Connectivity Establishment samlar flera kandidatadresser och testar par tills ett fungerar: värdkandidater på lokala gränssnitt, server-reflexiva kandidater byggda av det en NAT avslöjar, och vidarebefordrade kandidater som tilldelas på en relä. En privat adress ensam är inte en väg, eftersom andra sidan inte kan routa dit.
Det vidarebefordrade fallet är värt att förstå innan man avvisar det. RFC 8656 beskriver TURN som ett protokoll där en klient ber en server om en vidarebefordrad transportadress och servern vidarebefordrar trafik mellan den klienten och dess peers. Reläet bär alltså data, vilket skiljer sig väsentligt från en katalog som bara hjälper ändpunkter att mötas. Att utbyta reläadressen med motparten är ett koordineringssteg som applikationen måste utföra.
Det du inte kan lova är en direkt väg. Symmetrisk NAT och en del företagsbrandväggar besegrar hålslagning, och när de gör det fallerar systemet antingen tillbaka på ett relä eller misslyckas. Du kan inte heller dra slutsatsen att två översatta ändpunkter aldrig kan tala med varandra; en stack med stöd för relä-fallback finns just för att de ofta kan. Bestäm om tillgänglighet eller direkthet spelar störst roll och verifiera sedan vilken väg driftsättningen faktiskt valde i stället för att anta det lyckliga fallet.
En mäklare är smalare än ett nätverk
När kravet är en enda applikation kan en applikationsmäklare eller en omvänd anslutning som startas av arbetsstationen vara det minsta svaret. Arbetsstationen ringer ut till en mäklare, mäklaren autentiserar fjärranvändaren och bara den applikationssessionen bärs. Ingen rutt till arbetsstationens delnät skapas, så en kompromiss av fjärrsessionen ärver inte en väg till varje enhet bredvid.
Den smalheten har ett pris: varje extra applikation behöver sin egen integration, och allt applikationen förutsätter om ett lokalt nätverk, som en filutdelning den öppnar på en närliggande server, är kanske inte nåbart. Mäklare samlar också policy och loggning på ett ställe, vilket är användbart tills den platsen blir avbrottet.
Jämför förtroendegränser och testa sedan vägen
En hubb som avslutar tunnlar kan läsa trafiken den routar. En relä kan bära ett oberoende skyddat utbyte när applikationen krypterar från ände till ände, och en mäklare avslutar vanligtvis sessionen den presenterar. Fastställ var skyddet faktiskt slutar innan du avgör att två designer är likvärdiga eftersom båda är krypterade.
Kontrollera sedan vad arbetsstationen faktiskt når utgående, eftersom varje design ovan beror på det. Kör detta på arbetsstationen och ersätt värdnamnet du tänker använda.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comAcceptera designen först efter att den avsedda fjärroperationen lyckas under den tillåtna identiteten, en icke-godkänd identitet avvisas, och beteendet när den direkta eller vidarebefordrade vägen inte är tillgänglig är känt och dokumenterat. Inkludera en återanslutning och arbetsstationens normala startkontext, eftersom en session som började på kontoret över LAN inte testar något som fjärråtkomst är beroende av.