OpenVPN a HTTPS na portu 443: komu patří posluchač?
TCP a UDP 443 jsou oddělené sockety. Sdílení jednoho TCP posluchače vyžaduje vlastníka a sdílení portu u OpenVPN je úzká dohoda, ne trik s proxy.
Dvě služby mohou obě odpovídat na portu 443, aniž by kdy soutěžily, protože posluchač se určuje podle transportu, adresy a portu dohromady, ne jen podle čísla. Postavte webový server a OpenVPN na jeden stroj a jediná otázka, kterou stojí za to zodpovědět nejdřív, je, který socket každý proces žádá od jádra. Zapište si ten seznam, než upravíte konfiguraci, a většina chyb „adresa se už používá“ se vysvětlí sama. Vše po seznamu je volba mezi UDP posluchačem, sdíleným TCP socketem nebo frontendem, který směruje podle protokolu.
Začněte socketem, který žádá každý proces
Bind uspěje nebo selže podle této trojice, takže dva daemoni se střetnou jen tehdy, když se všechny tři části shodují. Proto web na TCP 443 neomezeně koexistuje s posluchačem OpenVPN na UDP 443 a proto přesun jednoho z nich na druhou místní adresu na stejném hostiteli také ukončí spor. Čtěte živé posluchače, ne soubory, které je měly vytvořit, protože zastaralý include nebo zapomenutý unit soubor přežije úpravu, kterou si pamatujete, že jste provedli.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
Spusťte ss -lntup jako root a přečtěte každý řádek, který zmiňuje 443, včetně položek IPv6. Divoký posluchač v6 obvykle přijímá i provoz v4, a tak posluchač, na který jste zapomněli, drží port obsazený poté, co změníte soubor, který jste považovali za odpovědný. Pokud vás název procesu překvapí, zúžte výstup pomocí ss -lntup 'sport = :443', než se čehokoli dotknete.
Přepněte tunel na UDP, když to síť dovolí
UDP posluchač střetu úplně obejde a obvykle je nejkratší opravou, protože se nesdílí žádný socket a do cesty se nepřidává žádný další produkt. Není to však zdarma. Některé klientské sítě zahazují UDP 443, aniž by poslaly reset, takže tunel se přestane navazovat místo toho, aby selhal bind, a uživatel hlásí, že VPN je mimo provoz, bez chyby k přečtení. UDP posluchač také přežije restart webové vrstvy, což se počítá na stroji, jehož stránka se často nasazuje znovu. Testujte ze sítě, kde sedí uživatelé, protože shell na serveru dokazuje jen to, že server dosáhne sám na sebe.
Změňte transport v konfiguraci serveru i v profilu klienta současně. Profil, který stále žádá TCP, bude opakovaně navazovat spojení proti posluchači pouze na UDP, a to vypadá jako síťová závada, dokud oba soubory neporovnáte.
Nechte proces VPN vlastnit TCP 443 a zbytek přepošlete
Community OpenVPN v režimu TCP serveru čte první bajty příchozího spojení a přeposílá vše, co není jeho protokol, do HTTPS backendu, k čemuž slouží direktiva port-share. Backend je běžný webový server s povoleným TLS, v této direktivě pojmenovaný hostitelem a portem, nikoli URL.
port-share 10.0.0.5 8080
Na stroji, kde stránka drží druhou privátní adresu, ten řádek posílá ne-VPN provoz na 10.0.0.5:8080, takže HTTPS virtuální hostitel tam musí být navázán a firewall musí povolit místní skok. Webový server musí TLS ukončit sám, protože přicházející bajty jsou původní handshake prohlížeče a nic mezi tím je nedešifrovalo. Namiřte direktivu na obyčejný HTTP posluchač a prohlížeč dostane chybu neplatné metody, která se čte jako rozbitá stránka, ne jako špatně umístěný backend. Direktiva existuje jen v režimu TCP serveru a UDP posluchač nemá žádný tok k prohlédnutí.
Protože proces VPN přijímá každé spojení, webová aplikace vidí přeposlaný požadavek přicházet z jedné z vlastních adres hostitele místo od návštěvníka. Vše, co potřebuje skutečnou adresu klienta, závisí na podpoře protokolu PROXY v backendu nebo na frontendu, který ji přidá. Přesun backendu na jinou místní adresu adresu návštěvníka nevrátí; jen změní, kterou z adres hostitele stránka zaznamenává. Zapište toto omezení do poznámek k nasazení, než analytický report položí otázku.
Reverzní proxy je špatný nástroj; směrovač čtvrté vrstvy ne
HTTP reverzní proxy ukončuje TLS, aby mohl číst požadavky, což znamená, že nemůže propustit proud OpenVPN nedotčený. Směrovač čtvrté vrstvy, který přeposílá podle SNI nebo podle inspekce prvního paketu, může stát před oběma, pokud neukončí relaci, na které VPN závisí. Obě zařízení vypadají na diagramu stejně a na socketu se chovají zcela odlišně.
Komerční Access Server přichází s vlastním nastavením sdílení portu a to se neshoduje jedna ku jedné s direktivou komunity. Než přizpůsobíte návod napsaný pro ten druhý, určete produkt a verzi. Zkopírované nastavení, které se tiše ignoruje, je horší než žádné nastavení, protože seznam posluchačů pak stále vypadá věrohodně.
Testujte web a tunel jako dvě oddělené cesty
Načtěte stránku a připojte tunel, pak znovu přečtěte seznam posluchačů a zjistěte, který proces teď vlastní 443. Načtená stránka nic nedokazuje o VPN a připojený tunel nic nedokazuje o stránce, i když oba používají stejné číslo. Tři příkazy níže kontrolují sdílený socket, webovou cestu a službu VPN v tomto pořadí.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Porovnejte adresu klienta v přístupovém logu backendu s adresou v logu VPN ve stejném okamžiku. Pokud stránka zaznamenává každého návštěvníka jako samotného hostitele, přeposílání funguje a zpracování adresy ne. Pokud oba logy mlčí, frontend spojení nikdy nepředal. Ať tak či onak, seznam posluchačů rozhoduje o tom, kdo socket přijímá, a to je fakt, který je třeba potvrdit, než změníte další soubor.
Nechte tuto mapu posluchačů vedle konfigurace, aby další člověk, který se dotkne 443, věděl, který proces přijímá a kam šel druhý protokol. Po změně potvrďte vlastnictví, místo abyste věřili tomu, co měla úprava udělat.