Dve servisné adresy na jednom klientovi OpenVPN: iroute a lo

Aplikácia odpovedá na svojej adrese tunela, a adresa, ktorú ste pre ňu zdokumentovali, nevedie nikam. V protokole OpenVPN sa nič nesťažuje, peer sa zobrazuje ako pripojený a hub uvádza presne jedného klienta. Medzera je v tom, že druhá adresa na klientovi sú dve oddelené skutočnosti: hostiteľ ju musí vlastniť a hub musí vedieť, ktorý peer ju vlastní. Vyriešte jedno bez druhého a prevádzka buď zomrie na hube, alebo dorazí bez cesty domov.

Alias je lokálny, vlastníctvo je vzdialené

Adresa tunela sa vyjednáva, takže ju oba konce spoznajú počas handshake. Ďalšia servisná adresa sa nevyjednáva vôbec, a preto jej pridanie samo o sebe na hube nič nemení. Klient môže adresu vlastniť okamžite a server napriek tomu pošle túto prevádzku na svoju predvolenú cestu alebo ju zahodí. Treba vytvoriť dva záznamy na dvoch rôznych miestach.

Na klientovi adresa patrí hostiteľovi a loopback je prirodzeným domovom pre identitu služby, ktorá by sa nikdy nemala objaviť na fyzickom spojení. Na hube je mapovanie peera na prefix samostatná deklarácia, ktorú číta len server. Ani jeden záznam neimplikuje ten druhý.

Držte oba rozsahy oddelené aj vo svojich poznámkach. Adresy v príklade sú dokumentačné hodnoty a ich prekrytie so skutočnou LAN je najrýchlejší spôsob, ako nechať funkčné nastavenie vyzerať pokazene.

Pridajte adresu na klientovi trvalo

Umiestnite servisnú adresu na loopback s prefixom hostiteľa, aby ju hostiteľ považoval za lokálny vstup, a nie za podsiet, ku ktorej sa treba dostať. ip address add 10.66.0.10/32 dev lo to urobí pre jednu adresu a opakovanie príkazu pre druhú adresu modeluje dve služby.

Spustite to ako jednorazový test, potom to presuňte do toho, čo vlastní sieťovú konfiguráciu hostiteľa, pretože prírastok za behu zmizne po reštarte a duplikáty sa hromadia medzi opätovnými pripojeniami. Jednotka systemd zoradená po sieti je jedna možnosť a sieťový správca distribúcie druhá. Čokoľvek si vyberiete, adresa musí existovať predtým, než sa aplikácia naviaže, inak služba nabieha na nesprávnom sockete. Overte pomocou ip address show dev lo po reštarte, nie po ručnom príkaze.

Naviazanie je samostatné rozhodnutie od adresovania. Aplikácia, ktorá počúva na každej adrese, prijíma prevádzku na rozhraniach, ktoré ste nikdy nezamýšľali, takže ju nasmerujte na konkrétnu servisnú adresu. Potom má miestna vstupná politika na čo presne reagovať.

Vyžiadajte si ju v súbore CCD, ktorý hub skutočne číta

Na serveri deklarácia vlastníctva ide do súboru jednotlivého klienta vybraného overeným spoločným menom, v adresári pomenovanom pomocou client-config-dir. Riadok je iroute 10.66.0.10 255.255.255.255, jeden na adresu, a hovorí serveru, ktorý peer má dostávať prevádzku pre tento cieľ.

Dva detaily to potichu pokazia. Názov súboru musí zodpovedať názvu, ktorý server skutočne používa, a ten sa líši, keď je v hre username-as-common-name. A iroute pôsobí len v režime TUN s nakonfigurovaným adresárom konfigurácie klienta, takže rovnaký riadok v mostovom nasadení nič nerobí. Pridávajte riadky do existujúceho súboru namiesto jeho nahradenia, pretože už môže niesť pevnú adresu alebo push možnosti. Referencia OpenVPN 2.6 dokumentuje adresár aj direktívu vlastníctva.

Vlastné jadro hubu tiež potrebuje cestu k týmto cieľom, aby sa miestne generovaná prevádzka dostala do procesu tunela. route 10.66.0.10 255.255.255.255 v konfigurácii servera pokrýva prevádzku, ktorú server sám vytvára, zatiaľ čo iní klienti potrebujú push "route 10.66.0.10 255.255.255.255", aby sa cieľ naučili sami.

Smerovanie a autorizácia zostávajú oddelené. Odoslaná trasa hovorí klientovi, kam posielať pakety, a nič neprideľuje; služba stále musí volajúceho prijať za svojich podmienok.

Skontrolujte vstupnú politiku a spiatočnú cestu

Paket adresovaný aliasu dorazí na vlastniaceho hostiteľa ako miestny vstup, takže otázkou je, či miestny firewall povoľuje tento zdroj a port. Povoľte konkrétny servisný port z rozsahu zdrojov VPN namiesto otvárania celej adresy.

Odpovede potrebujú cestu späť k volajúcemu. Pre volajúceho v bežnom fonde tunela táto cesta už existuje, pretože ju nesie zariadenie tunela. Volajúci za inou smerovanou sieťou potrebuje aj spiatočnú trasu tejto siete, a práve tu asymetrické nastavenia strácajú pakety.

Sledujte druhého poslucháča na tom istom porte naviazaného na inú adresu, pretože jadro doručí tomu socketu, ktorý zodpovedá, a výsledky vyzerajú náhodne. Skontrolujte pomocou ss -lntp a potvrďte, že naviazaná adresa je alias služby. Zdrojový NAT tu nie je potrebný a jeho pridanie skryje identitu volajúceho, na ktorej závisia vaše protokoly.

Testujte adresy a vlastníctvo oddelene

Testujte v dvoch krokoch. Najprv potvrďte, že vlastniaci hostiteľ dosiahne službu na svojom aliase sám zo seba, čo oddeľuje problémy s naviazaním a firewallom od smerovania. Potom testujte zo skutočného volajúceho VPN s autentifikáciou samotnej aplikácie. Keď prvý prejde a druhý zlyhá, chýbajúci diel je na strane hubu.

Skontrolujte aj režimy zlyhania, ktoré prežijú spojenie: alias zostane pridelený, keď je tunel mimo prevádzky, a hub si drží svoju trasu, keď peer chýba. Žiadny objekt sám o sebe nedokazuje, že služba je dostupná, a preto dvojkrokový test poráža jediný ping z notebooku.