Dvě servisní adresy na jednom klientu OpenVPN: iroute a lo

Aplikace odpovídá na své adrese tunelu, a adresa, kterou jste pro ni zdokumentovali, nikam nevede. V logu OpenVPN si nic nestěžuje, peer se jeví jako připojený a hub vypisuje přesně jednoho klienta. Mezera je v tom, že druhá adresa na klientu jsou dvě oddělená fakta: hostitel ji musí vlastnit a hub musí vědět, který peer ji vlastní. Vyřešte jedno bez druhého a provoz buď zemře na hubu, nebo dorazí bez cesty domů.

Alias je místní, vlastnictví je vzdálené

Adresa tunelu se vyjednává, takže se ji oba konce dozvědí během handshake. Další servisní adresa se nevyjednává vůbec, a proto její přidání samo o sobě na hubu nic nemění. Klient může adresu vlastnit okamžitě a server přesto pošle tento provoz na svou výchozí cestu nebo ho zahodí. Je třeba vytvořit dva záznamy na dvou různých místech.

Na klientu adresa patří hostiteli a loopback je přirozeným domovem pro identitu služby, která by se nikdy neměla objevit na fyzickém spoji. Na hubu je mapování peeru na prefix samostatná deklarace, kterou čte jen server. Ani jeden záznam neimplikuje ten druhý.

Držte oba rozsahy oddělené i ve svých poznámkách. Adresy v příkladu jsou dokumentační hodnoty a jejich překrytí se skutečnou LAN je nejrychlejší způsob, jak nechat funkční nastavení vypadat rozbitě.

Přidejte adresu na klientu trvale

Umístěte servisní adresu na loopback s prefixem hostitele, aby ji hostitel považoval za místní vstup, nikoli za podsíť, ke které se má dostat. ip address add 10.66.0.10/32 dev lo to udělá pro jednu adresu a opakování příkazu pro druhou adresu modeluje dvě služby.

Spusťte to jako jednorázový test, pak to přesuňte do toho, co vlastní síťovou konfiguraci hostitele, protože přírůstek za běhu zmizí po restartu a duplikáty se hromadí mezi opětovnými připojeními. Jednotka systemd seřazená po síti je jedna možnost a síťový správce distribuce druhá. Ať zvolíte cokoli, adresa musí existovat dřív, než se aplikace naváže, jinak služba naběhne na špatném socketu. Ověřte pomocí ip address show dev lo po restartu, ne po ručním příkazu.

Navázání je samostatné rozhodnutí od adresování. Aplikace, která poslouchá na všech adresách, přijímá provoz na rozhraních, která jste nikdy nezamýšleli, takže ji namiřte na konkrétní servisní adresu. Místní vstupní politika pak má na co přesně reagovat.

Vyzvedněte ji v souboru CCD, který hub skutečně čte

Na serveru deklarace vlastnictví jde do souboru jednotlivého klienta vybraného ověřeným obecným jménem, uvnitř adresáře pojmenovaného pomocí client-config-dir. Řádek je iroute 10.66.0.10 255.255.255.255, jeden na adresu, a říká serveru, který peer má dostávat provoz pro tento cíl.

Dva detaily to tiše rozbijí. Název souboru musí odpovídat jménu, které server skutečně používá, a to se liší, když je ve hře username-as-common-name. A iroute působí jen v režimu TUN s nakonfigurovaným adresářem konfigurace klientů, takže stejný řádek v mostovém nasazení nic nedělá. Přidávejte řádky do existujícího souboru, místo abyste ho nahrazovali, protože už může nést pevnou adresu nebo push volby. Reference OpenVPN 2.6 dokumentuje adresář i direktivu vlastnictví.

Vlastní jádro hubu také potřebuje cestu k těmto cílům, aby se místně generovaný provoz dostal do procesu tunelu. route 10.66.0.10 255.255.255.255 v konfiguraci serveru pokrývá provoz, který server sám vytváří, zatímco ostatní klienti potřebují push "route 10.66.0.10 255.255.255.255", aby se cíl naučili sami.

Směrování a autorizace zůstávají oddělené. Vyslaná trasa říká klientovi, kam posílat pakety, a nic nepřiděluje; služba stále musí volajícího přijmout za svých podmínek.

Zkontrolujte vstupní politiku a zpáteční cestu

Paket adresovaný aliasu dorazí na vlastnícího hostitele jako místní vstup, takže otázkou je, zda místní firewall tento zdroj a port povoluje. Povolte konkrétní servisní port z rozsahu zdrojů VPN místo otevírání celé adresy.

Odpovědi potřebují cestu zpět k volajícímu. Pro volajícího v běžném fondu tunelu tato cesta už existuje, protože ji nese zařízení tunelu. Volající za jinou směrovanou sítí potřebuje i zpáteční trasu této sítě, a právě zde asymetrická nastavení ztrácejí pakety.

Sledujte druhého posluchače na stejném portu navázaného na jinou adresu, protože jádro doručí tomu socketu, který odpovídá, a výsledky vypadají náhodně. Zkontrolujte pomocí ss -lntp a potvrďte, že navázaná adresa je alias služby. Zdrojový NAT zde není potřeba a jeho přidání skryje identitu volajícího, na které závisí vaše logy.

Testujte adresy a vlastnictví odděleně

Testujte ve dvou krocích. Nejprve potvrďte, že vlastnící hostitel dosáhne na službu na svém aliasu sám ze sebe, což oddělí problémy s navázáním a firewallem od směrování. Pak testujte ze skutečného volajícího VPN s autentizací samotné aplikace. Když první projde a druhý selže, chybějící díl je na straně hubu.

Zkontrolujte i režimy selhání, které přežijí spojení: alias zůstane přiřazen, když je tunel mimo provoz, a hub si drží trasu, když peer chybí. Žádný objekt sám o sobě nedokazuje, že je služba dosažitelná, a proto dvoukrokový test poráží jediný ping z notebooku.