Jak dosáhnout na pracovní stanici za NAT bez přesměrování portu
Pracovní stanice bez příchozího portu je přesto dostupná přes hub, relay nebo broker aplikací. Porovnejte, co který návrh garantuje, než jeden vyberete.
Dva koncové body za NAT operátora a uzamčený kancelářský router nenechávají žádný příchozí port k přesměrování a reflex je stejně o jeden požádat. Lepší otázka je, která strana může volat ven a které dostupné službě je dovoleno nést provoz. Čtyři návrhy odpovídají na tuto otázku různě a selhávají různě, když je cesta zablokovaná. Výběr mezi nimi je porovnání záruk, ne názvů protokolů.
Čtyři návrhy, čtyři různé sliby
Tabulka níže je krátká verze. Čtěte prostřední sloupec jako slib, který můžete otestovat, a pravý sloupec jako slib, který nikdo nedal.
| 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 |
Který řádek platí, závisí na úkolu, ne na preferenci. Jedno sezení vzdálené plochy, jedna administrativní konzole a přístup do celé privátní podsítě jsou tři požadavky, které nepotřebují stejný vstupní bod, i když se náhodou týkají stejného stroje.
Hub mění, kdo volá ven, ne co je povoleno
V návrhu s routovaným hubem vzdálený notebook a pracovní stanice, nebo síťová brána před ní, každý otevírá odchozí tunel ke službě, na kterou oba dosáhnou. Nic nepřijímá nevyžádané spojení na routeru pracovní stanice, a právě proto tento návrh přežívá NAT a funguje, když lokalita nemá statickou adresu. Hub pak směruje provoz mezi dvěma vnitřními adresami podle vlastní politiky.
Cena je, že hub musí existovat, musí být dostupný z obou stran a musí ho někdo provozovat. Odchozí filtrování musí transport povolit, a síť, která ho blokuje, návrh zmaří, i když přesměrování portu nebylo potřeba.
Jemná část je, že dostupnost a autorizace jsou oddělená rozhodnutí učiněná na různých místech. Trasa do prefixu neříká nic o tom, kterou službu na pracovní stanici smí identita použít, a pravidlo firewallu, které tunel povoluje, neříká nic o tom, zda se účet může přihlásit. Nastavte obojí, otestujte obojí a rozhodnutí o autorizaci ponechte u systému, který vlastní zdroj, ne u směrovací tabulky.
Průchod funguje jen tehdy, když ho implementují oba stacky
Průchod mezi rovnocennými uzly je schopnost konkrétního systému, ne nastavení, které vylepšuje VPN. Interactive Connectivity Establishment shromažďuje několik kandidátských adres a testuje dvojice, dokud jedna nefunguje: kandidáty hostitele na lokálních rozhraních, server-reflexivní kandidáty postavené z toho, co NAT prozradí, a relayované kandidáty přidělené na relayi. Privátní adresa sama o sobě není cesta, protože druhá strana k ní neumí směrovat.
Relayovaný případ stojí za pochopení, než ho odmítnete. RFC 8656 popisuje TURN jako protokol, ve kterém klient žádá server o relayovanou transportní adresu a server přeposílá provoz mezi tímto klientem a jeho protějšky. Relay tedy nese data, což je podstatně jiné než adresář, který jen pomáhá koncovým bodům se setkat. Výměna relayové adresy s protějškem je krok koordinace, který musí aplikace provést.
Co nemůžete slíbit, je přímá cesta. Symetrický NAT a některé podnikové firewally ničí prolamování děr, a když se to stane, systém buď přejde na relay, nebo selže. Také nemůžete usoudit, že dva přeložené koncové body spolu nikdy nemohou mluvit; podporovaný stack s relayovým záložním řešením existuje právě proto, že často mohou. Rozhodněte, zda je důležitější dostupnost, nebo přímost, a pak ověřte, kterou cestu nasazení skutečně zvolilo, místo abyste předpokládali příznivý případ.
Broker je užší než síť
Když je požadavkem jedna aplikace, broker aplikací nebo reverzní spojení spuštěné pracovní stanicí může být nejmenší odpověď. Pracovní stanice volá ven k brokerovi, broker ověří vzdáleného uživatele a přenáší se jen toto aplikační sezení. Nevzniká žádná trasa do podsítě pracovní stanice, takže kompromitace vzdáleného sezení nedědí cestu ke každému zařízení vedle.
Tato úzkost má cenu: každá další aplikace potřebuje vlastní integraci a cokoli, co aplikace předpokládá o lokální síti, například sdílenou složku, kterou otevírá na blízkém serveru, nemusí být dostupné. Broker také soustředí politiku a logování na jedno místo, což je užitečné, dokud se to místo nestane výpadkem.
Porovnejte hranice důvěry, pak otestujte cestu
Hub, který ukončuje tunely, může číst provoz, který směruje. Relay může nést nezávisle chráněnou výměnu, když aplikace šifruje end to end, a broker obvykle ukončuje sezení, které předkládá. Určete, kde ochrana skutečně končí, než rozhodnete, že dva návrhy jsou rovnocenné, protože oba jsou šifrované.
Pak zkontrolujte, kam pracovní stanice skutečně dosáhne odchozím směrem, protože na tom závisí každý návrh výše. Spusťte to na pracovní stanici a nahraďte název hostitele, který hodláte použít.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comNávrh přijměte až poté, co zamýšlená vzdálená operace uspěje pod povolenou identitou, neoprávněná identita je odmítnuta a chování při nedostupné přímé nebo relayované cestě je známé a zdokumentované. Zahrňte opětovné připojení a běžný kontext spuštění pracovní stanice, protože sezení zahájené v kanceláři přes LAN neotestuje nic, na čem vzdálený přístup závisí.