Dve DNS mená, jeden port OpenVPN: čo skutočne vyberá
Dve mená hostiteľa smerujúce na jednu adresu stále dorazia k jednému poslucháčovi. Backend môže vybrať iba pole, ktoré klient pošle, a natívny OpenVPN neposiela žiadne.
Dva záznamy A, jedna adresa, jeden démon: nech používateľ napíše ktorékoľvek meno, doručený paket je rovnaký a proces viazaný na port 1194 nemá čím oba rozlíšiť. To nie je nesprávna konfigurácia čakajúca na opravu; je to hranica toho, čo dokáže vyjadriť vyhľadávanie podľa mena. Čokoľvek, čo vyberá medzi dvoma inštanciami OpenVPN, musí byť hodnota, ktorú klient vloží do spojenia a ktorú frontend dokáže prečítať späť, a bežný klient OpenVPN takú hodnotu neposiela otvorene. Nasleduje, kam vás to dostane a ktoré usporiadania premávku skutočne rozdeľujú.
Začnite tým, čo vracia resolver
Klient sa spýta na vpn-a.example a dostane adresu; táto adresa plus port je všetko, k čomu sa pripája. Meno sa spotrebuje lokálne, počas vyhľadávania, a nikdy sa nestane poľom na drôte, takže poslucháč na druhej strane nemôže vidieť, ktorá značka bola použitá. Nasmerujte vpn-a.example a vpn-b.example na jeden hostiteľ a obe vyhľadávania dajú rovnaký cieľ, a preto démon obe spojenia pohltí do jednej inštancie bez zaznamenania rozdielu. Profily založené na adrese sa správajú presne ako tie založené na mene, z rovnakého dôvodu.
Tým sa tiež uzatvára rodina lákavých obchádzok: ďalšie aliasy, výber certifikátu pre každé meno na jednom sockete alebo pravidlo firewallu viazané na dopytované meno. Žiadne z nich nemôže konať na informáciu, ktorá bola už zahodená predtým, než prvý paket opustil klienta. Ak dva servery musia zostať oddelené, rozdelenie musí cestovať so samotným spojením, teda adresa, port alebo pole užitočného zaťaženia, ktoré definuje protokol.
Jediný selektor, ktorý sa počíta, ide vnútri paketu
HTTP to rieši hlavičkou Host a TLS rozšírením o meno servera v ClientHello, a tak jedna adresa obsluhuje mnoho lokalít za jedným poslucháčom. Obe fungujú preto, že protokol na drôte nesie požiadavku na konkrétnu službu. Podstatný fakt o OpenVPN je, že ani jedno z týchto polí nie je prítomné vo vrstve, ktorú skúma sprostredkujúca skrinka.
V bežnom usporiadaní sa TLS podanie rúk chrániace riadiaci kanál odohrá po nadviazaní vonkajšej relácie a prenáša sa v jej vnútri, takže poslucháč, ktorý tú reláciu neukončil, vidí nepriehľadný tok. Stále dokáže povedať, že ide o OpenVPN, pretože opkód a rámcovanie v úvodných bajtoch sú rozpoznateľné, ale meno servera, ak existuje, sedí v zašifrovanej časti. Dizajn, ktorý očakáva prečítanie virtuálneho hostiteľa z vonkajšieho paketu, číta pole, ktoré tam protokol nikdy nezapisuje. Vyplýva to z toho, ako je tunel postavený, nie z medzery, ktorú by mohlo uzavrieť dômyselnejšie porovnávanie vzorov.
Kde sa rozdeľovač protokolov zastaví
Multiplexor toho druhu, ktorý dokumentuje projekt sslh, načúva na jednom porte, skúma úvodné bajty a odovzdá spojenie tomu backendu, ktorý hovorí rozpoznaným protokolom. To má skutočnú hodnotu, keď jeden port musí obsluhovať SSH, HTTPS a OpenVPN spolu.
sslh drží samostatnú sondu pre každý protokol a jeho TLS sonda dokáže vytiahnuť meno servera alebo hodnotu ALPN zo skutočného ClientHello. Rozpoznanie natívneho OpenVPN je iná klasifikácia než čítanie rozšírenia TLS a obe sa neskladajú, pretože klient, ktorý nikdy nepošle ClientHello na načúvací socket, nechá sondu bez čohokoľvek na čítanie. Preto pravidlo zodpovedajúce OpenVPN odpovie „toto je klient OpenVPN“ a nejde ďalej. Dva backendy OpenVPN za týmto pravidlom sú nerozlíšiteľné, frontend nemá žiadny základ na voľbu a každá relácia pristane na tom istom mieste. Multiplexovanie zdieľa jeden port medzi rôznymi službami; nerobí virtuálny hosting vnútri jednej služby.
Usporiadania, ktoré dva servery skutočne oddeľujú
Najlacnejšie čestné rozdelenie je druhá verejná adresa, jedna na inštanciu, a existujúce profily už nesú, čo treba, pretože smerujú na rôzne adresy. Ďalšie je iný port na tej istej adrese, čo nestojí nič okrem čísla v každom profile. TCP a UDP držia oddelené tabuľky portov, takže 1194/tcp a 1194/udp sú nesúvisiace sockety a jeden z každého môže existovať na jednom hostiteľovi; to je oddelenie transportu, nie smerovanie podľa mena, a často sa s ním zamieňa. Obe možnosti prejdú revíziou firewallu, pretože pravidlo zodpovedá niečomu, čo paket skutočne obsahuje.
Ak hranica, ktorú potrebujete, vedie medzi skupinami používateľov a nie medzi dvoma implementáciami, môže ju pokryť jedna inštancia s odlišnými konfiguráciami klientov, vlastným spracovaním certifikátov a výslovnou politikou prístupu. To kupuje politiku vnútri servera, nie izoláciu medzi servermi, a to sú rozdielne požiadavky. Izolácia, ktorá musí vydržať aj pri kompromitácii, stále potrebuje adresu alebo okraj firewallu.
TLS terminátor postavený pred OpenVPN môže schopnému frontendu vystaviť skutočné meno servera, ale len vtedy, keď je klientská strana tiež nakonfigurovaná pre túto ďalšiu vrstvu. Existujúce profily toto správanie nezískajú tým, že sa nasmerujú na rovnakú adresu.
Dokážte selektor predtým, než budete stavať
Pomenujte pole, ktoré bude identifikovať backend, a potom potvrďte, že ho klient skutočne posiela; ak je odpoveďou adresa, plán drží, a ak ide o meno servera vnútri podania rúk, ktoré sa nikdy nedostane k poslucháčovi, žiadna práca s DNS to nezachráni. Tri príkazy rýchlo vyriešia stranu načúvania.
ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager
Riadok openssl dá certifikát len tam, kde niečo na tej adrese ukončuje TLS; voči natívnemu poslucháčovi OpenVPN sa zasekne alebo zlyhá, a to je samo osebe odpoveď na to, čo vonkajšia vrstva odhaľuje. Riadok journal, prečítaný na každom backende, ukáže, ktorá inštancia reláciu prijala. Frontendové logy zaznamenávajú, čo bolo klasifikované, a nikdy to, čo bolo zamýšľané, takže backend zostáva jedinou autoritou v tom, kam používateľ pristál.
Skončite dvoma profilmi určenými na dosiahnutie rôznych serverov, pripojte ich jeden po druhom a poznačte si log backendu pre každý. Ak sa obe relácie objavia v tom istom žurnále, selektor chýba, a nie je nesprávne nastavený, a opravou je adresa alebo port, na ktorý môže klient cieliť. Úprava pravidla smerovania nepomôže, pretože pravidlu nikdy nebolo dané nič, podľa čoho smerovať. Keď je rozdelenie skutočné, napíšte ho vedľa profilov, aby ďalší človek nepridal druhý alias a nečakal, že prácu urobí on.