Miért osztozik sok alkalmazáskapcsolat egyetlen OpenVPN-munkameneten

Képzeljen el egy böngészőt, amely HTTPS-oldalt tölt be, miközben egy SSH-kliens elér egy másik kiszolgálót, és egy feloldó válaszol egy lekérdezésre, mindezt egyetlen OpenVPN-munkameneten keresztül. A fizikai interfészen egy beszélgetést lát; a tunel belsejében hármat. Mindkét nézet helyes, és tudni, miért, a különbség egy hasznos és egy zavaró felvétel között. Kövessen végig egy belső folyamot a socket-től a vezetékig, és a rétegződés megszűnik absztrakt lenni.

Egy külső beszélgetés, sok belső folyam

Minden alkalmazás megnyitja a saját socketét, és a kernel ad neki egy ötöst: forrás-cím, forrás-port, cél-cím, cél-port és protokoll. Ezek az ötösök már a tunel megjelenése előtt léteznek. Ezután az útválasztás úgy dönt, hogy mindegyikük a tuneleszközön keresztül lép ki, így az OpenVPN-nek átadott csomag továbbra is magában hordozza az eredeti fejléceket. Az OpenVPN titkosítja ezt a belső csomagot, és az eredményt egyetlen külső UDP- vagy TCP-beszélgetésbe csomagolja a partnerrel. A külső beszélgetés tehát egy, míg a benne lévő folyamok annyian vannak, ahány alkalmazás megnyílt.

Semmi nem omlik össze. A belső ötösök végig megmaradnak, és ezért a távoli oldal még mindig meg tudja különböztetni a három folyamot.

A port, amely rögzített marad

Állandó a külső ötös: az Ön címe, az a helyi port, amelyet a kliens kötött, a partner címe és a beállított szolgáltatási port. Ezt az ötöst kell engedélyeznie az útvonalon lévő tűzfalmak vagy NAT-nak, és ezt mutatja majd a felmenő linken készült felvétel. Ez az is, amely egy újracsatlakozás vagy hálózatváltás után megváltozik, mert a kliens más helyi portot köthet. Egy tunel nem jelent egyetlen rögzített forrásportot örökre.

A belső portok azok, amelyek a végpontokat érdeklik. Egy HTTPS-folyam a tunelen belül megtartja a 443-as célportot, pedig a külső átvitel azon a porton ül, amelyet az üzemeltető beállított. Az alkalmazás végpontjai soha nem szereznek tudomást a külsőről.

Mit változtat meg a beburkolás lebontása a távoli végponton

A partnernél a külső réteg lekerül, és a belső csomag marad. Onnantól a továbbítás és a hozzáférési házirend a belső célra és protokollra vonatkozik. A webkiszolgáló továbbra is HTTPS-kapcsolatot kap, az SSH-démon továbbra is SSH-t kap, a feloldó pedig továbbra is lekérdezést kap.

Ezért a külső átvitelt engedélyező szabály nem ugyanaz a szabály, mint egy belső szolgáltatás engedélyezése. Az első egy útvonalat ír le; a második egy felhatalmazást.

A külső TCP egy folyamot jelent, nem egy kapcsolatot

Ha a külső átvitel UDP, minden belső folyam sorsa független: egy elveszett datagram egyetlen átvitelt érint a saját újraküldéséig. Ha a külső átvitel TCP, minden belső folyam egyetlen megbízható bájtfolyamot oszt meg.

Ez a megosztott folyam az a rész, amelyet az emberek kihagynak. A helyreállítás egyszer történik meg, mindenre, így egyetlen elveszett szegmens minden benne multiplexelt alkalmazás forgalmát késlelteti. Továbbra is sok kapcsolat van a végpontokon és egy kapcsolat a vezetéken, és a sorfej-hatás a vezetéken él. A figyelő portok száma erről semmit nem mond, ezért a portok számolgatása rossz módja a tunel teljesítményéről való gondolkodásnak.

Írja le a saját beállítását pontosan

Nevezze meg a kiválasztott belső forgalmat és az azt szállító konkrét külső átvitelt, ahelyett hogy azt mondaná, a gép mindent egy porton küld. A helyi szolgáltatások, egy második tunel és a másik címcsalád mind olyan folyamokat hoznak létre, amelyek soha nem lépnek be ebbe a beszélgetésbe. A felmenő linken készült felvétel a külső ötöst mutatja; a tunelen belüli felvétel a belsőket.

Vegye mindkettőt, és tegye egymás mellé az időbélyegeket. Ha bizonyítania kell, melyik alkalmazás melyik belső folyamot hozta létre, a gazdagép socket-táblázata a jobb eszköz, mert a portokat közvetlenül a folyamatokhoz rendeli. Ezután írja fel a megfigyelt külső ötöst és a megfigyelés pillanatát, mert az újracsatlakozás utáni következő felvétel jogosan mutathat más számokat.