Miksi monet sovellusyhteydet jakavat yhden OpenVPN-istunnon

Kuvittele selain lataamassa HTTPS-sivua, kun SSH-asiakas tavoittaa toisen palvelimen ja ratkaisija vastaa kyselyyn, kaikki yhden OpenVPN-istunnon kautta. Fyysisellä rajapinnalla näet yhden keskustelun; tunnelin sisällä näet kolme. Molemmat näkymät ovat oikeita, ja syyn tietäminen on ero hyödyllisen ja hämmentävän kaappauksen välillä. Seuraa yhtä sisempää virtaa soketista johtoon, niin kerrostuminen lakkaa olemasta abstraktia.

Yksi ulompi keskustelu, monta sisempää virtaa

Jokainen sovellus avaa oman sokettinsa, ja ydin antaa sille viisikon: lähdeosoite, lähdeportti, kohdeosoite, kohdeportti ja protokolla. Nuo viisikot ovat olemassa ennen kuin mikään tunneli tulee mukaan. Sitten reititys päättää, että ne kaikki lähtevät tunnelilaitteen kautta, joten OpenVPN:lle luovutettu paketti kantaa edelleen alkuperäiset otsikot sisällään. OpenVPN salaa tuon sisemmän paketin ja käärii tuloksen yhteen ulompaan UDP- tai TCP-keskusteluun vertaisen kanssa. Ulompi keskustelu on siis yksi, kun taas sen sisällä olevia virtoja on yhtä monta kuin sovellukset avasivat.

Mikään ei romahda. Sisemmät viisikot säilyvät päästä päähän, ja siksi kaukainen pää pystyy yhä erottamaan kolme virtaa.

Portti, joka pysyy kiinteänä

Vakiona pysyy ulompi viisikko: osoitteesi, paikallinen portti jonka asiakas varasi, vertaisen osoite ja määritetty palveluportti. Juuri tuo viisikko on se, jonka palomuurin tai NATin matkalla on sallittava, ja juuri sen ylälinkin kaappaus näyttää. Se on myös se, joka muuttuu uudelleenyhdistämisen tai verkon vaihdon jälkeen, koska asiakas voi varata toisen paikallisen portin. Yksi tunneli ei tarkoita yhtä kiinteää lähdeporttia ikuisesti.

Sisemmät portit ovat se, mistä päätepisteet välittävät. HTTPS-virta pitää kohdeportin 443 tunnelin sisällä, vaikka ulompi kuljetus istuu portissa, jonka operaattori on määrittänyt. Sovelluksen päätepisteet eivät koskaan saa tietää ulommasta.

Mitä purkaminen muuttaa kaukaisessa päässä

Vertaisella ulompi kerros lähtee pois, ja sisempi paketti on se, mikä jää. Siitä eteenpäin välitys ja käyttöoikeuskäytäntö kohdistuvat sisempään kohteeseen ja protokollaan. Verkkopalvelin saa yhä HTTPS-yhteyden, SSH-taustaohjelma saa yhä SSH:n, ja ratkaisija saa yhä kyselyn.

Siksi sääntö, joka sallii ulomman kuljetuksen, ei ole sama sääntö kuin sisäisen palvelun salliminen. Ensimmäinen kuvaa polun; toinen kuvaa valtuutuksen.

Ulompi TCP tarkoittaa yhtä virtaa, ei yhtä yhteyttä

Kun ulompi kuljetus on UDP, jokaisen sisemmän virran kohtalo on riippumaton: kadonnut datagrammi vaikuttaa yhteen siirtoon sen omaan uudelleenlähetykseen asti. Kun ulompi kuljetus on TCP, kaikki sisemmät virrat jakavat yhden luotettavan tavuvirran.

Tuo jaettu virta on se osa, joka ihmisiltä jää huomaamatta. Palautuminen tapahtuu kerran, kaikelle, joten yksi kadonnut segmentti viivästyttää jokaisen sisällä multipleksoidun sovelluksen liikennettä. Se on yhä monta yhteyttä päätepisteissä ja yksi yhteys johdossa, ja juuri johdossa jonon pään vaikutus elää. Kuuntelevien porttien määrä ei kerro tästä mitään, ja siksi porttien laskeminen on huono tapa pohtia tunnelin suorituskykyä.

Kuvaile oma asetuksesi täsmällisesti

Nimeä valittu sisempi liikenne ja sitä kuljettava tietty ulompi kuljetus, sen sijaan että sanoisit koneen lähettävän kaiken yhden portin kautta. Paikalliset palvelut, toinen tunneli ja toinen osoiteperhe luovat kaikki virtoja, jotka eivät koskaan tule tähän keskusteluun. Ylälinkin kaappaus näyttää ulomman viisikon; tunnelin sisäinen kaappaus näyttää sisemmät.

Ota molemmat ja laita aikaleimat vierekkäin. Jos sinun on todistettava, mikä sovellus loi minkä sisemmän virran, isännän sokettitaulu on parempi väline, koska se yhdistää portit suoraan prosesseihin. Kirjoita sitten muistiin havaitsemasi ulompi viisikko ja hetki, jolloin havaitsit sen, koska seuraava kaappaus uudelleenyhdistämisen jälkeen voi näyttää aivan oikeutetusti eri lukuja.