Prečo mnohé pripojenia aplikácií zdieľajú jednu reláciu OpenVPN

Predstavte si prehliadač načítavajúci stránku HTTPS, kým SSH klient dosahuje iný server a resolver odpovedá na dotaz, to všetko cez jednu reláciu OpenVPN. Na fyzickom rozhraní vidíte jednu konverzáciu; vo vnútri tunela vidíte tri. Oba pohľady sú správne a vedieť prečo je rozdiel medzi užitočným a mätúcim zachytením. Sledujte jeden vnútorný tok od socketu až k drôtu a vrstvenie prestane byť abstraktné.

Jedna vonkajšia konverzácia, mnoho vnútorných tokov

Každá aplikácia otvorí svoj socket a jadro jej dá päticu: zdrojovú adresu, zdrojový port, cieľovú adresu, cieľový port a protokol. Tieto pätice existujú skôr, než do hry vstúpi akýkoľvek tunel. Potom smerovanie rozhodne, že všetky vychádzajú cez tunelové zariadenie, takže paket odovzdaný OpenVPN stále nesie pôvodné hlavičky v sebe. OpenVPN ten vnútorný paket zašifruje a výsledok zabalí do jednej vonkajšej konverzácie UDP alebo TCP s partnerom. Vonkajšia konverzácia je teda jedna, zatiaľ čo tokov v nej je toľko, koľko aplikácií sa otvorilo.

Nič sa nezrúti. Vnútorné pätice prežívajú od konca po koniec, a preto vzdialená strana stále rozlišuje tri toky.

Port, ktorý zostáva pevný

Stála zostáva vonkajšia pätica: vaša adresa, miestny port, ktorý klient obsadil, adresa partnera a nakonfigurovaný port služby. Práve túto päticu musí povoliť firewall alebo NAT na ceste a práve ju ukáže zachytenie na odchádzajúcom spoji. Je to aj tá, ktorá sa zmení po opätovnom pripojení alebo prepnutí siete, pretože klient môže obsadiť iný miestny port. Jeden tunel neznamená jeden pevný zdrojový port navždy.

Vnútorné porty sú to, na čom záleží koncovým bodom. Tok HTTPS si vo vnútri tunela drží cieľový port 443, aj keď vonkajší transport sedí na porte, ktorý nakonfiguroval operátor. Koncové body aplikácie sa o tom vonkajšom nikdy nedozvedia.

Čo dekapsulácia zmení na vzdialenom konci

U partnera sa vonkajšia vrstva odoberie a zostane vnútorný paket. Odtiaľ sa preposielanie a prístupová politika vzťahujú na vnútorný cieľ a protokol. Webový server stále dostáva pripojenie HTTPS, SSH démon stále dostáva SSH a resolver stále dostáva dotaz.

Preto pravidlo povoľujúce vonkajší transport nie je to isté pravidlo ako povolenie vnútornej služby. Prvé opisuje cestu; druhé opisuje oprávnenie.

Vonkajší TCP znamená jeden tok, nie jedno pripojenie

Keď je vonkajší transport UDP, osud každého vnútorného toku je nezávislý: stratený datagram ovplyvní jeden prenos až do jeho vlastného opätovného odoslania. Keď je vonkajší transport TCP, všetky vnútorné toky zdieľajú jeden spoľahlivý bajtový tok.

Ten zdieľaný tok je časť, ktorú ľudia prehliadajú. Obnova nastane raz, pre všetko, takže jeden stratený segment zdrží prevádzku každej aplikácie, ktorá je vnútri multiplexovaná. Na koncových bodoch je stále veľa pripojení a na drôte jedno pripojenie, a práve na drôte žije efekt blokovania čela frontu. Počet počúvajúcich portov o tom nič nehovorí, a preto je počítanie portov zlý spôsob uvažovania o výkone tunela.

Opíšte svoje vlastné nastavenie presne

Pomenujte vybranú vnútornú prevádzku a konkrétny vonkajší transport, ktorý ju nesie, namiesto toho, aby ste hovorili, že stroj posiela všetko jedným portom. Miestne služby, druhý tunel a druhá rodina adries vytvárajú toky, ktoré do tejto konverzácie nikdy nevstúpia. Zachytenie na odchádzajúcom spoji ukáže vonkajšiu päticu; zachytenie vo vnútri tunela ukáže tie vnútorné.

Vezmite oboje a položte časové pečiatky vedľa seba. Ak potrebujete dokázať, ktorá aplikácia vytvorila ktorý vnútorný tok, tabuľka socketov na hostiteľovi je lepší nástroj, pretože priraďuje porty priamo procesom. Potom zapíšte pozorovanú vonkajšiu päticu a okamih, kedy ste ju pozorovali, pretože ďalšie zachytenie po opätovnom pripojení môže celkom legitímne ukázať iné čísla.