Zašto mnoge veze aplikacija dijele jednu OpenVPN sesiju

Zamislite preglednik koji učitava HTTPS stranicu dok SSH klijent dolazi do drugog poslužitelja, a razrješivač odgovara na upit — sve kroz jednu OpenVPN sesiju. Na fizičkom sučelju vidite jedan razgovor; unutar tunela vidite tri. Oba pogleda su točna, a znati zašto je razlika između korisnog snimka i zbunjujućeg. Slijedite jedan unutarnji tok od utičnice do žice i slojevitost prestaje biti apstraktna.

Jedan vanjski razgovor, mnogo unutarnjih tokova

Svaka aplikacija otvara svoju utičnicu i jezgra joj daje petorku od izvorišne adrese, izvorišnog porta, odredišne adrese, odredišnog porta i protokola. Te petorke postoje prije nego što je ikakav tunel uključen. Usmjeravanje zatim odlučuje da sve one izlaze kroz tunelski uređaj, pa paket predan OpenVPN i dalje nosi izvorna zaglavlja u sebi. OpenVPN šifrira taj unutarnji paket i zamata rezultat u jedan vanjski UDP ili TCP razgovor s partnerom. Vanjski razgovor je dakle jedan, dok je tokova unutar njega onoliko koliko su aplikacije otvorile.

Ništa se ne sažima. Unutarnje petorke preživljavaju od kraja do kraja, i zato daleka strana još može razlikovati tri toka.

Port koji ostaje nepromijenjen

Ono što ostaje stalno je vanjska petorka: vaša adresa, lokalni port koji je klijent zauzeo, adresa partnera i konfigurirani port usluge. Upravo tu petorku mora propustiti vatrozid ili NAT na putu, i upravo nju će pokazati snimka na uzlaznoj vezi. Ona se također mijenja nakon ponovnog spajanja ili promjene mreže, jer klijent može zauzeti drugi lokalni port. Jedan tunel ne znači jedan stalni izvorišni port zauvijek.

Unutarnji portovi su ono do čega je krajnjim točkama stalo. HTTPS tok zadržava odredišni port 443 unutar tunela iako vanjski prijevoz stoji na portu koji je operater konfigurirao. Krajnje točke aplikacija nikada ne saznaju za vanjski.

Što dekapsulacija mijenja na dalekom kraju

Kod partnera se vanjski sloj skida i ostaje unutarnji paket. Odande se prosljeđivanje i pravila pristupa primjenjuju na unutarnje odredište i protokol. Web poslužitelj još prima HTTPS vezu, SSH usluga još prima SSH, a razrješivač još prima upit.

Zato pravilo koje dopušta vanjski prijevoz nije isto pravilo kao dopuštanje unutarnje usluge. Prvo opisuje put; drugo opisuje ovlaštenje.

Vanjski TCP znači jedan tok, a ne jednu vezu

Kad je vanjski prijevoz UDP, sudbina svakog unutarnjeg toka je neovisna: izgubljena datagrama pogađa jedan prijenos do njegova vlastitog ponovnog slanja. Kad je vanjski prijevoz TCP, svi unutarnji tokovi dijele jedan pouzdan tok bajtova.

Taj zajednički tok je dio koji ljudi propuštaju. Oporavak se događa jednom, za sve, pa jedan izgubljeni segment odgađa promet svake aplikacije multipleksirane unutra. I dalje je mnogo veza na krajnjim točkama i jedna veza na žici, a upravo na žici živi učinak blokiranja glave reda. Broj portova koji slušaju o tome ne govori ništa, zato je brojanje portova loš način razmišljanja o učinku tunela.

Opišite vlastitu postavku točno

Nazovite odabrani unutarnji promet i konkretni vanjski prijevoz koji ga nosi, umjesto da kažete da stroj šalje sve kroz jedan port. Lokalne usluge, drugi tunel i druga obitelj adresa stvaraju tokove koji nikada ne ulaze u ovaj razgovor. Snimka na uzlaznoj vezi pokazuje vanjsku petorku; snimka unutar tunela pokazuje unutarnje.

Uzmite oboje i stavite vremenske oznake jednu uz drugu. Ako trebate dokazati koja je aplikacija stvorila koji unutarnji tok, tablica utičnica na hostu bolji je instrument, jer izravno povezuje portove s procesima. Zatim zapišite vanjsku petorku koju ste promatrali i trenutak kada ste je promatrali, jer sljedeća snimka nakon ponovnog spajanja može s pravom pokazati druge brojeve.