Kaks lõpp-punkti operaatori NAT-i taga ja lukustatud kontorirouter ei jäta ühtegi sissetulevat porti suunamiseks, ja refleks on ikkagi seda küsida. Parem küsimus on, milline pool saab välja helistada ja millisel kättesaadaval teenusel on lubatud liiklust kanda. Neli lahendust vastavad sellele küsimusele erinevalt ja nurjuvad erineval viisil, kui tee on blokeeritud. Nende vahel valimine on garantiide, mitte protokollinimede võrdlemine.

Neli lahendust, neli erinevat lubadust

Allolev tabel on lühiversioon. Lugege keskmist veergu lubadusena, mida saate testida, ja paremat veergu lubadusena, mida keegi ei andnud.

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

Milline rida kehtib, sõltub ülesandest, mitte eelistusest. Üks kaugtöölaua sessioon, üks administraatori kest ja juurdepääs tervele privaatsele alamsvõrgule on kolm nõuet, mis ei vaja sama sisenemispunkti, isegi kui need juhtumisi puudutavad sama masinat.

Jaotur muudab seda, kes välja helistab, mitte seda, mis on lubatud

Marsruuditud jaoturi lahenduses avavad kaug-sülearvuti ja tööjaam, või selle ees olev saidi lüüs, kumbki väljuva tunneli teenuseni, mida mõlemad saavad kätte. Miski ei võta tööjaama ruuteris vastu soovimata ühendust, ja just seetõttu see lahendus NAT-i üle elab ja töötab ka siis, kui saidil pole staatilist aadressi. Seejärel marsruudib jaotur liiklust kahe sisemise aadressi vahel oma poliitika järgi.

Hind on see, et jaotur peab olemas olema, mõlemalt poolt kättesaadav olema ja kellegi poolt käitatud olema. Väljuv filtreerimine peab transporti lubama, ja võrk, mis selle blokeerib, nurjab lahenduse, kuigi pordisuunamist polnud vaja.

Peen osa on see, et kättesaadavus ja autoriseerimine on eraldi otsused, mis tehakse eri kohtades. Marsruut prefiksini ei ütle midagi selle kohta, millist teenust tööjaamas võib identiteet kasutada, ja tulemüürireegel, mis lubab tunnelit, ei ütle midagi selle kohta, kas konto saab sisse logida. Seadistage mõlemad, testige mõlemaid ja jätke autoriseerimisotsus selle süsteemi juurde, kellele ressurss kuulub, mitte marsruutimistabeli juurde.

Läbimurre töötab ainult siis, kui mõlemad virnad seda rakendavad

Võrdõiguslike sõlmede vaheline läbimurre on konkreetse süsteemi võime, mitte VPN-i parandav seade. Interactive Connectivity Establishment kogub mitu kandidaataadressi ja testib paare, kuni üks töötab: hostkandidaadid kohalikel liidestel, serveri-peegeldusega kandidaadid, mis ehitatakse sellest, mida NAT paljastab, ja releele eraldatud releekandidaadid. Privaatne aadress üksi ei ole tee, sest teine pool ei saa sinna marsruutida.

Releekanalit tasub mõista enne selle kõrvaleheitmist. RFC 8656 kirjeldab TURN-i protokollina, milles klient küsib serverilt releetud transpordiaadressi ja server edastab liiklust selle kliendi ja tema võrdõiguslike sõlmede vahel. Seega kannab andmeid relee, mis erineb sisuliselt kataloogist, mis ainult aitab lõpp-punktidel kohtuda. Relee-aadressi vahetamine teise poolega on koordineerimissamm, mille rakendus peab tegema.

Mida te lubada ei saa, on otsene tee. Sümmeetriline NAT ja mõned ettevõtte tulemüürid nurjavad aukude puurimise, ja kui nad seda teevad, langeb süsteem kas releele tagasi või nurjub. Samuti ei saa te järeldada, et kaks tõlgitud lõpp-punkti ei saa kunagi rääkida; toetatud virn relee varulahendusega on olemas just seetõttu, et nad sageli saavad. Otsustage, kas tähtsam on kättesaadavus või otsesus, ja seejärel kontrollige, millise tee juurutamine tegelikult valis, selle asemel et eeldada soodsat juhtumit.

Vahendaja on kitsam kui võrk

Kui nõue on üks rakendus, võib rakendusevahendaja või tööjaama algatatud pöördühendus olla väikseim vastus. Tööjaam helistab välja vahendajale, vahendaja autendib kaugkasutaja ja kantakse ainult see rakendusesessioon. Tööjaama alamsvõrku ei teki ühtegi marsruuti, seega kaugsessiooni kompromiteerimine ei päri teed iga kõrval oleva seadmeni.

Sellel kitsusel on hind: iga lisarakendus vajab oma integratsiooni ja kõik, mida rakendus kohaliku võrgu kohta eeldab, näiteks failijagamiskoht, mille see lähedases serveris avab, ei pruugi olla kättesaadav. Vahendajad koondavad ka poliitika ja logimise ühte kohta, mis on kasulik seni, kuni see koht muutub katkestuseks.

Võrrelge usalduspiire, seejärel testige teed

Jaotur, mis tunneleid lõpetab, saab marsruuditavat liiklust lugeda. Relee saab kanda iseseisvalt kaitstud vahetust, kui rakendus krüpteerib otsast otsani, ja vahendaja lõpetab tavaliselt sessiooni, mida ta esitab. Tehke kindlaks, kus kaitse tegelikult lõpeb, enne kui otsustate, et kaks lahendust on samaväärsed, sest mõlemad on krüpteeritud.

Seejärel kontrollige, mida tööjaam väljapoole tegelikult kätte saab, sest iga ülaltoodud lahendus sõltub sellest. Käivitage see tööjaamas, asendades hostinime, mida kavatsete kasutada.

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

Nõustuge lahendusega alles siis, kui kavandatud kaugoperatsioon õnnestub lubatud identiteedi all, mittelubatud identiteet lükatakse tagasi ja käitumine, kui otsene või releetud tee pole saadaval, on teada ja dokumenteeritud. Lisage taasühendamine ja tööjaama tavaline käivituskontekst, sest kontoris LAN-i kaudu alanud sessioon ei testi midagi, millest kaugjuurdepääs sõltub.

Seotud artiklid