Dva koncové body za NAT operátora a uzamknutý kancelársky router nenechávajú žiadny prichádzajúci port na presmerovanie a reflex je napriek tomu o jeden požiadať. Lepšia otázka je, ktorá strana môže volať von a ktorej dostupnej službe je dovolené niesť prevádzku. Štyri návrhy odpovedajú na túto otázku rôzne a zlyhávajú rôzne, keď je cesta zablokovaná. Výber medzi nimi je porovnanie záruk, nie názvov protokolov.

Štyri návrhy, štyri rôzne sľuby

Tabuľka nižšie je krátka verzia. Čítajte stredný stĺpec ako sľub, ktorý môžete otestovať, a pravý stĺpec ako sľub, ktorý nikto nedal.

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

Ktorý riadok platí, závisí od úlohy, nie od preferencie. Jedna relácia vzdialenej plochy, jedna administratívna konzola a prístup do celej privátnej podsiete sú tri požiadavky, ktoré nepotrebujú rovnaký vstupný bod, aj keď sa náhodou týkajú toho istého stroja.

Koncentrátor mení, kto volá von, nie to, čo je dovolené

V návrhu s routovaným koncentrátorom vzdialený notebook a pracovná stanica, alebo sieťová brána pred ňou, otvárajú každý odchádzajúci tunel k službe, na ktorú obe dosiahnu. Nič neprijíma nevyžiadané spojenie na routeri pracovnej stanice, a práve preto tento návrh prežíva NAT a funguje aj vtedy, keď lokalita nemá statickú adresu. Potom koncentrátor smeruje prevádzku medzi dvoma vnútornými adresami podľa vlastnej politiky.

Cena je, že koncentrátor musí existovať, musí byť dostupný z oboch strán a musí ho niekto prevádzkovať. Odchádzajúce filtrovanie musí transport povoliť, a sieť, ktorá ho blokuje, návrh zmarí, aj keď presmerovanie portu nebolo potrebné.

Jemná časť je, že dostupnosť a autorizácia sú oddelené rozhodnutia prijímané na rôznych miestach. Trasa do prefixu nehovorí nič o tom, ktorú službu na pracovnej stanici smie identita použiť, a pravidlo firewallu, ktoré tunel povoľuje, nehovorí nič o tom, či sa účet môže prihlásiť. Nastavte oboje, otestujte oboje a rozhodnutie o autorizácii ponechajte pri systéme, ktorý vlastní zdroj, nie pri smerovacej tabuľke.

Prechod funguje len vtedy, keď ho implementujú oba stacky

Prechod medzi rovnocennými uzlami je schopnosť konkrétneho systému, nie nastavenie, ktoré vylepšuje VPN. Interactive Connectivity Establishment zhromažďuje niekoľko kandidátskych adries a testuje dvojice, kým jedna nefunguje: kandidáti hostiteľa na lokálnych rozhraniach, serverovo reflexné kandidáty postavené z toho, čo prezradí NAT, a relayované kandidáty pridelené na relayi. Samotná privátna adresa nie je cesta, pretože druhá strana k nej nevie smerovať.

Relayovaný prípad stojí za pochopenie, kým ho odmietnete. RFC 8656 opisuje TURN ako protokol, v ktorom klient žiada server o relayovanú transportnú adresu a server preposiela prevádzku medzi týmto klientom a jeho protistranami. Relay teda nesie dáta, čo je podstatne iné ako adresár, ktorý len pomáha koncovým bodom stretnúť sa. Výmena relayovej adresy s druhou stranou je krok koordinácie, ktorý musí aplikácia vykonať.

To, čo nemôžete sľúbiť, je priama cesta. Symetrický NAT a niektoré podnikové firewally porážajú prebíjanie dier, a keď sa tak stane, systém buď prejde na relay, alebo zlyhá. Nemôžete ani usúdiť, že dva preložené koncové body spolu nikdy nebudú môcť hovoriť; podporovaný stack s relayovou zálohou existuje práve preto, že často môžu. Rozhodnite, či je dôležitejšia dostupnosť alebo priamosť, a potom overte, ktorú cestu nasadenie skutočne zvolilo, namiesto predpokladu priaznivého prípadu.

Broker je užší ako sieť

Keď je požiadavkou jedna aplikácia, broker aplikácií alebo reverzné spojenie spustené pracovnou stanicou môžu byť najmenšou odpoveďou. Pracovná stanica volá von k brokerovi, broker overí vzdialeného používateľa a prenáša sa len táto aplikačná relácia. Nevzniká žiadna trasa do podsiete pracovnej stanice, takže kompromitácia vzdialenej relácie nezdedí cestu ku každému zariadeniu vedľa.

Táto úzkosť má cenu: každá ďalšia aplikácia potrebuje vlastnú integráciu a čokoľvek, čo aplikácia predpokladá o lokálnej sieti, napríklad zdieľanú zložku, ktorú otvára na blízkom serveri, nemusí byť dostupné. Brokeri tiež sústreďujú politiku a logovanie na jedno miesto, čo je užitočné, kým sa to miesto nestane výpadkom.

Porovnajte hranice dôvery, potom otestujte cestu

Koncentrátor, ktorý ukončuje tunely, môže čítať prevádzku, ktorú smeruje. Relay môže niesť nezávisle chránenú výmenu, keď aplikácia šifruje od konca ku koncu, a broker zvyčajne ukončuje reláciu, ktorú predkladá. Určite, kde ochrana skutočne končí, skôr než rozhodnete, že dva návrhy sú rovnocenné, pretože oba sú šifrované.

Potom skontrolujte, kam pracovná stanica skutočne dosiahne odchádzajúcim smerom, pretože na tom závisí každý návrh vyššie. Spustite to na pracovnej stanici a nahraďte názov hostiteľa, ktorý hodláte použiť.

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

Návrh prijmite až potom, čo zamýšľaná vzdialená operácia uspeje pod povolenou identitou, neoprávnená identita je odmietnutá a správanie pri nedostupnej priamej alebo relayovanej ceste je známe a zdokumentované. Zahrňte opätovné pripojenie a bežný kontext spustenia pracovnej stanice, pretože relácia začatá v kancelárii cez LAN neotestuje nič, na čom závisí vzdialený prístup.

Súvisiace články