Atingi laborejon malantaŭ NAT sen porda plusendado
Laborejo sen envena pordo estas ankoraŭ atingebla per centro, relajso aŭ aplikaĵa peranto. Komparu, kion ĉiu dezajno garantias, antaŭ ol vi elektos unu.
Du finpunktoj malantaŭ la NAT de la provizanto kaj ŝlosita oficeja enkursigilo lasas neniun envenan pordon por plusendi, kaj la reflekso estas tamen peti unu. La pli bona demando estas, kiu flanko povas voki eksteren kaj kiu atingebla servo rajtas porti la trafikon. Kvar dezajnoj respondas tiun demandon malsame, kaj ili malsukcesas malsame, kiam vojo estas blokita. Elekti inter ili estas komparo de garantioj, ne de protokolaj nomoj.
Kvar dezajnoj, kvar malsamaj promesoj
La tabelo sube estas la mallonga versio. Legu la mezan kolumnon kiel la promeson, kiun vi povas testi, kaj la dekstran kolumnon kiel la promeson, kiun neniu donis.
| 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 |
Kiu vico validas dependas de la tasko kaj ne de la prefero. Unu fora labortabla seanco, unu administra ŝelo kaj aliro al tuta privata subreto estas tri postuloj, kiuj ne bezonas la saman enirpunkton, eĉ kiam ili hazarde koncernas la saman maŝinon.
Centro ŝanĝas, kiu vokas eksteren, ne kio estas permesita
En dezajno de enkursigita centro la fora tekkomputilo kaj la laborejo, aŭ la reteja pordego antaŭ ĝi, ĉiu malfermas eliran tunelon al servo, kiun ambaŭ povas atingi. Nenio akceptas nepetitan konekton ĉe la enkursigilo de la laborejo, kaj ĝuste tial ĉi tiu dezajno postvivas NAT kaj ankoraŭ funkcias, kiam la retejo ne havas statikan adreson. Poste la centro enkursigas trafikon inter la du internaj adresoj laŭ sia propra politiko.
La kosto estas, ke la centro devas ekzisti, devas esti atingebla de ambaŭ flankoj kaj devas esti funkciigata de iu. Elira filtrado devas permesi la transporton, kaj reto, kiu blokas ĝin, venkos la dezajnon, eĉ se neniu porda plusendado estis necesa.
La subtila parto estas, ke atingeblo kaj rajtigo estas apartaj decidoj farataj en malsamaj lokoj. Vojo en prefikson diras nenion pri tio, kiun servon ĉe la laborejo la identeco rajtas uzi, kaj fajroŝirma regulo, kiu permesas la tunelon, diras nenion pri tio, ĉu la konto povas ensaluti. Agordu ambaŭ, testu ambaŭ kaj tenu la rajtigan decidon ĉe la sistemo, kiu posedas la rimedon, anstataŭ ĉe la enkursiga tabelo.
Traveturo funkcias nur, kiam ambaŭ stakoj efektivigas ĝin
Samranga traveturo estas kapablo de specifa sistemo, ne agordo, kiu plibonigas VPN. Interactive Connectivity Establishment kolektas plurajn kandidatajn adresojn kaj testas parojn ĝis unu funkcias: gastigantaj kandidatoj sur lokaj interfacoj, servile reflektaj kandidatoj konstruitaj el tio, kion malkaŝas NAT, kaj relajsitaj kandidatoj asignitaj sur relajso. Privata adreso sola ne estas vojo, ĉar la alia flanko ne povas enkursigi al ĝi.
La relajsita kazo indas esti komprenata antaŭ ol forigi ĝin. RFC 8656 priskribas TURN kiel protokolon, en kiu kliento petas de servilo relajsitan transportan adreson kaj la servilo plusendas trafikon inter tiu kliento kaj ĝiaj samranguloj. Do la relajso portas la datumojn, kio substance diferencas de dosierujo, kiu nur helpas finpunktojn renkontiĝi. Interŝanĝi la relajsan adreson kun la samrangulo estas kunordiga paŝo, kiun la aplikaĵo devas fari.
Kion vi ne povas promesi, estas rekta vojo. Simetria NAT kaj kelkaj entreprenaj fajroŝirmiloj venkas truan boradon, kaj kiam ili tion faras, la sistemo aŭ retroiras al relajso aŭ malsukcesas. Vi ankaŭ ne povas konkludi, ke du tradukitaj finpunktoj neniam povas paroli; subtenata stako kun relajsa rezervo ekzistas ĝuste ĉar ili ofte povas. Decidu, ĉu havebleco aŭ rekto pli gravas, kaj poste kontrolu, kiun vojon la deplojo efektive elektis, anstataŭ supozi la feliĉan kazon.
Peranto estas pli mallarĝa ol reto
Kiam la postulo estas unu aplikaĵo, aplikaĵa peranto aŭ inversa konekto startigita de la laborejo povas esti la plej malgranda respondo. La laborejo vokas eksteren al peranto, la peranto aŭtentikigas la foran uzanton, kaj nur tiu aplikaĵa seanco estas portata. Neniu vojo al la subreto de la laborejo estas kreata, do kompromito de la fora seanco ne heredas vojon al ĉiu aparato apude.
Tiu mallarĝeco havas prezon: ĉiu plia aplikaĵo bezonas sian propran integriĝon, kaj io, kion la aplikaĵo supozas pri loka reto, ekzemple dosierpartigon, kiun ĝi malfermas sur proksima servilo, eble ne estas atingebla. Perantoj ankaŭ koncentras politikon kaj protokoladon en unu loko, kio utilas ĝis tiu loko fariĝas la paneo.
Komparu fido-limojn, poste testu la vojon
Centro, kiu finigas tunelojn, povas legi la trafikon, kiun ĝi enkursigas. Relajso povas porti sendepende protektitan interŝanĝon, kiam la aplikaĵo ĉifras de fino al fino, kaj peranto kutime finigas la seancn, kiun ĝi prezentas. Establu, kie protekto efektive finiĝas, antaŭ ol decidi, ke du dezajnoj estas ekvivalentaj ĉar ambaŭ estas ĉifritaj.
Poste kontrolu, kion la laborejo efektive atingas elire, ĉar ĉiu dezajno supre dependas de tio. Rulu ĉi tion sur la laborejo, anstataŭigante la gastignomon, kiun vi intencas uzi.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comAkceptu la dezajnon nur post kiam la celata fora operacio sukcesas sub la permesita identeco, neaprobita identeco estas rifuzata, kaj la konduto, kiam la rekta aŭ relajsita vojo ne haveblas, estas konata kaj dokumentita. Inkluzivu rekonon kaj la normalan startan kuntekston de la laborejo, ĉar seanco komencita en la oficejo per la loka reto testas nenion, de kio la fora aliro dependas.