Kam patří trasa v OpenVPN: ke klientovi, nebo k serveru?
Holá trasa v konfiguraci serveru mění server, ne klienta. Zvolte klientský soubor, globální push nebo push pro jednoho klienta a zkontrolujte, co dorazilo.
Přidáte route 10.60.0.0 255.255.255.0 do konfigurace serveru, restartujete, znovu připojíte notebook a podsíť je z tohoto notebooku stále nedostupná. Řádek byl přijat, služba se čistě spustila a v logu nic nevypadá špatně. Stalo se to, že trasa byla nainstalována na stroj, který jste upravovali: brána si nyní myslí, že na ten prefix dosáhne, zatímco klientovi nebylo řečeno nic. Umístění je celá otázka a existují čtyři místa, kde může stejný řádek žít.
Čtyři místa a kdo každé z nich dostane
Trasu lze přidat vlastní konfigurací klienta, nabídnout všem klientům globálním pushem, nabídnout jednomu klientovi souborem pro konkrétního klienta nebo zapsat do vlastního směrovacího kontextu serveru.
Tyto čtyři případy používají téměř totožnou syntaxi a přinášejí zcela odlišné výsledky. První tři ovlivňují, co klient posílá do tunelu; čtvrtý ovlivňuje, jak server dosáhne na síť, což je užitečné, když server sám potřebuje cestu, a škodlivé, když je to zaměněno za distribuci.
Rozhodněte, který ze čtyř chcete, než řádek napíšete, a poté potvrďte příjemce.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Proč holá serverová trasa lidi překvapuje
Konfigurace serveru je místo, kam se správci dívají nejdřív, a direktiva trasy tam zní jako tvrzení o síti VPN. Není. OpenVPN ji bere jako místní instalaci trasy na stroji, kde běží démon, což je přesně stejný druh změny, jaký byste provedli pomocí ip route a pak na ni zapomněli.
Distribuce vyžaduje, aby byla trasa odeslána pushem, a push vyžaduje, aby si ji klient stáhl. Klient spuštěný s vypnutými staženými volbami nabídku zcela ignoruje. Zkontrolujte oba konce tohoto podání ruky, než přepíšete soubor serveru, protože log serveru si stěžovat nebude: z jeho strany byla nabídka odeslána. Přijatá trasa navíc platí až při příštím připojení, nikdy v relaci, ve které už jste.
Jakmile obě operace uvidíte odděleně, selhání přestane být záhadné: server na prefix dosáhne, klient ne, a obě tvrzení platí současně.
Soubory pro jednotlivé klienty a identita, se kterou se shodují
Soubor pro konkrétního klienta je pojmenován podle identity, kterou server autentizoval, což je ve výchozím nastavení běžné jméno certifikátu. Přátelský název připojení v desktopovém klientovi není tato hodnota a neshoda vytvoří soubor, který se nikdy nepřečte.
Zkontrolujte adresář, který server skutečně používá, a poté potvrďte, že název souboru přesně odpovídá autentizované identitě, včetně velikosti písmen.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Uvnitř tohoto souboru se trasa stále musí odeslat pushem, protože kontext pro konkrétního klienta je sada voleb aplikovaných na relaci tohoto klienta, nikoli místní směrovací tabulka. Holá trasa tam má stejný problém jako holá trasa v globálním souboru.
Vlastní soubor klienta a nástroj, který ho vlastní
Trasa umístěná v konfiguraci klienta se nainstaluje, když se tento klient připojí, a odstraní, když se odpojí, což je správný životní cyklus pro statické cíle.
Pokud profil vlastní správce sítě, může tyto volby jednou importovat a pak si držet vlastní kopii. Úprava staženého souboru později nic nezmění, což je častá příčina věty "trasa tam je, ale neplatí".
Zkontrolujte aktivní profil, ne soubor, který jste stáhli, a zkontrolujte importovaná nastavení, která správce zobrazuje. Poté se připojte a zeptejte se systému, kterou cestu konkrétní adresa používá, místo abyste předpokládali, že tunel vyhrál, protože trasa existovala v textovém souboru.
Ověřte na klientovi a poté zkontrolujte zpáteční cestu
Zeptejte se na cíl vlastní směrovací tabulky klienta, ne serveru. Vyhledání jednoho hostitele uvnitř prefixu stačí k tomu, aby ukázalo rozhraní a další skok, které se použijí.
ip route get 10.60.0.10Pokud vyhledání ukazuje na tunel, distribuce fungovala a zbývající problém je jinde. Pokud ukazuje na výchozí bránu, trasa nebyla nainstalována, byla odfiltrována volbou na straně klienta nebo patří profilu, který klient nepoužívá.
Předpokládejte, že distribuce fungovala, a přesto nic neodpovídá: pak zkontrolujte předávání na bráně, zpáteční trasu protistrany a jakýkoli firewall mezi nimi. Trasa vybírá cestu, nepřiděluje přístup.