Varför många appanslutningar delar en enda OpenVPN-session

Föreställ dig en webbläsare som laddar en HTTPS-sida medan en SSH-klient når en annan server och en resolver svarar på en fråga, allt genom en enda OpenVPN-session. På det fysiska gränssnittet ser du ett samtal; inne i tunneln ser du tre. Båda vyerna är korrekta, och att veta varför är skillnaden mellan en användbar och en förvirrande fångst. Följ ett inre flöde från socket till kabel och lagerskiktningen slutar vara abstrakt.

Ett yttre samtal, många inre flöden

Varje applikation öppnar sin egen socket, och kärnan ger den en fem-tuppel av källadress, källport, måladdres, målport och protokoll. Dessa tuppler finns innan någon tunnel är inblandad. Sedan beslutar routingen att alla går ut genom tunnelenheten, så paketet som lämnas till OpenVPN bär fortfarande de ursprungliga rubrikerna inuti sig. OpenVPN krypterar det inre paketet och lindar in resultatet i ett enda yttre UDP- eller TCP-samtal med peeren. Det yttre samtalet är alltså ett, medan flödena inuti är lika många som applikationerna öppnade.

Ingenting kollapsar. De inre tupplerna överlever från ände till ände, och därför kan den bortre sidan fortfarande skilja de tre flödena.

Porten som förblir låst

Det som är konstant är den yttre tuppeln: din adress, den lokala port som klienten band, peer-adressen och den konfigurerade tjänsteporten. Det är denna tuppel en brandvägg eller NAT på vägen måste tillåta, och det är den en fångst på upplänken visar. Det är också den som ändras efter en återanslutning eller ett nätverksbyte, eftersom klienten kan binda en annan lokal port. En tunnel betyder inte en fast källport för alltid.

Det är de inre portarna som ändpunkterna bryr sig om. Ett HTTPS-flöde behåller målport 443 inne i tunneln även om den yttre transporten sitter på den port operatören har konfigurerat. Applikationens ändpunkter får aldrig veta om den yttre.

Vad dekapsulering ändrar i den bortre änden

Hos peeren tas det yttre lagret bort, och det inre paketet är det som återstår. Därifrån gäller vidarebefordran och åtkomstpolicy för det inre målet och protokollet. Webbservern tar fortfarande emot en HTTPS-anslutning, SSH-demonen tar fortfarande emot SSH, och resolvern tar fortfarande emot en fråga.

Därför är en regel som tillåter den yttre transporten inte samma regel som att tillåta en intern tjänst. Den första beskriver en väg; den andra beskriver ett tillstånd.

Yttre TCP betyder ett flöde, inte en anslutning

När den yttre transporten är UDP är varje inre flödes öde oberoende: ett förlorat datagram påverkar en överföring fram till dess egen omsändning. När den yttre transporten är TCP delar alla inre flöden en enda pålitlig byte-ström.

Den delade strömmen är den del folk missar. Återhämtning sker en gång, för allt, så ett enda förlorat segment fördröjer trafiken från varje applikation som multiplexas inuti. Det är fortfarande många anslutningar vid ändpunkterna och en anslutning på kabeln, och det är på kabeln head-of-line-effekten bor. Antalet lyssnande portar säger dig ingenting om detta, och därför är det ett dåligt sätt att resonera om tunnelns prestanda att räkna portar.

Beskriv din egen uppsättning exakt

Namnge den valda inre trafiken och den specifika yttre transport som bär den, i stället för att säga att maskinen skickar allt genom en port. Lokala tjänster, en andra tunnel och den andra adressfamiljen skapar alla flöden som aldrig kommer in i detta samtal. En fångst på upplänken visar den yttre tuppeln; en fångst inne i tunneln visar de inre.

Ta båda, och ställ tidsstämplarna sida vid sida. Om du måste bevisa vilken applikation som skapade vilket inre flöde, är sockettabellen på värden det bättre instrumentet, eftersom den kopplar portar direkt till processer. Skriv sedan ned den yttre tuppel du observerade och ögonblicket du observerade den, för nästa fångst efter en återanslutning kan med rätta visa andra siffror.