Kvifor mange app-samband deler éin OpenVPN-økt

Tenk deg ein nettlesar som lastar ei HTTPS-side medan ein SSH-klient når ein annan tenar og ein resolvar svarar på ei førespurnad, alt gjennom éi OpenVPN-økt. På det fysiske grensesnittet ser du éi samtale; inne i tunellen ser du tre. Begge syna er rette, og å vita kvifor er skilnaden mellom ein nyttig og ein forvirrande fangst. Følg éin indre straum frå socket til kabel, så sluttar lagdelinga å vera abstrakt.

Éi ytre samtale, mange indre straumar

Kvar applikasjon opnar sin eigen socket, og kjernen gjev han ein fem-tuppel av kjeldeadresse, kjeldeport, måladdresse, målport og protokoll. Desse tuppelane finst før nokon tunell er med. Deretter avgjer rutinga at alle går ut gjennom tunell-eininga, så pakken som vert gjeven vidare til OpenVPN ber framleis dei opphavlege overskriftene inni seg. OpenVPN krypterer den indre pakken og pakkar resultatet inn i éi ytre UDP- eller TCP-samtale med peer-en. Den ytre samtala er altså éi, medan straumane inni er like mange som applikasjonane opna.

Ingenting kollapsar. Dei indre tuppelane overlever frå ende til annan, og derfor kan den fjerne sida framleis skilja dei tre straumane.

Porten som held seg fast

Det som er konstant, er den ytre tuppelen: adressa di, den lokale porten klienten batt, peer-adressa og den konfigurerte tenesteporten. Det er denne tuppelen ein brannmur eller NAT på vegen må tillate, og det er den ein fangst på opplenkja vil visa. Det er òg den som endrar seg etter ei attilkopling eller eit nettverksbyte, fordi klienten kan binda ein annan lokal port. Éin tunell tyder ikkje éin fast kjeldeport for alltid.

Det er dei indre portane endepunkta bryr seg om. Ein HTTPS-straum held målport 443 inne i tunellen sjølv om den ytre transporten sit på porten operatøren har konfigurert. Endepunkta til applikasjonen får aldri vita om den ytre.

Kva dekapsulering endrar i den fjerne enden

Hjå peer-en vert det ytre laget teke av, og den indre pakken er det som er att. Derifrå gjeld vidaresending og tilgangspolicy for den indre destinasjonen og protokollen. Webserveren mottek framleis ein HTTPS-tilkopling, SSH-demonen mottek framleis SSH, og resolvaren mottek framleis ei førespurnad.

Derfor er ei regel som tillèt den ytre transporten ikkje den same regelen som å tillate ei intern teneste. Den fyrste skildrar ein veg; den andre skildrar ein autorisasjon.

Ytre TCP tyder éin straum, ikkje éi tilkopling

Når den ytre transporten er UDP, er lagnaden til kvar indre straum uavhengig: eit tapt datagram påverkar éin overføring til si eiga omsending. Når den ytre transporten er TCP, deler alle indre straumar éin påliteleg bytestraum.

Den delte straumen er den delen folk overser. Attoppretting skjer éin gong, for alt, så eitt tapt segment forseinkar trafikken frå kvar applikasjon som er multipleksa inni. Det er framleis mange samband ved endepunkta og eitt samband på kabelen, og det er på kabelen head-of-line-effekten bur. Talet på lyttande portar fortel deg ingenting om dette, og derfor er det å telja portar ein dårleg måte å resonnera om ytinga til tunellen.

Skildr eige oppsett nøyaktig

Nemne den valde indre trafikken og den konkrete ytre transporten som ber han, i staden for å seia at maskina sender alt gjennom éin port. Lokale tenester, ein andre tunell og den andre adressefamilien skaper alle straumar som aldri kjem inn i denne samtala. Ein fangst på opplenkja viser den ytre tuppelen; ein fangst inne i tunellen viser dei indre.

Ta båe, og set tidsstempla side om side. Viss du må prova kva applikasjon som skapte kva indre straum, er socket-tabellen på verten det betre instrumentet, fordi han knyter portar direkte til prosessar. Skriv så ned den ytre tuppelen du observerte og augneblinken du observerte han, for den neste fangsten etter ei attilkopling kan med rette visa andre tal.