Een werkstation achter NAT bereiken zonder port forwarding

Twee eindpunten achter de NAT van de provider en een vergrendelde kantoorrouter laten geen inkomende poort over om door te sturen, en de reflex is er toch een aanvragen. De betere vraag is welke kant naar buiten kan bellen en welke bereikbare dienst het verkeer mag dragen. Vier ontwerpen beantwoorden die vraag verschillend, en ze falen op verschillende manieren wanneer een pad geblokkeerd is. Kiezen tussen hen is een vergelijking van garanties, niet van protocolnamen.

Vier ontwerpen, vier verschillende beloften

De tabel hieronder is de korte versie. Lees de middelste kolom als de belofte die u kunt testen, en de rechterkolom als de belofte die niemand heeft gedaan.

Welke rij van toepassing is, hangt af van de taak en niet van de voorkeur. Eén sessie voor een extern bureaublad, één beheerdersshell en toegang tot een heel privaat subnet zijn drie vereisten die niet hetzelfde toegangspunt nodig hebben, zelfs niet als ze toevallig dezelfde machine betreffen.

Een hub verandert wie naar buiten belt, niet wat is toegestaan

In een ontwerp met een gerouteerde hub openen de externe laptop en het werkstation, of de sitegateway ervoor, elk een uitgaande tunnel naar een dienst die beide kunnen bereiken. Niets accepteert een ongevraagde verbinding op de router van het werkstation, en precies daarom overleeft dit ontwerp NAT en werkt het ook wanneer de site geen statisch adres heeft. Daarna routeert de hub verkeer tussen de twee interne adressen volgens zijn eigen beleid.

De prijs is dat de hub moet bestaan, vanaf beide kanten bereikbaar moet zijn en door iemand beheerd moet worden. Uitgaande filtering moet het transport toestaan, en een netwerk dat het blokkeert, zal het ontwerp verslaan ook al was er geen port forwarding nodig.

Het subtiele punt is dat bereikbaarheid en autorisatie aparte beslissingen zijn die op verschillende plaatsen worden genomen. Een route naar een prefix zegt niets over welke dienst op het werkstation de identiteit mag gebruiken, en een firewallregel die de tunnel toestaat zegt niets over of het account kan inloggen. Configureer beide, test beide, en houd de autorisatiebeslissing bij het systeem dat de resource bezit in plaats van bij de routingtabel.

Traversal werkt alleen als beide stacks het implementeren

Traversal tussen peers is een vermogen van een specifiek systeem, geen instelling die een VPN verbetert. Interactive Connectivity Establishment verzamelt meerdere kandidaatadressen en test paren tot er een werkt: hostkandidaten op lokale interfaces, server-reflexieve kandidaten opgebouwd uit wat een NAT onthult, en relaykandidaten die op een relay worden toegewezen. Een privaat adres alleen is geen pad, omdat de andere kant er niet naartoe kan routeren.

Het gerelayeerde geval is het waard te begrijpen voordat u het afwijst. RFC 8656 beschrijft TURN als een protocol waarin een client een server om een gerelayeerd transportadres vraagt en de server verkeer tussen die client en zijn peers doorstuurt. De relay draagt dus de gegevens, wat wezenlijk verschilt van een directory die alleen endpoints helpt elkaar te vinden. Het uitwisselen van het relayadres met de andere kant is een coördinatiestap die de applicatie moet uitvoeren.

Wat u niet kunt beloven, is een direct pad. Symmetrische NAT en sommige bedrijfsfirewalls verslaan hole punching, en wanneer dat gebeurt, valt het systeem terug op een relay of faalt het. U kunt ook niet concluderen dat twee vertaalde eindpunten nooit kunnen praten; een ondersteunde stack met relay-fallback bestaat juist omdat ze dat vaak wel kunnen. Bepaal of beschikbaarheid of directheid belangrijker is, en verifieer dan welk pad de implementatie werkelijk koos in plaats van het gunstige geval aan te nemen.

Een broker is smaller dan een netwerk

Wanneer de eis één applicatie is, kunnen een applicatiebroker of een omgekeerde verbinding die het werkstation start het kleinste antwoord zijn. Het werkstation belt naar buiten naar een broker, de broker authenticeert de externe gebruiker, en alleen die applicatiesessie wordt gedragen. Er wordt geen route naar het subnet van het werkstation gemaakt, dus een compromis van de externe sessie erft geen pad naar elk apparaat ernaast.

Die smalheid heeft een prijs: elke extra applicatie heeft zijn eigen integratie nodig, en alles wat de applicatie over een lokaal netwerk aanneemt, zoals een bestandsshare die het op een nabije server opent, is mogelijk niet bereikbaar. Brokers concentreren ook beleid en logging op één plek, wat nuttig is totdat die plek de storing wordt.

Vergelijk vertrouwensgrenzen en test dan het pad

Een hub die tunnels beëindigt, kan het verkeer lezen dat hij routeert. Een relay kan een afzonderlijk beschermde uitwisseling dragen wanneer de applicatie van begin tot eind versleutelt, en een broker beëindigt meestal de sessie die hij presenteert. Stel vast waar de bescherming werkelijk eindigt voordat u besluit dat twee ontwerpen gelijkwaardig zijn omdat beide versleuteld zijn.

Controleer dan wat het werkstation uitgaand werkelijk bereikt, want elk ontwerp hierboven hangt daarvan af. Voer dit uit op het werkstation en vervang de hostnaam die u wilt gebruiken.

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

Accepteer het ontwerp pas nadat de beoogde externe bewerking slaagt onder de toegestane identiteit, een niet-goedgekeurde identiteit wordt geweigerd, en het gedrag wanneer het directe of gerelayeerde pad niet beschikbaar is bekend en gedocumenteerd is. Neem een herverbinding en de normale opstartcontext van het werkstation op, want een sessie die op kantoor via het LAN begon, test niets waarvan externe toegang afhangt.