Bereik ’n werkstasie agter NAT sonder om ’n poort oop te maak

Twee eindpunte agter ’n diensverskaffer se NAT en ’n toegeslote kantoorrouter laat geen inkomende poort oor om te stuur nie, en die refleks is om tog een aan te vra. Die beter vraag is watter kant kan uitbel en watter bereikbare diens die verkeer mag dra. Vier ontwerpe beantwoord daardie vraag verskillend, en hulle faal op verskillende maniere wanneer ’n pad geblokkeer word. Om tussen hulle te kies is ’n vergelyking van waarborge, nie van protokolname nie.

Vier ontwerpe, vier verskillende beloftes

Die tabel hieronder is die kort weergawe. Lees die middelste kolom as die belofte wat jy kan toets, en die regterkolom as die belofte wat niemand gemaak het nie.

Watter ry van toepassing is, hang van die taak af eerder as van voorkeur. Een sessie vir afstandwerk op die skerm, een administratiewe dop en toegang tot ’n volledige private subnet is drie vereistes wat nie dieselfde toegangspunt nodig het nie, selfs wanneer hulle toevallig dieselfde masjien raak.

’n Hub verander wie uitbel, nie wat toegelaat word nie

In ’n gerouteerde hub-ontwerp open die afstandskootrekenaar en die werkstasie, of die terreinpoort voor dit, elkeen ’n uitgaande tonnel na ’n diens wat albei kan bereik. Niks aanvaar ’n onversoekte verbinding by die werkstasie se router nie, en dit is juis waarom hierdie ontwerp NAT oorleef en waarom dit steeds werk wanneer die terrein geen statiese adres het nie. Die hub routeer dan verkeer tussen die twee binneste adresse volgens sy eie beleid.

Die koste is dat die hub moet bestaan, van albei kante bereikbaar moet wees en deur iemand bedryf moet word. Uitgaande filtrering moet die transport toelaat, en ’n netwerk wat dit blokkeer, sal die ontwerp verydel selfs al was geen poortstuur nodig nie.

Die subtiele deel is dat bereikbaarheid en magtiging aparte besluite is wat op verskillende plekke geneem word. ’n Roete na ’n voorvoegsel sê niks oor watter diens op die werkstasie die identiteit mag gebruik nie, en ’n vuurmuurreël wat die tonnel toelaat sê niks oor of die rekening kan aanmeld nie. Konfigureer albei, toets albei, en hou die magtigingsbesluit by die stelsel wat die hulpbron besit eerder as by die routingtabel.

Deurgang werk net wanneer albei stelle dit implementeer

Ewenaar-deurgang is ’n vermoë van ’n spesifieke stelsel, nie ’n instelling wat ’n VPN verbeter nie. Interactive Connectivity Establishment versamel verskeie kandidaatadresse en toets pare tot een werk: gasheerkandidate op plaaslike koppelvlakke, bediener-refleksiewe kandidate wat uit die NAT se onthulling gebou word, en deurgestuurde kandidate wat op ’n aflos toegewys word. ’n Private adres alleen is nie ’n pad nie, want die ander kant kan nie daarheen routeer nie.

Die deurgestuurde geval is die moeite werd om te verstaan voordat jy dit afmaak. RFC 8656 beskryf TURN as ’n protokol waarin ’n kliënt ’n bediener vra vir ’n deurgestuurde transportadres en die bediener verkeer tussen daardie kliënt en sy eweknieë aanstuur. Die aflos dra dus die data, wat wesenlik verskil van ’n gids wat net eindpunte help ontmoet. Om die aflosadres met die eweknie uit te ruil is ’n koördinasiestap wat die toepassing moet doen.

Wat jy nie kan belowe nie, is ’n direkte pad. Simmetriese NAT en sommige ondernemingsvuurmure verydel gatponsing, en wanneer dit gebeur, val die stelsel terug op ’n aflos of misluk. Wat jy ook nie kan aflei nie, is dat twee vertaalde eindpunte nooit kan praat nie; ’n ondersteunde stel met ’n aflos-terugval bestaan juis omdat hulle dikwels kan. Besluit of beskikbaarheid of direktheid meer saak maak, en verifieer dan watter pad die ontplooiing werklik gekies het in plaas daarvan om die gelukkige geval te aanvaar.

’n Makelaar is smaller as ’n netwerk

Wanneer die vereiste een toepassing is, kan ’n toepassingsmakelaar of ’n omgekeerde verbinding wat deur die werkstasie begin word, die kleinste antwoord wees. Die werkstasie bel uit na ’n makelaar, die makelaar verifieer die afstandgebruiker, en net daardie toepassingsessie word gedra. Geen roete na die werkstasie se subnet word geskep nie, so ’n kompromittering van die afstandsessie erf nie ’n pad na elke toestel langsaan nie.

Daardie smalheid het ’n prys: elke bykomende toepassing het sy eie integrasie nodig, en enigiets wat die toepassing oor ’n plaaslike netwerk aanneem, soos ’n lêerdeling wat dit op ’n nabye bediener oopmaak, is dalk nie bereikbaar nie. Makelaars konsentreer ook beleid en logboekhouding op een plek, wat nuttig is totdat daardie plek die onderbreking word.

Vergelyk vertrouensgrense, en toets dan die pad

’n Hub wat tonnele termineer, kan die verkeer lees wat hy routeer. ’n Aflos kan ’n onafhanklik beskermde uitruiling dra wanneer die toepassing punt-tot-punt versleutel, en ’n makelaar termineer gewoonlik die sessie wat hy aanbied. Stel vas waar beskerming werklik eindig voordat jy besluit dat twee ontwerpe ekwivalent is omdat albei versleutel is.

Kyk dan wat die werkstasie werklik uitgaande kan bereik, want elke ontwerp hierbo hang daarvan af. Voer dit op die werkstasie uit en vervang die gasheernaam wat jy van plan is om te gebruik.

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

Aanvaar die ontwerp eers nadat die beoogde afstandsbewerking onder die toegelate identiteit slaag, ’n nie-goedgekeurde identiteit geweier word, en die gedrag wanneer die direkte of deurgestuurde pad onbeskikbaar is, bekend en gedokumenteer is. Sluit ’n herverbinding en die werkstasie se normale opstartkonteks in, want ’n sessie wat in die kantoor oor die LAN begin het, toets niks waarvan afstands toegang afhang nie.