Hvorfor mange app-forbindelser deler én OpenVPN-session

Forestil dig en browser, der indlæser en HTTPS-side, mens en SSH-klient når en anden server og en resolver besvarer en forespørgsel, alt sammen gennem én OpenVPN-session. På det fysiske interface ser du én samtale; inde i tunnelen ser du tre. Begge syn er korrekte, og at vide hvorfor er forskellen på en brugbar optagelse og en forvirrende. Følg én indre strøm fra socket til kabel, så holder lagdelingen op med at være abstrakt.

Én ydre samtale, mange indre strømme

Hver applikation åbner sin egen socket, og kernen giver den en fem-tupel af kildeadresse, kildeport, destinationsadresse, destinationsport og protokol. De tupler findes, før nogen tunnel er involveret. Derefter beslutter routing, at de alle forlader gennem tunnel-enheden, så pakken, der gives videre til OpenVPN, stadig bærer de oprindelige headers indeni. OpenVPN krypterer den indre pakke og pakker resultatet ind i én ydre UDP- eller TCP-samtale med peer’en. Den ydre samtale er altså én, mens strømmene indeni er lige så mange, som applikationerne åbnede.

Intet kollapser. De indre tupler overlever fra ende til anden, og derfor kan den fjerne side stadig skelne de tre strømme.

Porten der bliver fast

Det, der er konstant, er den ydre tupel: din adresse, den lokale port klienten bandt, peer-adressen og den konfigurerede serviceport. Det er den tupel, en firewall eller NAT på vejen skal tillade, og det er den, en optagelse på uplink’en vil vise. Det er også den, der ændrer sig efter en genopkobling eller et netværksskift, fordi klienten kan binde en anden lokal port. Én tunnel betyder ikke én fast kildeport for evigt.

Det er de indre porte, endepunkterne er interesserede i. En HTTPS-strøm beholder destinationsport 443 inde i tunnelen, selvom den ydre transport sidder på den port, operatøren har konfigureret. Applikationens endepunkter hører aldrig om den ydre.

Hvad dekapsulering ændrer i den fjerne ende

Hos peer’en tages det ydre lag af, og den indre pakke er det, der er tilbage. Derfra gælder videresendelse og adgangspolitik for den indre destination og protokol. Webserveren modtager stadig en HTTPS-forbindelse, SSH-dæmonen modtager stadig SSH, og resolveren modtager stadig en forespørgsel.

Derfor er en regel, der tillader den ydre transport, ikke den samme regel som at tillade en intern tjeneste. Den første beskriver en vej; den anden beskriver en autorisation.

Ydre TCP betyder én strøm, ikke én forbindelse

Når den ydre transport er UDP, er hver indre strøms skæbne uafhængig: en tabt datagram påvirker én overførsel indtil dens egen gensendelse. Når den ydre transport er TCP, deler alle indre strømme én pålidelig bytestrøm.

Den delte strøm er den del, folk overser. Genopretning sker én gang, for alt, så et enkelt tabt segment forsinker trafik fra enhver applikation, der er multiplekset indeni. Det er stadig mange forbindelser ved endepunkterne og én forbindelse på kablet, og det er på kablet, at head-of-line-effekten bor. Antallet af lyttende porte fortæller dig intet om dette, og derfor er det en dårlig måde at tælle porte på, når man skal ræsonnere om tunnelens ydeevne.

Beskriv dit eget setup præcist

Navngiv den valgte indre trafik og den konkrete ydre transport, der bærer den, i stedet for at sige, at maskinen sender alt gennem én port. Lokale tjenester, en anden tunnel og den anden adressefamilie skaber alle strømme, der aldrig kommer ind i denne samtale. En optagelse på uplink’en viser den ydre tupel; en optagelse inde i tunnelen viser de indre.

Tag begge, og stil tidsstemplerne ved siden af hinanden. Hvis du skal bevise, hvilken applikation der skabte hvilken indre strøm, er socket-tabellen på værten det bedre instrument, fordi den knytter porte direkte til processer. Skriv derefter den ydre tupel ned, som du observerede, og det øjeblik du observerede den, for den næste optagelse efter en genopkobling kan med rette vise andre tal.