Portvidarebefordran kontra VPN-åtkomst: vart paketet faktiskt tar vägen

En portvidarebefordran skriver om målet och stannar där; en VPN packar in paketet först. Se vilket lager var och en ändrar och vad det innebär för HTTPS.

Två designer, en HTTPS-applikation, och paketet tar olika väg i varje. En portvidarebefordran ändrar var paketet levereras och lämnar resten i fred. En VPN bär paketet inuti ett annat paket först, så applikationens lyssnare ser en annan källa och en mindre maximal nyttolast. Krypteringen som folk diskuterar finns i båda fallen, eftersom applikationen fortfarande är HTTPS; det som skiljer är vem som får öppna en anslutning och vad nätet däremellan kan observera. Den skillnaden avgör de flesta praktiska frågor.

DNAT-regeln skriver om målet och stannar där

På en Linux-gateway innebär att publicera en tjänst en regel i nat-tabellens PREROUTING-kedja, eller motsvarigheten i nftables. Regeln matchar den offentliga adressen och porten och skriver sedan om målet till applikationens privata adress. Källadress, källport och nyttolast lämnas orörda, och conntrack registrerar mappningen så att svar skrivs tillbaka vid utgång. Beteendet är den traditionella adressöversättningsmodell som beskrivs i RFC 3022.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

Applikationens lyssnare får aldrig veta att anslutningen kom via en översättning. Den ser klientens verkliga källadress, vilket är användbart för åtkomstloggar och hastighetsgränser, och den svarar till den privata adressen eftersom conntrack vänder mappningen. Inget på den vägen dekrypterar eller krypterar om: TLS går fortfarande mellan klienten och applikationens eget certifikat.

Regeln fastställer också de fellägen du kommer att möta senare. Om gatewayen vidarebefordrar men applikationens värd saknar någon returväg till klienten, lämnar svaren med fel källa och handskakningen fastnar. Om en andra regel matchar först avgör ordningen resultatet, och iptables -t nat -L -n -v visar räknarna som bevisar vilken regel som tog paketet.

Tunneln packar in paketet innan lyssnaren ser det

En VPN publicerar inte applikationen alls. Klienten bygger ett yttre paket adresserat till gatewayens offentliga adress, krypterar det inre paketet inuti, och gatewayen dekrypterar och dirigerar det inre paketet till det privata målet. Med WireGuard är den yttre transporten UDP, vanligtvis på en hög port; med OpenVPN över TCP 443 ser det yttre paketet ut som TLS för allt som övervakar vägen.

Inuti tunneln behåller det inre paketet privata adresser: klientens tunneladress, säg 10.8.0.6, och applikationen på 10.20.30.40. Lyssnaren ser därför en källa från tunnelpoolen, och varje klient delar den gatewayen som nästa hopp. Åtkomstloggar bakom en VPN visar ofta gatewayen i stället för användaren just av denna anledning, om inte gatewayen bevarar den ursprungliga källan.

Inpackningen kostar rubrikutrymme, och det är den enda skillnaden på mekanismnivå med en mätbar konsekvens. En yttre IP-rubrik plus UDP plus WireGuards egen rubrik äter av vägens MTU, så stora paket måste fragmenteras eller den inre TCP-stacken måste begränsa sitt MSS. En överföring som fungerar på den vidarebefordrade vägen kan fastna på tunneln när en mellanliggande enhet släpper den ICMP som skulle ha signalerat den mindre MTU:n.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Exponering avgörs vid ingången, inte av chiffret

Båda designerna slutar vid samma TLS-lyssnare, så båda ärver samma certifikat, samma protokollversioner och samma applikationsinloggning. Det som ändras är vem som får inleda en handskakning. Med en offentlig vidarebefordran får varje värd som når 203.0.113.10:443 en TCP-handskakning och en TLS ClientHello innan applikationens auktorisering ens beaktas. Med åtkomst bara via tunneln är lyssnaren bara nåbar från adresser som gatewayen dirigerar in i tunneln, och en främmandes SYN dör vid gatewaypolicyn.

Den skillnaden handlar om nåbarhet, inte om sekretess. En vidarebefordrad HTTPS-tjänst är inte klartext, och en VPN tar inte bort behovet av applikationsautentisering: tunnelintag svarar på om en enhet får skicka paket in i detta nät, medan filapplikationen svarar på om en användare får läsa ett dokument. Att blanda ihop de två är hur team hamnar med en VPN som ger hela LAN:et och en applikation med ett enda delat lösenord.

Undersök lyssnaren och policyn var för sig, eftersom var och en av dem kan vara bredare än du antar:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Om ss visar att lyssnaren är bunden till 0.0.0.0, är applikationen nåbar varifrån routing och brandväggspolicy tillåter det, och vidarebefordran är bara en av vägarna in. Att binda till den privata adressen, eller begränsa källområdet i brandväggen, är ett beslut skilt från valet av VPN, och det är beslutet som faktiskt minskar exponeringen.

Mät vägen, inte etiketten

När någon hävdar att vidarebefordran är snabbare håller den ärliga jämförelsen allt annat konstant: samma klient, samma åtkomstnät, samma fil, samma TLS-konfiguration, samma applikationsvärd. Kör överföringen två gånger per väg och notera total tid, antal fel och responsivitet, inte utdata från ett orelaterat hastighetstest.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

De siffrorna skiljer anslutningsuppbyggnad från överföringstid, vilket spelar roll eftersom de två vägarna vanligtvis skiljer sig i rundturfördröjning och MTU snarare än i chiffmerkostnad. TLS-arbete sker vid ändpunkterna i båda designerna, och en tunnel lägger till inkapsling, en annan väg och möjligen en mer belastad gateway. Om tunnelvägen är längre eller dess gateway är belastad hör skillnaden till vägen och inte till ordet kryptering.

Välj den ingångspolicy tjänsten faktiskt behöver, och avgör sedan om en uppmätt skillnad motiverar att ändra den. En offentlig vidarebefordran passar för en tjänst avsedd för det öppna internet, med källbegränsningar, uppdaterad TLS och övervakning framför. Åtkomst bara via tunneln passar för ett internt verktyg vars användare redan är registrerade, förutsatt att gatewayens routing och applikationens behörigheter båda är smalare än hela LAN:et.

Innan du kallar designen klar, bekräfta fyra saker: vilken adress lyssnaren är bunden till, vilken regel eller väg som släpper in paketet, om returvägen fungerar från klientens verkliga adress, och om stora nyttolaster klarar MTU:n. Var och en av dem har ett kommando ovan, och ingen av dem besvaras med ordet säker eller ett bandbreddsdiagram.

Relaterade artiklar