Nå ein arbeidsstasjon bak NAT utan portvideresending
Ein arbeidsstasjon utan innkomande port er likevel tilgjengeleg via ein hub, eit relé eller ein applikasjonsmeklar. Samanlikn kva kvart design garanterer før du vel eitt.
To endepunkt bak NAT-en til leverandøren og ein låst kontorrouter lèt ingen innkomande port liggje att å videresende, og refleksen er å be om ein likevel. Det betre spørsmålet er kva side som kan ringje ut, og kva tilgjengeleg teneste som har lov til å bera trafikken. Fire design svarar på det spørsmålet ulikt, og dei feilar på ulike måtar når ein veg blir blokkert. Å velje mellom dei er ei samanlikning av garantiar, ikkje av protokollnamn.
Fire design, fire ulike løfte
Tabellen nedanfor er kortversjonen. Les den midtre kolonnen som løftet du kan teste, og den høgre kolonnen som løftet ingen har gjeve.
| 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 |
Kva rad som gjeld, kjem an på oppgåva og ikkje på preferansen. Éi fjernskrivebordsøkt, eitt administrativt skal og tilgang til eit heilt privat subnett er tre krav som ikkje treng same inngangspunkt, sjølv når dei tilfeldigvis gjeld same maskin.
Ein hub endrar kven som ringjer ut, ikkje kva som er tillate
I eit design med ruta hub opnar den eksterne laptoppen og arbeidsstasjonen, eller gatewayen til staden framfor han, kvar sin utgåande tunnel til ei teneste begge kan nå. Ingenting godtek ei uoppfordra tilkopling på ruteren til arbeidsstasjonen, og det er nettopp derfor dette designet overlever NAT og framleis verkar når staden ikkje har ei statisk adresse. Deretter rutar huben trafikk mellom dei to indre adressene etter sin eigen policy.
Prisen er at huben må finnast, vere tilgjengeleg frå begge sider og bli driven av nokon. Utgåande filtrering må tillate transporten, og eit nettverk som blokkerer han vil beseire designet sjølv om inga portvideresending var naudsynt.
Den subtile delen er at tilgjenge og autorisasjon er separate avgjerder som blir tekne på ulike stader. Ei rute inn i eit prefiks seier ingenting om kva teneste på arbeidsstasjonen identiteten kan bruke, og ein brannmurregel som tillèt tunnelen seier ingenting om kontoen kan logge inn. Konfigurer begge, test begge, og hald autorisasjonsavgjerda hos systemet som eig ressursen i staden for hos rutetabellen.
Traversering verkar berre når begge stakkane implementerer ho
Peer-traversering er ein eigenskap hos eit bestemt system, ikkje ei innstilling som betreinar ein VPN. Interactive Connectivity Establishment samlar fleire kandidatadresser og testar par til eitt verkar: vertskandidatar på lokale grensesnitt, tenar-refleksive kandidatar bygde frå det ein NAT avslører, og vidaresende kandidatar tildelte på eit relé. Ei privat adresse åleine er ikkje ein veg, fordi den andre sida ikkje kan rute til ho.
Det vidaresende tilfellet er verdt å forstå før ein avviser det. RFC 8656 skildrar TURN som ein protokoll der ein klient ber ein tenar om ei vidaresend transportadresse, og tenaren vidaresender trafikk mellom denne klienten og peer-ane hans. Reléet ber altså dataa, noko som er vesentleg annleis enn ein katalog som berre hjelper endepunkt å møtast. Å utveksle reléadressa med peer-en er eit koordineringstrinn som applikasjonen må utføre.
Det du ikkje kan love, er ein direkte veg. Symmetrisk NAT og nokre bedriftsbrannmurar beseirar hòltaking, og når dei gjer det, fell systemet anten tilbake til eit relé eller feilar. Du kan heller ikkje konkludere at to omsette endepunkt aldri kan snakke saman; ein støtta stack med relé-fallback finst nettopp fordi dei ofte kan. Avgjer om tilgjenge eller direktheit tyder mest, og verifiser deretter kva veg utrulleringa faktisk valde i staden for å anta det gunstige tilfellet.
Ein meklar er smalare enn eit nettverk
Når kravet er éin applikasjon, kan ein applikasjonsmeklar eller ei omvend tilkopling starta av arbeidsstasjonen vere det minste svaret. Arbeidsstasjonen ringjer ut til ein meklar, meklaren autentiserer den eksterne brukaren, og berre den applikasjonsøkta blir boren. Det blir ikkje oppretta noka rute til subnettet til arbeidsstasjonen, så eit kompromiss av fjernøkta arvar ikkje ein veg til kvar eining ved sida.
Den smalheita har ein pris: kvar ekstra applikasjon treng sin eigen integrasjon, og alt applikasjonen føreset om eit lokalt nettverk, som ei filutveksling han opnar på ein nærliggande tenar, er kanskje ikkje tilgjengeleg. Meklarar samlar òg policy og logging på ein stad, noko som er nyttig heilt til den staden blir avbrotet.
Samanlikn tillitsgrenser, og test deretter vegen
Ein hub som avsluttar tunnelar, kan lese trafikken han rutar. Eit relé kan bera ein uavhengig verna utveksling når applikasjonen krypterer ende til ende, og ein meklar avsluttar vanlegvis økta han presenterer. Fastslå kvar vernet faktisk sluttar før du avgjer at to design er likeverdige fordi begge er krypterte.
Kontroller deretter kva arbeidsstasjonen faktisk når utgåande, sidan kvart design ovanfor er avhengig av det. Køyr dette på arbeidsstasjonen, og byt ut vertsnamnet 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 lukkast under den tillatne identiteten, ein ikkje-godkjend identitet blir avvist, og åtferda når den direkte eller vidaresende vegen ikkje er tilgjengeleg er kjend og dokumentert. Ta med ei gjenoppkopling og den normale oppstartskonteksten til arbeidsstasjonen, fordi ei økt som starta på kontoret over LAN ikkje testar noko som fjerntilgang er avhengig av.