Twa einen efter de NAT fan ’e provider en in ôfsletten kantoarrûter litte gjin yngeande poarte oer om troch te stjoeren, en de refleks is dochs ien oanfreegje. De bettere fraach is hokker kant nei bûten belje kin en hokker berikbere tsjinst tastean is it ferkear te dragen. Fjouwer ûntwerpen beantwurdzje dy fraach ferskillend, en se mislearje op ferskillende manieren as in paad blokkearre wurdt. Kieze tusken har is in ferliking fan garânsjes, net fan protokolnammen.

Fjouwer ûntwerpen, fjouwer ferskillende beloften

De tabel hjirûnder is de koarte ferzje. Lês de middenkolom as de belofte dy’t jo teste kinne, en de rjochterkolom as de belofte dy’t nimmen dien hat.

DesignWho initiatesPromise you getPromise you do not get
Routed VPN hubBoth ends, outbound to the hubA routed path to permitted prefixesAccess to services no policy allows
Peer traversal with ICEBoth peers to a rendezvous serviceA path tested between the two peersA direct path through every NAT
TURN relayClient outbound to a relayTransport that survives symmetric NATPeer discovery or a usable directory
Application brokerWorkstation outbound to a brokerOne audited application sessionSubnet-wide reachability

Hokker rige jildt hinget fan ’e taak ôf en net fan ’e foarkar. Ien sesje foar ôfstânswurk op it skerm, ien bestjoerlike skyl en tagong ta in hiel privee subnet binne trije easken dy’t net deselde yngong nedich hawwe, sels as se tafallich deselde masine beslane.

In hub feroaret wa’t nei bûten belt, net wat tastien is

Yn in ûntwerp mei in rûte hub iepenje de ôfstâns-laptop en it wurkstasjon, of de gateway fan it plak dêrfoar, elk in útgeande tunnel nei in tsjinst dy’t beide berikke kinne. Neat akseptearret in net-frege ferbining op ’e rûter fan it wurkstasjon, en dat is krekt wêrom’t dit ûntwerp NAT oerlibbet en noch wurket as it plak gjin statysk adres hat. Dêrnei rûtet de hub ferkear tusken de twa ynderlike adressen neffens syn eigen belied.

De priis is dat de hub bestean moat, fan beide kanten berikber wêze moat en troch immen betsjinne wurde moat. Utgeande filtering moat it ferfier tastean, en in netwurk dat it blokkearret sil it ûntwerp ferslaan, sels as gjin poartetrochstjoering nedich wie.

It subtile part is dat berikberens en autorisaasje aparte besluten binne dy’t op ferskillende plakken nommen wurde. In rûte nei in foarheaksel seit neat oer hokker tsjinst op it wurkstasjon de identiteit brûke mei, en in firewallregel dy’t de tunnel tastiet seit neat oer oft it akkount ynloegje kin. Konfigurearje beide, test beide, en hâld it autorisaasjebeslút by it systeem dat de boarne besit yn stee fan by de rûtingstabel.

Trochgong wurket allinnich as beide steapels it ymplementearje

Trochgong tusken gelikense parten is in fermogen fan in beskaat systeem, net in ynstelling dy’t in VPN ferbetteret. Interactive Connectivity Establishment sammelt ferskate kandidaatadressen en testet pearen oant ien wurket: hostkandidaten op lokale ynterfaces, tsjinner-refleksive kandidaten boud fan wat in NAT iepenbieret, en relaiskandidaten tawiisd op in relais. In privee adres allinnich is gjin paad, want de oare kant kin dêr net hinne rûte.

It relaisgefal is de muoite wurdich te begripen foardat jo it ôfwize. RFC 8656 beskriuwt TURN as in protokol wêryn’t in klant in tsjinner freget om in relais ferfieraderes en de tsjinner ferkear trochstjoert tusken dy klant en syn parten. It relais draacht dus de gegevens, wat materieel oars is as in gids dy’t allinnich helpt om einen te moetsjen. It relaisadres mei de oare kant útwikselje is in koördinaasjestap dy’t de applikaasje dwaan moat.

Wat jo net belove kinne, is in direkt paad. Symmetrysk NAT en guon bedriuwsfirewalls ferslaan gatboarjen, en as se dat dogge, falt it systeem werom op in relais of mislearret it. Wat jo ek net konkludearje kinne, is dat twa oersette einen nea prate kinne; in stipe steapel mei relais-fallback bestiet krekt om’t se it faak wol kinne. Beslis oft beskikberens of direktens mear útmakket, en ferifiearje dan hokker paad de útrulling eins keazen hat yn stee fan it geunstige gefal oan te nimmen.

In broker is smeller as in netwurk

As de eask ien applikaasje is, kin in app-broker of in omkearde ferbining starten troch it wurkstasjon it lytste antwurd wêze. It wurkstasjon belt nei bûten nei in broker, de broker autentisearret de ôfstânsbrûker, en allinnich dy applikaasjesesje wurdt droegen. Der wurdt gjin rûte nei it subnet fan it wurkstasjon makke, sadat in kompromis fan ’e ôfstânssesje gjin paad nei elk apparaat dêrnjonken erft.

Dy smelens hat in priis: elke ekstra applikaasje hat syn eigen yntegraasje nedich, en alles wat de applikaasje oer in lokaal netwurk oannimt, lykas in bestânsdieling dy’t it op in tichtbye tsjinner iepenet, is miskien net berikber. Brokers konsintrearje ek belied en logging op ien plak, wat nuttich is oant dat plak de steuring wurdt.

Ferlykje fertrouwensgrinzen, test dan it paad

In hub dy’t tunnels beëiniget kin it ferkear lêze dat hy rûtet. In relais kin in selsstannich beskerme útwikseling drage as de applikaasje fan ein oant ein fersifere, en in broker beëiniget gewoanlik de sesje dy’t hy presintearret. Stel fêst wêr’t beskerming eins einiget foardat jo beslute dat twa ûntwerpen gelykweardich binne om’t beide fersifere binne.

Kontrolearje dan wat it wurkstasjon eins útgeand berikke kin, want elk ûntwerp hjirboppe hinget dêrfan ôf. Fier dit út op it wurkstasjon en ferfang de hostnamme dy’t jo fan plan binne te brûken.

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

Akseptearje it ûntwerp pas neidat de bedoelde ôfstânsoperaasje slagget ûnder de tastiene identiteit, in net-goedkarde identiteit wegere wurdt, en it gedrach as it direkte of relaispaad net beskikber is bekend en dokumintearre is. Nim in opnij ferbinen en de normale opstartkontekst fan it wurkstasjon op, want in sesje dy’t op kantoar oer it LAN begûn is, testet neat dêr’t ôfstânstagong fan ôfhinget.

Relatearre artikelen