Klientens källport kontra serverns lyssnarport i ett VPN-flöde
Jämför de två portnumren i en tunnel: serverns fasta lyssnare och klientens kortlivade källa, och hur routerns översättning ligger mellan dem.
I samma samtal dyker två nummer upp och ingen av dem är fel. Serverloggen visar lyssnaren som erbjuder tjänsten, laptopen visar socketen som skickade datagrammet, och en router emellan kan skriva om den andra på väg ut. Det är mer användbart att jämföra samtalets ändar än att jämföra siffrorna. Jämförelsen nedan håller lyssnaren, klientens socket och den översatta källan åtskilda, eftersom de svarar på olika frågor.
Två nummer som beskriver motsatta ändar
Serverns konfigurerade port är destinationen som klienten ringer. Den är fastställd av policy, står i profilen och måste vara öppen på serversidan. Klientens källport väljs lokalt, vanligtvis från det efemära intervallet, och finns för att svaret ska ha någonstans att landa. Den kan ändras vid varje återanslutning, och inget i designen är beroende av att den är stabil.
En router emellan kan skriva om den källan till sin egen 'NAT'-mappning. Därför har numret som observeras på servern ofta ingen koppling till det laptopen valde.
Var källnumret ändras på väg ut
Ta ett påhittat IPv4-exempel: en klient bakom en översättande router, en server med en 'UDP'-lyssnare och ett enda datagram som passerar båda. Tabellen namnger varje ändpunkt och vad som händer med den, i stället för att spela upp paketet på tre observationspunkter.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
Destinationen är konstant i varje rad, och bara källans identitet ändras. Krav för UDP NAT skiljer på en intern adress och port och den externa mappningen, vilket är precis skillnaden mellan andra och tredje raden. En router kan behålla klientens källport eller välja en annan; att behålla den är inget en applikation bör förutsätta.
Läs de tre ändpunkterna från värdarna själva
Listorna nedan kommer från tre olika maskiner och visar tillsammans hela samtalet. Kör den första på servern, den andra på klienten och den tredje där mappningen finns. En enda logglinje visar aldrig alla tre.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194Den första listan bevisar att servern är bunden till tjänsteporten och visar vilken process som äger den. Den andra visar klientens lokala socket och destinationen den ringde. Den tredje visar mappningen som routern skapade, och det är den enda platsen där den översatta källan visas. Läs dem i den ordningen, och de två numren slutar se motstridiga ut.
Vad en återanslutning ändrar, och vad den inte ändrar
Vissa routrar behåller klientens källport när den är ledig, och andra tilldelar en annan varje gång. Båda beteendena är normala, och en applikation som kräver det första går sönder på det andra. En ändring av mappningen efter en återanslutning eller ett nätverksbyte är inte ett serverfel: klienten öppnar en ny socket, routern tilldelar vad den har, och servern ser en ny källa på samma lyssnare. Ett fel vore att förvänta sig att servern tar emot trafik adresserad till en godtycklig klientport.
Communityns OpenVPN-klienter får detta beteende genom nobind, vilket låter operativsystemet välja den lokala porten; fjärrporten kommer fortfarande från profilen. Att binda explicit är ett medvetet val, inte ett protokollkrav. Servern fortsätter erbjuda en ändpunkt medan klienterna väljer sina egna lokala identiteter.
Märk lagren separat i registreringen
Inne i tunneln finns ett andra samtal med egna portar. En HTTPS-begäran som tunneln bär har destination TCP 443, medan den yttre krypterade anslutningen använder UDP 1194, så att ändra den yttre källporten ändrar inget i den inre tjänsten.
Även på det yttre lagret spelar protokollet roll. UDP 1194 och TCP 1194 är olika ändpunkter, och en 'TCP'-lyssnare kommer aldrig ta emot ett UDP-datagram bara för att numret stämmer. När du dokumenterar en driftsättning, märk serverns lyssnare, klientens socket och den översatta källan som tre olika saker, och lägg till transporten på varje.
Låt sedan policyn följa rollerna. Servern öppnar den avsedda transporten på sin lyssnare och autentiserar fortfarande motparten; klientens brandvägg släpper igenom svar på sitt eget utgående utbyte utan att publicera en inkommande tjänst. Ett tillståndslöst filter behöver returriktningen uttryckligen skriven, och det är det praktiska skälet till att åtskillnaden spelar roll bortom prydliga diagram.