Dosegnite radnu stanicu iza NAT-a bez prosljeđivanja porta
Radna stanica bez ulaznog porta i dalje je dostupna kroz hub, relej ili broker aplikacija. Uporedite šta svaki dizajn garantuje prije nego što izaberete jedan.
Dvije krajnje točke iza NAT-a operatera i zaključan uredski ruter ne ostavljaju nijedan ulazni port za prosljeđivanje, a refleks je ipak zatražiti ga. Bolje pitanje je koja strana može zvati prema van i kojoj dostupnoj usluzi je dopušteno nositi promet. Četiri dizajna odgovaraju na to pitanje različito i podbacuju na različite načine kada je put blokiran. Izbor među njima je poređenje garancija, a ne naziva protokola.
Četiri dizajna, četiri različita obećanja
Tabela ispod je kratka verzija. Čitajte srednju kolonu kao obećanje koje možete testirati, a desnu kolonu kao obećanje koje niko nije dao.
| 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 |
Koji red važi zavisi od zadatka, a ne od preferencije. Jedna sesija udaljene radne površine, jedan administrativni shell i pristup cijeloj privatnoj podmreži su tri zahtjeva kojima ne treba ista ulazna točka, čak i kada slučajno uključuju istu mašinu.
Hub mijenja ko zove prema van, a ne šta je dopušteno
U dizajnu s rutiranim hubom udaljeni laptop i radna stanica, ili mrežni gateway ispred nje, svaki otvara odlazni tunel prema usluzi do koje oba mogu doći. Ništa ne prihvata neželjenu konekciju na ruteru radne stanice, i upravo zato ovaj dizajn preživljava NAT i radi kada lokacija nema statičnu adresu. Hub zatim rutira promet između dvije unutrašnje adrese prema vlastitoj politici.
Cijena je da hub mora postojati, mora biti dostupan s obje strane i mora ga neko voditi. Odlazno filtriranje mora dopustiti transport, a mreža koja ga blokira osujetit će dizajn iako nikakvo prosljeđivanje porta nije bilo potrebno.
Suptilni dio je da su dostupnost i autorizacija odvojene odluke donesene na različitim mjestima. Ruta u prefiks ne govori ništa o tome kojoj usluzi na radnoj stanici identitet smije pristupiti, a pravilo firewall-a koje dopušta tunel ne govori ništa o tome može li se račun prijaviti. Konfigurišite oboje, testirajte oboje i zadržite odluku o autorizaciji uz sistem koji posjeduje resurs, a ne uz routing tabelu.
Proboj radi samo kada ga implementiraju oba stacka
Proboj između ravnopravnih čvorova je sposobnost određenog sistema, a ne postavka koja poboljšava VPN. Interactive Connectivity Establishment prikuplja nekoliko kandidatskih adresa i testira parove dok jedan ne proradi: kandidate hosta na lokalnim interfejsima, server-refleksivne kandidate izgrađene od onoga što NAT otkrije i relejne kandidate dodijeljene na releju. Privatna adresa sama po sebi nije put, jer druga strana ne može rutirati do nje.
Relejni slučaj vrijedi razumjeti prije nego što ga odbacite. RFC 8656 opisuje TURN kao protokol u kojem klijent traži od servera relejnu transportnu adresu, a server prosljeđuje promet između tog klijenta i njegovih ravnopravnih čvorova. Relej dakle nosi podatke, što se bitno razlikuje od imenika koji samo pomaže krajnjim točkama da se sretnu. Razmjena relejne adrese s drugom stranom je korak koordinacije koji aplikacija mora izvesti.
Ono što ne možete obećati je direktan put. Simetrični NAT i neki korporativni firewall-i osujećuju probijanje rupa, a kada to učine, sistem se ili vraća na relej ili podbacuje. Također ne možete zaključiti da dva prevedena kraja nikada ne mogu razgovarati; podržan stack s relejnim fallback-om postoji upravo zato što često mogu. Odlučite da li je važnija dostupnost ili direktnost, pa provjerite koji je put implementacija zaista odabrala, umjesto da pretpostavite povoljan slučaj.
Broker je uži od mreže
Kada je zahtjev jedna aplikacija, broker aplikacija ili obrnuta konekcija koju pokrene radna stanica može biti najmanji odgovor. Radna stanica zove prema van do brokera, broker autentificira udaljenog korisnika i nosi se samo ta aplikacijska sesija. Nikakva ruta do podmreže radne stanice se ne stvara, pa kompromitacija udaljene sesije ne nasljeđuje put do svakog uređaja pored nje.
Ta uskost ima cijenu: svaka dodatna aplikacija treba vlastitu integraciju, a sve što aplikacija pretpostavi o lokalnoj mreži, poput dijeljenja datoteka koje otvori na obližnjem serveru, možda neće biti dostupno. Brokeri također koncentrišu politiku i logovanje na jednom mjestu, što je korisno dok to mjesto ne postane ispad.
Uporedite granice povjerenja, pa testirajte put
Hub koji završava tunele može čitati promet koji rutira. Relej može nositi nezavisno zaštićenu razmjenu kada aplikacija šifrira od kraja do kraja, a broker obično završava sesiju koju predstavlja. Utvrdite gdje zaštita zaista prestaje prije nego što zaključite da su dva dizajna ekvivalentna jer su oba šifrirana.
Zatim provjerite do čega radna stanica zaista dolazi prema van, jer svaki dizajn iznad zavisi od toga. Pokrenite ovo na radnoj stanici, zamjenjujući ime hosta koje namjeravate koristiti.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comPrihvatite dizajn tek kada namjeravana udaljena operacija uspije pod dopuštenim identitetom, neodobreni identitet bude odbijen, a ponašanje kada direktan ili relejni put nije dostupan bude poznato i dokumentovano. Uključite ponovno povezivanje i uobičajen kontekst pokretanja radne stanice, jer sesija koja je počela u uredu preko LAN-a ne testira ništa o čemu ovisi udaljeni pristup.