Port-triggering versus port-forwarding voor een VPN-server thuis

Port-forwarding en port-triggering staan op de meeste thuisrouters in hetzelfde menu, en daarom worden ze behandeld als twee manieren om één klus te doen. Forwarding is een statische regel: een inkomende verbinding naar een WAN-poort wordt vertaald naar een vast intern adres en een vaste poort, of er nu iets anders gebeurt of niet. Triggering is voorwaardelijk: de router houdt uitgaand verkeer in de gaten en opent pas een inkomende mapping nadat een passende verbinding naar buiten gaat. Een VPN-server wacht tot iemand anders eerst verbindt, dus juist die voorwaarde is het enige dat hij nooit kan vervullen.

Twee regels met verschillende levenscycli

IPv4-NAT is stateful. Wanneer een interne host een pakket naar buiten stuurt, maakt de router een mapping aan zodat antwoorden de weg terug vinden; een inkomend pakket dat bij geen enkele mapping past, wordt weggegooid, en dat gedrag houdt een niet-bijgewerkte desktop buiten het internet. Forwarding is een permanente vertaalregel die met de hand wordt toegevoegd. Triggering is een tijdelijk gat dat door een verkeerspatroon wordt bewaakt.

Het praktische verschil is tijd. Een forward bestaat vanaf het moment dat hij wordt opgeslagen tot iemand hem verwijdert. Een getriggerde mapping bestaat nadat de trigger afgaat en sluit op een idle-timer, gemeten in minuten op consumentenhardware, of meteen bij een herstart.

Geen van beide is abstract veiliger. Een forward stelt één poort doorlopend bloot; een trigger stelt hem pas na bepaald uitgaand verkeer bloot. Voor een dienst die het eerste pakket van een vreemde moet aannemen, past maar één van de twee bij de taak.

Waarom triggering geen server publiceert

Een VPN-server is naar zijn aard passief. De tegenpartij, of dat een laptop in een café of een telefoon op mobiele data is, stuurt het eerste pakket, en de router heeft er geen mapping voor. Niets binnen heeft verkeer naar de trigger-poort gestart, dus de regel gaat nooit af en de verbinding sterft voordat de handshake begint.

Waar triggering lijkt te werken, genereert iets anders verkeer op de trigger-poort: een client op de LAN, een monitoringssonde of de eigen uitgaande controles van de server. Dan opent de mapping voor die ene host en sluit weer wanneer het verkeer stopt, dus de volgende externe tegenpartij mislukt opnieuw terwijl het eerste succes in het log staat en als bewijs uitziet.

Triggering is meestal ook voor één host. Veel implementaties laten slechts één intern apparaat tegelijk de mapping houden, wat precies verkeerd is voor een server die meerdere tegenpartijen moet antwoorden. De functie is gebouwd voor toepassingen die uitgaand een controleverbinding openen en inkomende data op een tweede poort verwachten, en hij past nog steeds bij die vorm.

Wat een forward werkelijk mapt

Een forward is één vertaalregel: WAN-poort en protocol naar intern adres en poort. Hij heeft een listener nodig die al aan de andere kant draait, en hij heeft nodig dat het interne adres blijft waar het is. Een DHCP-lease die naar een andere machine verhuist, stuurt elke tunnel stilzwijgend naar de verkeerde host, dus maak de reservering vóór de regel.

Het protocol is belangrijker dan het formulier suggereert. OpenVPN over UDP heeft een UDP-forward nodig, WireGuard heeft UDP nodig, en IPsec-data komt binnen als ESP, IP-protocol 50, dat helemaal geen poorten heeft. Een forwardingformulier dat alleen TCP of UDP accepteert, kan dat niet uitdrukken, dus IPsec heeft passthrough of een statische één-op-één-mapping nodig in plaats van een poortregel.

De laag boven je router

Een forward beheert alleen de vertaling die van jou is. Als het WAN-adres niet van jou is, wat het geval is achter carrier-grade NAT waar abonnees 100.64.0.0/10 delen zoals beschreven in RFC 6598, bereikt de inkomende verbinding je router nooit, omdat de provider eerst vertaalde. Geen enkele regel op je apparaat kan die volgorde herstellen.

Dubbel NAT is hetzelfde probleem in het klein. Je router stuurt door naar de ISP-router, die geen passende regel heeft en het pakket weggooit. Voeg de regel toe op het buitenste apparaat, of zet dat apparaat in bridge-modus en laat het jouwe het publieke adres houden.

Daarom moet de test van buiten komen. Een test vanaf dezelfde LAN via het publieke adres hangt af van hairpin-NAT-ondersteuning en kan slagen of falen om redenen die niets met de regel te maken hebben; een telefoon op mobiele data, of een vriend op een ander netwerk, is de schonere controle.

Begrens de regel en verifieer dan beide helften

Stuur één poort door naar één adres. Een bereik dat is toegevoegd omdat de eerste pogingen faalden, is hoe beheerinterfaces op het internet belanden, en de VPN-listener heeft de adminpagina van de router er niet naast gepubliceerd nodig.

Behoud alles wat die listener al beschermde: identiteit via certificaat of sleutel, host-firewall, actuele pakketversies. Een forward laat een pakket binnen; authenticatie bepaalt of het pakket een tunnel wordt, en dat zijn twee aparte fouten wanneer er iets misgaat.

De verificatie heeft twee helften. De handshake moet vanaf een extern netwerk slagen, en daarna moet een privébron achter de server via de tunnel antwoorden. Forwarding laat de tunnelverbinding binnen en niets meer; routering en autorisatie voor 10.8.0.0/24 zijn een andere instelling op een ander scherm.

Beslis met drie vragen

Drie vragen beslechten de keuze sneller dan welke vergelijkingstabel dan ook:

• Verbindt er iets van buiten, als het eerste pakket? Gebruik dan forwarding, of een relay. Triggering kan niet opengaan zonder uitgaand verkeer dat er nooit zal zijn.
• Moet het gat idle-tijd overleven? Gebruik dan forwarding, want een getriggerde mapping sluit volgens zijn eigen schema.
• Is het WAN-adres van jou om te publiceren? Zo niet, herstel de laag erboven voordat je een regel aanpast.

Als het antwoord op alle drie nee is, wat het geval is voor een laptop die zelf een commerciële provider belt, is geen van beide regels nodig. Een client achter NAT werkt omdat hij zelf de stateful mapping maakt, en dat dekt de meeste mensen die om middernacht een pagina over port-forwarding lezen.