Hvorfor mange app-forbindelser deler én OpenVPN-økt

Tenk deg en nettleser som laster en HTTPS-side mens en SSH-klient når en annen server og en resolver svarer på en forespørsel, alt gjennom én OpenVPN-økt. På det fysiske grensesnittet ser du én samtale; inne i tunnelen ser du tre. Begge syn er riktige, og å vite hvorfor er forskjellen mellom en nyttig og en forvirrende fangst. Følg én indre strøm fra socket til kabel, så slutter lagdelingen å være abstrakt.

Én ytre samtale, mange indre strømmer

Hver applikasjon åpner sin egen socket, og kjernen gir den en fem-tuppel av kildeadresse, kildeport, måladdresse, målport og protokoll. Disse tuppelene finnes før noen tunnel er involvert. Deretter bestemmer rutingen at alle går ut gjennom tunnel-enheten, så pakken som gis videre til OpenVPN bærer fortsatt de opprinnelige overskriftene inni seg. OpenVPN krypterer den indre pakken og pakker resultatet inn i én ytre UDP- eller TCP-samtale med peer-en. Den ytre samtalen er altså én, mens strømmene inni er like mange som applikasjonene åpnet.

Ingenting kollapser. De indre tuppelene overlever fra ende til annen, og derfor kan den fjerne siden fortsatt skille de tre strømmene.

Porten som holder seg fast

Det som er konstant, er den ytre tuppelen: adressen din, den lokale porten klienten bandt, peer-adressen og den konfigurerte tjenesteporten. Det er denne tuppelen en brannmur eller NAT på veien må tillate, og det er den en fangst på opplinken vil vise. Det er også den som endres etter en gjentilkobling eller et nettverksbytte, fordi klienten kan binde en annen lokal port. Én tunnel betyr ikke én fast kildeport for alltid.

Det er de indre portene endepunktene bryr seg om. En HTTPS-strøm beholder målport 443 inne i tunnelen selv om den ytre transporten sitter på porten operatøren har konfigurert. Applikasjonens endepunkter får aldri vite om den ytre.

Hva dekapsulering endrer i den fjerne enden

Hos peer-en tas det ytre laget av, og den indre pakken er det som er igjen. Derfra gjelder videresending og tilgangspolicy for den indre destinasjonen og protokollen. Webserveren mottar fortsatt en HTTPS-forbindelse, SSH-demonen mottar fortsatt SSH, og resolveren mottar fortsatt en forespørsel.

Derfor er en regel som tillater den ytre transporten ikke den samme regelen som å tillate en intern tjeneste. Den første beskriver en vei; den andre beskriver en autorisasjon.

Ytre TCP betyr én strøm, ikke én forbindelse

Når den ytre transporten er UDP, er skjebnen til hver indre strøm uavhengig: et tapt datagram påvirker én overføring til dens egen omsending. Når den ytre transporten er TCP, deler alle indre strømmer én pålitelig bytestrøm.

Den delte strømmen er den delen folk overser. Gjenoppretting skjer én gang, for alt, så ett tapt segment forsinker trafikken fra hver applikasjon som er multiplekset inni. Det er fortsatt mange forbindelser ved endepunktene og én forbindelse på kabelen, og det er på kabelen head-of-line-effekten bor. Antallet lyttende porter forteller deg ingenting om dette, og derfor er det å telle porter en dårlig måte å resonnere om tunnelens ytelse.

Beskriv ditt eget oppsett nøyaktig

Navngi den valgte indre trafikken og den konkrete ytre transporten som bærer den, i stedet for å si at maskinen sender alt gjennom én port. Lokale tjenester, en andre tunnel og den andre adressefamilien skaper alle strømmer som aldri kommer inn i denne samtalen. En fangst på opplinken viser den ytre tuppelen; en fangst inne i tunnelen viser de indre.

Ta begge, og sett tidsstemplene side om side. Hvis du må bevise hvilken applikasjon som skapte hvilken indre strøm, er socket-tabellen på verten det bedre instrumentet, fordi den kobler porter direkte til prosesser. Skriv så ned den ytre tuppelen du observerte og øyeblikket du observerte den, for den neste fangsten etter en gjentilkobling kan med rette vise andre tall.