Portutlösning kontra portvidarebefordran för en VPN-server hemma

Portvidarebefordran och portutlösning ligger i samma meny på de flesta hemmaroutrar, och därför behandlas de som två sätt att göra ett jobb. Vidarebefordran är en statisk regel: en inkommande anslutning till en WAN-port översätts till en fast intern adress och port, oavsett om något annat händer. Utlösning är villkorad: routern övervakar utgående trafik och öppnar en inkommande mappning först när en matchande anslutning går ut. En VPN-server väntar på att någon annan ansluter först, så just det villkoret är det enda den aldrig kan uppfylla.

Två regler med olika livscykler

IPv4-NAT är tillståndsbaserad. När en intern värd skickar ett paket ut skapar routern en mappning så att svar hittar tillbaka; ett inkommande paket som inte matchar någon mappning slängs, och det beteendet håller en ouppdaterad dator utanför internet. Vidarebefordran är en permanent översättningspost som läggs till för hand. Utlösning är ett tillfälligt hål som vaktas av ett trafikmönster.

Den praktiska skillnaden är tid. En vidarebefordran finns från det att den sparas tills någon tar bort den. En utlöst mappning finns efter att utlösaren slår till och stängs på en inaktivitetstimer, mätt i minuter på konsumenthårdvara, eller direkt vid omstart.

Ingen av dem är säkrare i abstrakt mening. En vidarebefordran exponerar en port hela tiden; en utlösare exponerar den först efter viss utgående trafik. För en tjänst som måste ta emot det första paketet från en främling passar bara en av de två.

Varför utlösning inte publicerar en server

En VPN-server är passiv av design. Motparten, vare sig det är en bärbar dator på ett kafé eller en telefon på mobildata, skickar det första paketet, och routern har ingen mappning för det. Ingenting inifrån har startat trafik till utlösarporten, så regeln slår aldrig till och anslutningen dör innan handskakningen börjar.

Där utlösning verkar fungera genererar något annat trafik på utlösarporten: en klient på LAN, en övervakningssond eller serverns egna utgående kontroller. Då öppnas mappningen för den enda värden och stängs när trafiken upphör, så nästa externa motpart misslyckas igen medan den första framgången ligger i loggen och ser ut som bevis.

Utlösning är också oftast för en enda värd. Många implementationer låter bara en intern enhet hålla mappningen i taget, vilket är precis fel för en server som ska svara flera motparter. Funktionen byggdes för program som öppnar en kontrollanslutning utåt och förväntar sig inkommande data på en andra port, och den passar fortfarande den formen.

Vad en vidarebefordran faktiskt mappar

En vidarebefordran är en enda översättningspost: WAN-port och protokoll till intern adress och port. Den behöver en lyssnare som redan kör i andra änden, och den behöver att den interna adressen stannar där den är. En DHCP-lease som flyttar till en annan maskin skickar varje tunnel till fel värd, i tysthet, så skapa reservationen före regeln.

Protokollet spelar större roll än formuläret antyder. OpenVPN över UDP behöver en UDP-vidarebefordran, WireGuard behöver UDP, och IPsec-data kommer som ESP, IP-protokoll 50, som inte har några portar alls. Ett vidarebefordringsformulär som bara accepterar TCP eller UDP kan inte uttrycka det, så IPsec behöver passthrough eller en statisk ett-till-ett-mappning i stället för en portregel.

Lagret ovanför din router

En vidarebefordran styr bara den översättning du äger. Om WAN-adressen inte är din, vilket är fallet bakom operatörs-NAT där abonnenter delar 100.64.0.0/10 som beskrivs i RFC 6598, når den inkommande anslutningen aldrig din router eftersom leverantören översatte först. Ingen regel på din enhet kan rätta till den ordningen.

Dubbel NAT är samma problem i miniatyr. Din router vidarebefordrar till ISP-routern, som inte har någon matchande regel och kastar paketet. Antingen lägger du till regeln på den yttre enheten, eller sätter den yttre enheten i bryggläge och låter din behålla den offentliga adressen.

Därför måste testet komma utifrån. Ett test från samma LAN via den offentliga adressen beror på hairpin-NAT-stöd och kan lyckas eller misslyckas av skäl som inte har med regeln att göra; en telefon på mobildata, eller en vän på ett annat nätverk, är den renare kontrollen.

Avgränsa regeln och verifiera sedan båda halvorna

Vidarebefordra en port till en adress. Ett intervall som lades till för att de första försöken misslyckades är hur administrationsgränssnitt hamnar på internet, och VPN-lyssnaren behöver inte routerns admin-sida publicerad bredvid.

Behåll allt som redan skyddade den lyssnaren: certifikat- eller nyckelidentitet, värdens brandvägg, aktuella paketversioner. En vidarebefordran släpper in ett paket; autentiseringen avgör om paketet blir en tunnel, och det är två separata fel när något går snett.

Verifieringen har två halvor. Handskakningen måste slutföras från ett externt nätverk, och sedan måste en privat resurs bakom servern svara genom tunneln. Vidarebefordran släpper in tunnelanslutningen och inget mer; routning och auktorisering för 10.8.0.0/24 är en annan inställning på en annan skärm.

Bestäm med tre frågor

Tre frågor avgör valet snabbare än någon jämförelsetabell:

• Ansluter något utifrån som det första paketet? Använd då vidarebefordran, eller ett relä. Utlösning kan inte öppnas utan utgående trafik som aldrig kommer att finnas.
• Måste hålet överleva inaktiv tid? Använd då vidarebefordran, eftersom en utlöst mappning stängs enligt sitt eget schema.
• Är WAN-adressen din att publicera? Om inte, reparera lagret ovanför innan du redigerar någon regel.

Om svaret på alla tre är nej, vilket är fallet för en bärbar dator som själv ringer en kommersiell leverantör, behövs ingen av reglerna. En klient bakom NAT fungerar eftersom den själv skapar den tillståndsbaserade mappningen, och det täcker de flesta som läser en sida om portvidarebefordran vid midnatt.