OpenVPN přes TCP i UDP z jednoho hostitele
Před verzí 2.7 váže jeden proces jeden transport. Porovnejte přemostěnou dvojici TAP, dvě podsítě TUN a společný fond, poté každý profil přiřaďte jeho naslouchači.
Sítě, které povolují jen TCP 443, koexistují se sítěmi, které UDP bez potíží propouštějí, a jeden server musí obsloužit obě. Profil s proto udp odpovídá druhé skupině a na první selhává, a úprava stejné konfigurace na proto tcp nevytvoří druhý naslouchač. Direktiva volí jeden transport pro jeden proces. Vše ostatní z toho vyplývá.
Buď spustíte více než jeden proces, nebo spustíte verzi, která umí svázat několik socketů najednou.
Před 2.7 váže jeden proces jeden transport
Komunitní verze OpenVPN váže socket, který popisuje proto , a tato direktiva volí jediný transport pro instanci. TCP a UDP jsou oddělené zásobníky, takže stejné číslo portu může obsadit obojí současně, ale ne jeden proces. Řada 2.6 vám proto dává jeden transport na démona. OpenVPN 2.7 toto omezení pro servery odstranil, ty mohou svázat několik socketů pomocí několika --local v jednom procesu.
Ověřte verzi, než začnete navrhovat kolem kterékoli z obou odpovědí, protože uspořádání 2.7 je jiný provozní model s vlastní syntaxí konfigurace. Příručka psaná pro 2.6 popisuje dva procesy, i když to neříká.
Tři způsoby, jak provozovat dvě instance
S rozhraními TAP spusťte jednu instanci na transport a přemostěte obě zařízení tap na hostiteli. Obě sady klientů skončí ve stejné broadcastové doméně, což jednomu fondu adres umožní je pokrýt a udrží chod protokolů závislých na broadcastu. S TUN přemostění není k dispozici, takže nejjednodušší rozdělení dá každé instanci vlastní podsíť a směrování udrží obě sady klientů oddělené. Třetí možnost zachová jeden fond tím, že každá instance volá skript learn-address , který klientovi nainstaluje trasu /32 přes zařízení dané instance.
Právě toto třetí uspořádání lidé žádají a právě ono vyžaduje největší péči, protože skript se stává součástí datové cesty a musí správně zpracovat události přidání, aktualizace a smazání.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Udržte obě instance oddělené
Každá instance také potřebuje samostatný port nebo adresu, samostatný stavový soubor a samostatné cílové umístění logu. Dva démoni zapisující do jednoho stavového souboru vytvářejí výstup, který se během incidentu nedá číst, a to je přesně chvíle, kdy ho potřebujete. Pokud druhá instance váže konkrétní adresu, musí tato adresa na hostiteli existovat při startu procesu; jinak skončí chybou při vázání dřív, než cokoli řekne o klíčích.
Pojmenujte jednotky a profily tak, aby byl transport zřejmý už z názvu souboru . Další operátor by neměl muset otevírat konfiguraci, aby zjistil, která je TCP.
Přiřaďte profil naslouchači
Server provozující proto tcp očekává klientský profil s proto tcp-client , a profil, který stále nese proto udp vůči tomuto naslouchači vyprší bez chyby, na kterou by uživatel mohl reagovat . Udržte dva profily, pokud nasazení nabízí oba transporty, a označte je tak, aby podpora poznala, který byl vyzkoušen. Samotné číslo portu transport nepopisuje.
Pravidla firewallu jdou stejným rozdělením: pravidlo pro UDP 1194 neříká nic o TCP 1194 a pravidlo pro jednu adresu nepokrývá druhý naslouchač.
Nejprve si přečtěte pohled serveru
Začněte na serveru příkazem ss -lntup a potvrďte, že se objeví jak TCP, tak UDP naslouchač. Poté připojte jednoho klienta každého druhu a ve stavovém výstupu zkontrolujte dva záznamy s odlišnými adresami. Pokud sockety existují a žádný klient nepřichází, cesta nebo firewall odmítá pakety dřív, než je démon uvidí.
Socket, který se nikdy neobjeví, je problém konfigurace nebo vázání, a socket, který se objeví, ale nikdy nezaznamená spojení, je problém filtrování. Z pohledu klienta vypadají oba stejně, proto přichází pohled samotného serveru první. Mějte na paměti, že TCP nese blokování na začátku fronty, takže jeho nabídnutí je opatření dostupnosti, nikoli vylepšení pro klienty s čistou cestou UDP.