Proč mnoho připojení aplikací sdílí jedno sezení OpenVPN

Představte si prohlížeč načítající stránku HTTPS, zatímco SSH klient dosahuje jiného serveru a resolver odpovídá na dotaz, to vše přes jedno sezení OpenVPN. Na fyzickém rozhraní vidíte jednu konverzaci; uvnitř tunelu vidíte tři. Oba pohledy jsou správné a vědět proč je rozdíl mezi užitečným zachycením a matoucím. Sledujte jeden vnitřní tok od socketu až k drátu a vrstvení přestane být abstraktní.

Jedna vnější konverzace, mnoho vnitřních toků

Každá aplikace otevře svůj socket a jádro jí dá pětici zdrojové adresy, zdrojového portu, cílové adresy, cílového portu a protokolu. Tyto pětice existují dřív, než do hry vstoupí jakýkoli tunel. Směrování pak rozhodne, že všechny vycházejí přes tunelové zařízení, takže paket předaný OpenVPN stále nese původní hlavičky uvnitř. OpenVPN ten vnitřní paket zašifruje a výsledek zabalí do jedné vnější konverzace UDP nebo TCP s protějškem. Vnější konverzace je tedy jedna, zatímco toků uvnitř je tolik, kolik aplikací se otevřelo.

Nic se neslévá. Vnitřní pětice přežívají od konce ke konci, a proto vzdálená strana stále rozezná tři toky.

Port, který zůstává pevný

Stálá zůstává vnější pětice: vaše adresa, místní port, který klient obsadil, adresa protějšku a nakonfigurovaný port služby. Právě tuto pětici musí povolit firewall nebo NAT na cestě a právě ji ukáže zachycení na odchozím spoji. Je to také ta, která se změní po opětovném připojení nebo přepnutí sítě, protože klient může obsadit jiný místní port. Jeden tunel neznamená jeden pevný zdrojový port navždy.

Vnitřní porty jsou to, na čem záleží koncovým bodům. Tok HTTPS si uvnitř tunelu drží cílový port 443, i když vnější transport sedí na portu, který nakonfiguroval operátor. Koncové body aplikací se o tom vnějším nikdy nedozvědí.

Co dekapsulace změní na vzdáleném konci

U protějšku se vnější vrstva sundá a zůstane vnitřní paket. Odtud se předávání a přístupová politika vztahují na vnitřní cíl a protokol. Webový server stále dostává připojení HTTPS, SSH démon stále dostává SSH a resolver stále dostává dotaz.

Proto pravidlo povolující vnější transport není totéž pravidlo jako povolení vnitřní služby. První popisuje cestu; druhé popisuje oprávnění.

Vnější TCP znamená jeden tok, ne jedno spojení

Když je vnější transport UDP, osud každého vnitřního toku je nezávislý: ztracený datagram ovlivní jeden přenos až do jeho vlastního opakovaného odeslání. Když je vnější transport TCP, všechny vnitřní toky sdílejí jeden spolehlivý bajtový tok.

Ten sdílený tok je část, kterou lidé přehlížejí. Obnova proběhne jednou, za všechno, takže jeden ztracený segment zpozdí provoz každé aplikace, která je uvnitř multiplexovaná. Na koncových bodech je to stále mnoho spojení a na drátu jedno spojení, a právě na drátu žije efekt blokování čela fronty. Počet naslouchajících portů o tom neříká nic, a proto je počítání portů špatný způsob uvažování o výkonu tunelu.

Popište své vlastní nastavení přesně

Pojmenujte vybraný vnitřní provoz a konkrétní vnější transport, který ho nese, místo abyste říkali, že stroj posílá všechno jedním portem. Místní služby, druhý tunel a druhá rodina adres vytvářejí toky, které do této konverzace nikdy nevstoupí. Zachycení na odchozím spoji ukáže vnější pětici; zachycení uvnitř tunelu ukáže ty vnitřní.

Vezměte obojí a položte časová razítka vedle sebe. Pokud potřebujete dokázat, která aplikace vytvořila který vnitřní tok, tabulka socketů na hostiteli je lepší nástroj, protože přímo přiřazuje porty k procesům. Pak zapište vnější pětici, kterou jste pozorovali, a okamžik, kdy jste ji pozorovali, protože další zachycení po opětovném připojení může legitimně ukázat jiná čísla.