Nå en arbejdsstation bag NAT uden portvideresendelse

To endepunkter bag udbyderens NAT og en låst kontorrouter efterlader ingen indgående port at videresende, og refleksen er at anmode om en alligevel. Det bedre spørgsmål er, hvilken side der kan ringe ud, og hvilken tilgængelig tjeneste der har lov til at bære trafikken. Fire designs besvarer det spørgsmål forskelligt, og de fejler på forskellige måder, når en vej blokeres. At vælge mellem dem er en sammenligning af garantier, ikke af protokolnavne.

Fire designs, fire forskellige løfter

Tabellen nedenfor er den korte version. Læs den midterste kolonne som det løfte, du kan teste, og den højre kolonne som det løfte, ingen har givet.

Hvilken række der gælder, afhænger af opgaven snarere end af præference. Én fjernskrivebordssession, én administrativ shell og adgang til et helt privat undernet er tre krav, der ikke har brug for det samme indgangspunkt, selv når de tilfældigvis handler om den samme maskine.

En hub ændrer, hvem der ringer ud, ikke hvad der er tilladt

I et design med en rutet hub åbner den fjernede laptop og arbejdsstationen, eller stedets gateway foran den, hver en udgående tunnel til en tjeneste, som begge kan nå. Intet accepterer en uopfordret forbindelse på arbejdsstationens router, og det er netop derfor, dette design overlever NAT og stadig virker, når stedet ikke har en statisk adresse. Hubben ruter derefter trafik mellem de to indre adresser efter sin egen politik.

Prisen er, at hubben skal findes, være tilgængelig fra begge sider og betjenes af nogen. Udgående filtrering skal tillade transporten, og et netværk, der blokerer den, vil besejre designet, selv om ingen portvideresendelse var nødvendig.

Den subtile del er, at tilgængelighed og autorisation er separate beslutninger, der træffes forskellige steder. En rute ind i et præfiks siger intet om, hvilken tjeneste på arbejdsstationen identiteten må bruge, og en firewallregel, der tillader tunnelen, siger intet om, hvorvidt kontoen kan logge ind. Konfigurer begge, test begge, og hold autorisationsbeslutningen hos det system, der ejer ressourcen, i stedet for hos routingtabellen.

Traversering virker kun, når begge stakke implementerer den

Peer-traversering er en evne hos et bestemt system, ikke en indstilling, der forbedrer en VPN. Interactive Connectivity Establishment indsamler flere kandidatadresser og tester par, indtil et virker: værtskandidater på lokale grænseflader, server-refleksive kandidater bygget ud fra det, en NAT afslører, og videresendte kandidater tildelt på et relæ. En privat adresse alene er ikke en vej, fordi den anden side ikke kan route til den.

Det videresendte tilfælde er værd at forstå, før man afviser det. RFC 8656 beskriver TURN som en protokol, hvor en klient beder en server om en videresendt transportadresse, og serveren videresender trafik mellem denne klient og dens peers. Relæet bærer altså dataene, hvilket er væsentligt anderledes end en mappe, der kun hjælper endepunkter med at mødes. At udveksle relæadressen med peer'en er et koordinationstrin, som applikationen skal udføre.

Det, du ikke kan love, er en direkte vej. Symmetrisk NAT og nogle virksomhedsfirewalls besejrer hulning, og når de gør det, falder systemet enten tilbage til et relæ eller fejler. Det, du heller ikke kan konkludere, er, at to oversatte endepunkter aldrig kan tale sammen; en understøttet stak med relæ-fallback findes netop, fordi de ofte kan. Beslut, om tilgængelighed eller direkthead betyder mest, og verificer derefter, hvilken vej implementeringen faktisk valgte, i stedet for at antage det gunstige tilfælde.

En broker er smallere end et netværk

Når kravet er én applikation, kan en applikationsbroker eller en omvendt forbindelse startet af arbejdsstationen være det mindste svar. Arbejdsstationen ringer ud til en broker, brokeren autentificerer den eksterne bruger, og kun den applikationssession bæres. Der oprettes ingen rute til arbejdsstationens undernet, så et kompromis af fjernsessionen arver ikke en vej til hver enhed ved siden af.

Den snæverhed har en pris: hver ekstra applikation kræver sin egen integration, og alt, hvad applikationen forudsætter om et lokalt netværk, såsom et filshare, den åbner på en nærliggende server, er måske ikke tilgængeligt. Brokere samler også politik og logning ét sted, hvilket er nyttigt, indtil det sted bliver afbrydelsen.

Sammenlign tillidsgrænser, og test derefter vejen

En hub, der afslutter tunneller, kan læse den trafik, den ruter. Et relæ kan bære en uafhængigt beskyttet udveksling, når applikationen krypterer ende til ende, og en broker afslutter normalt den session, den præsenterer. Fastslå, hvor beskyttelsen faktisk slutter, før du beslutter, at to designs er ækvivalente, fordi begge er krypterede.

Kontroller derefter, hvad arbejdsstationen faktisk kan nå udgående, da hvert design ovenfor afhænger af det. Kør dette på arbejdsstationen, og erstat værtsnavnet, du agter at bruge.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

Accepter kun designet, efter at den tilsigtede fjernhandling lykkes under den tilladte identitet, en ikke-godkendt identitet afvises, og adfærden, når den direkte eller videresendte vej ikke er tilgængelig, er kendt og dokumenteret. Medtag en genoprettelse af forbindelsen og arbejdsstationens normale opstartskontekst, fordi en session, der begyndte på kontoret over LAN, ikke tester noget, som fjernadgang afhænger af.