Nå en arbeidsstasjon bak NAT uten portvideresending
En arbeidsstasjon uten innkommende port er likevel tilgjengelig via en hub, et relé eller en applikasjonsmegler. Sammenlign hva hvert design garanterer før du velger ett.
To endepunkter bak leverandørens NAT og en låst kontorrouter etterlater ingen innkommende port å videresende, og refleksen er å be om en likevel. Det bedre spørsmålet er hvilken side som kan ringe ut, og hvilken tilgjengelig tjeneste som har lov til å bære trafikken. Fire design svarer på det spørsmålet ulikt, og de feiler på ulike måter når en vei blokkeres. Å velge mellom dem er en sammenligning av garantier, ikke av protokollnavn.
Fire design, fire forskjellige løfter
Tabellen nedenfor er kortversjonen. Les den midterste kolonnen som løftet du kan teste, og den høyre kolonnen som løftet ingen har gitt.
| 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 |
Hvilken rad som gjelder avhenger av oppgaven og ikke av preferansen. Én fjernskrivebordsøkt, ett administrativt skall og tilgang til et helt privat subnett er tre krav som ikke trenger samme inngangspunkt, selv når de tilfeldigvis gjelder samme maskin.
En hub endrer hvem som ringer ut, ikke hva som er tillatt
I et design med rutet hub åpner den eksterne laptopen og arbeidsstasjonen, eller stedets gateway foran den, hver sin utgående tunnel til en tjeneste begge kan nå. Ingenting godtar en uoppfordret forbindelse på arbeidsstasjonens router, og det er nettopp derfor dette designet overlever NAT og fortsatt virker når stedet ikke har en statisk adresse. Deretter ruter huben trafikk mellom de to indre adressene etter sin egen policy.
Prisen er at huben må finnes, være tilgjengelig fra begge sider og drives av noen. Utgående filtrering må tillate transporten, og et nettverk som blokkerer den vil beseire designet selv om ingen portvideresending var nødvendig.
Den subtile delen er at tilgjengelighet og autorisasjon er separate beslutninger som tas på forskjellige steder. En rute inn i et prefiks sier ingenting om hvilken tjeneste på arbeidsstasjonen identiteten kan bruke, og en brannmurregel som tillater tunnelen sier ingenting om kontoen kan logge inn. Konfigurer begge, test begge, og hold autorisasjonsbeslutningen hos systemet som eier ressursen i stedet for hos rutetabellen.
Traversering virker bare når begge stakkene implementerer den
Peer-traversering er en egenskap hos et bestemt system, ikke en innstilling som forbedrer en VPN. Interactive Connectivity Establishment samler flere kandidatadresser og tester par til ett virker: vertskandidater på lokale grensesnitt, server-refleksive kandidater bygget fra det en NAT avslører, og videresendte kandidater tildelt på et relé. En privat adresse alene er ikke en vei, fordi den andre siden ikke kan rute til den.
Det videresendte tilfellet er verdt å forstå før man avviser det. RFC 8656 beskriver TURN som en protokoll der en klient ber en server om en videresendt transportadresse, og serveren videresender trafikk mellom denne klienten og dens peers. Reléet bærer altså dataene, noe som er vesentlig annerledes enn en katalog som bare hjelper endepunkter å møtes. Å utveksle reléadressen med peer-en er et koordineringstrinn som applikasjonen må utføre.
Det du ikke kan love, er en direkte vei. Symmetrisk NAT og noen bedriftsbrannmurer beseirer hulltaking, og når de gjør det, faller systemet enten tilbake til et relé eller feiler. Du kan heller ikke konkludere at to oversatte endepunkter aldri kan snakke sammen; en støttet stack med relé-fallback finnes nettopp fordi de ofte kan. Bestem om tilgjengelighet eller direkthet betyr mest, og verifiser deretter hvilken vei utrullingen faktisk valgte i stedet for å anta det gunstige tilfellet.
En megler er smalere enn et nettverk
Når kravet er én applikasjon, kan en applikasjonsmegler eller en omvendt forbindelse startet av arbeidsstasjonen være det minste svaret. Arbeidsstasjonen ringer ut til en megler, megleren autentiserer den eksterne brukeren, og bare den applikasjonsøkten bæres. Det opprettes ingen rute til arbeidsstasjonens subnett, så et kompromiss av fjernøkten arver ikke en vei til hver enhet ved siden av.
Den smalheten har en pris: hver ekstra applikasjon trenger sin egen integrasjon, og alt applikasjonen forutsetter om et lokalt nettverk, som en filutveksling den åpner på en nærliggende server, er kanskje ikke tilgjengelig. Meglere samler også policy og logging på ett sted, noe som er nyttig helt til det stedet blir avbruddet.
Sammenlign tillitsgrenser, og test deretter veien
En hub som avslutter tunneler, kan lese trafikken den ruter. Et relé kan bære en uavhengig beskyttet utveksling når applikasjonen krypterer ende til ende, og en megler avslutter vanligvis økten den presenterer. Fastslå hvor beskyttelsen faktisk slutter før du bestemmer at to design er likeverdige fordi begge er krypterte.
Kontroller deretter hva arbeidsstasjonen faktisk når utgående, siden hvert design ovenfor avhenger av det. Kjør dette på arbeidsstasjonen, og bytt ut vertsnavnet du har tenkt å bruke.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comGodta designet først etter at den tiltenkte fjernoperasjonen lykkes under den tillatte identiteten, en ikke-godkjent identitet avvises, og oppførselen når den direkte eller videresendte veien ikke er tilgjengelig er kjent og dokumentert. Ta med en gjentilkobling og arbeidsstasjonens normale oppstartskontekst, fordi en økt som startet på kontoret over LAN ikke tester noe som fjern tilgang er avhengig av.