OpenVPN a HTTPS na porte 443: komu patrí poslucháč?
TCP a UDP 443 sú oddelené sockety. Zdieľanie jedného TCP poslucháča vyžaduje vlastníka a zdieľanie portu OpenVPN je úzka dohoda, nie trik s proxy.
Dve služby môžu obe odpovedať na porte 443 bez toho, aby kedy súťažili, pretože poslucháč sa určuje podľa transportu, adresy a portu spolu, nie podľa čísla samotného. Postavte webový server a OpenVPN na jeden stroj a jediná otázka, ktorá si zaslúži prvú odpoveď, je, ktorý socket každý proces žiada od jadra. Zapíšte si ten zoznam pred úpravou konfigurácie a väčšina chýb „adresa sa už používa“ sa vysvetlí sama. Všetko po zozname je voľba medzi UDP poslucháčom, zdieľaným TCP socketom alebo frontendom, ktorý smeruje podľa protokolu.
Začnite socketom, ktorý žiada každý proces
Bind uspeje alebo zlyhá podľa tejto trojice, takže dva daemony sa zrazia len vtedy, keď sa zhodujú všetky tri časti. Preto web na TCP 443 neobmedzene koexistuje s poslucháčom OpenVPN na UDP 443 a preto presun jedného z nich na druhú miestnu adresu na tom istom hostiteľovi tiež ukončí spor. Čítajte živé poslucháče, nie súbory, ktoré ich mali vytvoriť, pretože zastaraný include alebo zabudnutý unit súbor prežije úpravu, ktorú si pamätáte, že ste urobili.
| 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 |
Spustite ss -lntup ako root a prečítajte každý riadok, ktorý spomína 443, vrátane položiek IPv6. Divoký poslucháč v6 zvyčajne prijíma aj prevádzku v4, a tak poslucháč, na ktorý ste zabudli, drží port obsadený po tom, čo zmeníte súbor, ktorý ste považovali za zodpovedný. Ak vás názov procesu prekvapí, zúžte výstup pomocou ss -lntup 'sport = :443', skôr než sa čohokoľvek dotknete.
Prepnite tunel na UDP, keď to sieť dovolí
UDP poslucháč obíde zrážku úplne a je zvyčajne najkratšou opravou, pretože sa nezdieľa žiadny socket a do cesty nevstupuje žiadny ďalší produkt. Nie je to však zadarmo. Niektoré klientske siete zahadzujú UDP 443 bez odoslania resetu, takže tunel sa prestane nadväzovať namiesto toho, aby zlyhal na bind, a používateľ hlási, že VPN je mimo prevádzky, bez chyby na prečítanie. UDP poslucháč tiež prežije reštart webovej vrstvy, čo sa počíta na stroji, ktorého stránka sa často nasadzuje znova. Testujte zo siete, kde sedia používatelia, pretože shell na serveri dokazuje len to, že server dosiahne sám seba.
Zmeňte transport v konfigurácii servera aj v profile klienta súčasne. Profil, ktorý stále žiada TCP, bude krúžiť v slučkách opätovného pripájania voči poslucháčovi iba s UDP, a to vyzerá ako sieťová porucha, kým neporovnáte oba súbory.
Nechajte proces VPN vlastniť TCP 443 a zvyšok preposielajte
Community OpenVPN v režime TCP servera číta prvé bajty prichádzajúceho spojenia a preposiela všetko, čo nie je jeho vlastný protokol, do HTTPS backendu, a na to slúži direktíva port-share. Backend je bežný webový server s povoleným TLS, v tejto direktíve pomenovaný hostiteľom a portom, nie URL.
port-share 10.0.0.5 8080
Na stroji, kde stránka drží druhú privátnu adresu, ten riadok posiela ne-VPN prevádzku na 10.0.0.5:8080, takže HTTPS virtuálny hostiteľ tam musí byť naviazaný a firewall musí povoliť miestny skok. Webový server musí TLS ukončiť sám, pretože prichádzajúce bajty sú pôvodný handshake prehliadača a nič medzi nimi ich nedešifrovalo. Namierte direktívu na obyčajný HTTP poslucháč a prehliadač dostane chybu neplatnej metódy, ktorá sa číta ako rozbitá stránka, nie ako zle umiestnený backend. Direktíva existuje len v režime TCP servera a UDP poslucháč nemá žiadny tok na preskúmanie.
Pretože proces VPN prijíma každé spojenie, webová aplikácia vidí preposlanú požiadavku prichádzať z jednej z vlastných adries hostiteľa namiesto od návštevníka. Všetko, čo potrebuje skutočnú adresu klienta, závisí od podpory protokolu PROXY v backende alebo od frontendu, ktorý ju pridá. Presun backendu na inú miestnu adresu adresu návštevníka nevráti; zmení len to, ktorú z adries hostiteľa stránka zaznamenáva. Zapíšte toto obmedzenie do poznámok k nasadeniu, skôr než analytický report položí otázku.
Reverzný proxy je nesprávny nástroj; smerovač štvrtej vrstvy nie
HTTP reverzný proxy ukončuje TLS, aby mohol čítať požiadavky, čo znamená, že nemôže prepustiť tok OpenVPN nedotknutý. Smerovač štvrtej vrstvy, ktorý preposiela podľa SNI alebo podľa inšpekcie prvého paketu, môže stáť pred oboma, ak neukončí reláciu, na ktorej VPN závisí. Obe zariadenia vyzerajú na diagrame rovnako a pri sockete sa správajú úplne odlišne.
Komerčný Access Server prináša vlastné nastavenia zdieľania portu a tie nezodpovedajú direktíve komunity jeden na jedného. Identifikujte produkt a verziu, skôr než prispôsobíte návod napísaný pre ten druhý. Skopírované nastavenie, ktoré sa ticho ignoruje, je horšie ako žiadne nastavenie, pretože zoznam poslucháčov potom stále vyzerá vierohodne.
Testujte web a tunel ako dve oddelené cesty
Načítajte stránku a pripojte tunel, potom znova prečítajte zoznam poslucháčov, aby ste videli, ktorý proces teraz vlastní 443. Načítaná stránka nič nedokazuje o VPN a pripojený tunel nič nedokazuje o stránke, hoci oba používajú rovnaké číslo. Tri príkazy nižšie kontrolujú zdieľaný socket, webovú cestu a službu VPN v tomto poradí.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Porovnajte adresu klienta v prístupovom logu backendu s adresou v logu VPN v tom istom okamihu. Ak stránka zaznamenáva každého návštevníka ako samotného hostiteľa, preposielanie funguje a spracovanie adresy nie. Ak oba logy mlčia, frontend spojenie nikdy neodovzdal. Tak či onak, zoznam poslucháčov rozhoduje o tom, kto socket prijíma, a to je fakt, ktorý treba potvrdiť, skôr než zmeníte ďalší súbor.
Nechajte tú mapu poslucháčov vedľa konfigurácie, aby ďalší človek, ktorý sa dotkne 443, vedel, ktorý proces prijíma a kam odišiel druhý protokol. Po zmene potvrďte vlastníctvo namiesto toho, aby ste verili tomu, čo mala úprava urobiť.