Tveir endapunktar bakvið NAT símafyrirtækisins og læstur beinir skrifstofunnar skilja eftir ekkert innkomandi port til að framsenda, og viðbragðið er samt að biðja um eitt. Betri spurningin er hvaða hlið getur hringt út og hvaða aðgengilega þjónusta má bera umferðina. Fjórar hannanir svara þeirri spurningu á mismunandi hátt og mistakast á mismunandi vegu þegar slóð er lokuð. Að velja á milli þeirra er samanburður á ábyrgðum, ekki á nöfnum samskiptaregla.

Fjórar hannanir, fjögur mismunandi loforð

Taflan hér fyrir neðan er stutta útgáfan. Lestu miðdálkinn sem loforðið sem þú getur prófað og hægri dálkinn sem loforðið sem enginn gaf.

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

Hvaða röð á við fer eftir verkefninu en ekki eftir smekk. Einn fjarvinnuskjásfundur, eitt stjórnunarskel og aðgangur að heilu einkareknu undirneti eru þrjár kröfur sem þurfa ekki sama inngangspunkt, jafnvel þótt þær varði sama vélina fyrir tilviljun.

Hub breytir því hver hringir út, ekki hvað er leyft

Í hönnun með beinum hub opna fartölvan í fjarlægð og vinnustöðin, eða gátt staðarins fyrir framan hana, hvort um sig útleiðandi göng að þjónustu sem báðar ná til. Ekkert tekur við óumbeðinni tengingu á beini vinnustöðvarinnar, og það er einmitt ástæðan fyrir því að þessi hönnun lifir NAT af og virkar jafnvel þótt staðurinn hafi ekki fast netfang. Síðan beinir hub umferð milli tveggja innri netfanga samkvæmt eigin stefnu.

Kostnaðurinn er að hub verður að vera til, vera aðgengilegur frá báðum hliðum og einhver verður að reka hann. Útleiðandi sía verður að leyfa flutninginn, og net sem lokar á hann mun koma í veg fyrir hönnunina þótt engrar portframsendingar hafi verið þörf.

Hinn fíngerði hluti er að aðgengi og heimild eru aðskildar ákvarðanir sem teknar eru á mismunandi stöðum. Slóð inn í forskeyti segir ekkert um hvaða þjónustu á vinnustöðinni auðkennið má nota, og eldveggsregla sem leyfir göngin segir ekkert um hvort reikningurinn geti skráð sig inn. Stilltu bæði, prófaðu bæði og hafðu heimildarákvörðunina hjá kerfinu sem á auðlindina, ekki hjá beinitöflunni.

Gegnumferð virkar aðeins þegar báðir stakar útfæra hana

Gegnumferð milli jafningja er hæfileiki tiltekins kerfis, ekki stilling sem bætir VPN. Interactive Connectivity Establishment safnar nokkrum frambjóðendanetföngum og prófar pör þar til eitt virkar: hýsilsframbjóðendur á staðbundnum tengi, þjónendurspegluð frambjóðendur byggð á því sem NAT afhjúpar, og framsend frambjóðendur sem úthlutað er á endurvarpa. Einkanetfang eitt og sér er ekki slóð, því hin hliðin getur ekki beint þangað.

Það er þess virði að skilja framsendu tilvikin áður en þeim er hafnað. RFC 8656 lýsir TURN sem samskiptareglu þar sem biðlarinn biður þjón um framsent flutningsnetfang og þjónninn framsendir umferð milli þess biðlara og jafningja hans. Endurvarpinn ber því gögnin, sem er verulega frábrugðið skrá sem aðeins hjálpar endapunktum að hittast. Skipti á endurvarpsnetfangi við jafningjann er samhæfingarskref sem forritið verður að gera.

Það sem þú getur ekki lofað er bein slóð. Samhverft NAT og sumar fyrirtækjaeldveggir koma í veg fyrir holuborun, og þegar svo fer fer kerfið annaðhvort aftur á endurvarpa eða mistekst. Þú getur heldur ekki ályktað að tveir þýddir endapunktar geti aldrei talað saman; studdur staki með endurvarpsvaraleið er til einmitt vegna þess að þeir geta það oft. Ákveddu hvort framboð eða beinleiki skiptir meira máli og staðfestu síðan hvaða slóð uppsetningin valdi í raun í stað þess að gera ráð fyrir happatilvikinu.

Miðlari er þrengri en net

Þegar krafan er eitt forrit getur forritamiðlari eða öfug tenging sem vinnustöðin hefur frumkvæði að verið minnsta svarið. Vinnustöðin hringir út til miðlara, miðlarinn sannreynir fjarnotandann og aðeins það forritsfundur er borið. Engin slóð til undirnets vinnustöðvarinnar verður til, svo skaði á fjarfundinum erfir ekki slóð til hvers tækis við hliðina.

Sú þrengd hefur verð: hvert viðbótarforrit þarf eigin samþættingu, og hvað sem forritið gerir ráð fyrir um staðbundið net, eins og skráardeilingu sem það opnar á nálægum þjóni, er kannski ekki aðgengilegt. Miðlarar einbeita einnig stefnu og skráningu á einn stað, sem er gagnlegt þar til sá staður verður bilunin.

Berðu saman traustmörk og prófaðu síðan slóðina

Hub sem lýkur göngum getur lesið umferðina sem hann beinir. Endurvarpi getur borið sjálfstætt varið skipti þegar forritið dulkóðar enda á milli, og miðlari lýkur venjulega fundinum sem hann kynnir. Komdu á hvar verndin endar í raun áður en þú ákveður að tvær hannanir séu jafngildar því báðar eru dulkóðaðar.

Athugaðu síðan hvað vinnustöðin nær í raun út, því hver hönnun hér að ofan veltur á því. Keyrðu þetta á vinnustöðinni og skiptu út hýsilnafninu sem þú ætlar að nota.

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

Samþykktu hönnunina aðeins eftir að ætluð fjaraðgerð tekst undir leyfðu auðkenni, ósamþykkt auðkenni er hafnað og hegðunin þegar bein eða framsend slóð er ekki tiltæk er þekkt og skjalfest. Láttu fylgja endurtengingu og venjulegt ræsingarsamhengi vinnustöðvarinnar, því fundur sem hófst á skrifstofunni yfir LAN prófar ekkert af því sem fjaraðgangur veltur á.

Tengdir greinar