Kam patrí trasa v OpenVPN: ku klientovi alebo k serveru?
Holá trasa v konfigurácii servera mení server, nie klienta. Vyberte klientsky súbor, globálny push alebo push pre jedného klienta a skontrolujte, čo prišlo.
Pridáte route 10.60.0.0 255.255.255.0 do konfigurácie servera, reštartujete, znova pripojíte notebook a podsiet je z tohto notebooku stále nedostupná. Riadok bol prijatý, služba sa čisto spustila a v logu nič nevyzerá zle. Stalo sa to, že trasa bola nainštalovaná na stroji, ktorý ste upravovali: brána si teraz myslí, že dokáže dosiahnuť ten prefix, zatiaľ čo klientovi nebolo nič povedané. Umiestnenie je celá otázka a existujú štyri miesta, kde môže ten istý riadok žiť.
Štyri miesta a kto každé z nich dostane
Trasu možno pridať vlastnou konfiguráciou klienta, ponúknuť každému klientovi cez globálny push, ponúknuť jednému klientovi cez súbor špecifický pre klienta alebo zapísať do vlastného smerovacieho kontextu servera.
Tieto štyri prípady používajú takmer identickú syntax a prinášajú úplne odlišné výsledky. Prvé tri ovplyvňujú, čo klient posiela do tunela; štvrtý ovplyvňuje, ako server dosiahne sieť, čo je užitočné, keď server sám potrebuje cestu, a škodlivé, keď sa to zamení za distribúciu.
Rozhodnite, ktorý zo štyroch chcete, skôr než riadok napíšete, a potom potvrďte príjemcu.
| 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 |
Prečo holá serverová trasa ľudí prekvapuje
Konfigurácia servera je miesto, kam sa správcovia pozerajú najskôr, a direktíva trasy tam znie ako tvrdenie o sieti VPN. Nie je. OpenVPN ju berie ako miestnu inštaláciu trasy na stroji, kde beží démon, čo je presne ten istý druh zmeny, akú by ste urobili pomocou ip route a potom na ňu zabudli.
Distribúcia vyžaduje, aby bola trasa odoslaná pushom, a push vyžaduje, aby si ju klient stiahol. Klient spustený s vypnutými stiahnutými voľbami ponuku úplne ignoruje. Skontrolujte oba konce tohto podania ruky, než prepíšete súbor servera, pretože log servera sa nebude sťažovať: z jeho strany bola ponuka odoslaná. Prijatá trasa navyše platí až pri ďalšom pripojení, nikdy v relácii, v ktorej už ste.
Keď obe operácie uvidíte oddelene, zlyhanie prestane byť záhadné: server na prefix dosiahne, klient nie, a obe tvrdenia platia súčasne.
Súbory pre jednotlivých klientov a identita, s ktorou sa zhodujú
Súbor pre konkrétneho klienta je pomenovaný podľa identity, ktorú server autentizoval, čo je predvolene bežné meno certifikátu. Priateľský názov pripojenia v desktopovom klientovi nie je táto hodnota a nezhoda vytvorí súbor, ktorý sa nikdy neprečíta.
Skontrolujte adresár, ktorý server skutočne používa, a potom potvrďte, že názov súboru presne zodpovedá autentizovanej identite, vrátane veľkosti písmen.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Vnútri tohto súboru sa trasa stále musí odoslať pushom, pretože kontext pre konkrétneho klienta je sada volieb aplikovaných na reláciu tohto klienta, nie miestna smerovacia tabuľka. Holá trasa tam má rovnaký problém ako holá trasa v globálnom súbore.
Vlastný súbor klienta a nástroj, ktorý ho vlastní
Trasa umiestnená v konfigurácii klienta sa nainštaluje, keď sa tento klient pripojí, a odstráni, keď sa odpojí, čo je správny životný cyklus pre statický cieľ.
Ak profil vlastní správca siete, môže tieto voľby raz importovať a potom si držať vlastnú kópiu. Úprava stiahnutého súboru neskôr nič nezmení, čo je častá príčina vety "trasa tam je, ale neplatí".
Skontrolujte aktívny profil, nie súbor, ktorý ste stiahli, a skontrolujte importované nastavenia, ktoré správca zobrazuje. Potom sa pripojte a spýtajte sa systému, ktorú cestu konkrétna adresa používa, namiesto toho, aby ste predpokladali, že tunel vyhral, pretože trasa existovala v textovom súbore.
Overte na klientovi a potom skontrolujte spiatočnú cestu
Spýtajte sa na cieľ vlastnej smerovacej tabuľky klienta, nie servera. Vyhľadanie jedného hostiteľa vnútri prefixu stačí na to, aby ukázalo rozhranie a ďalší skok, ktoré sa použijú.
ip route get 10.60.0.10Ak vyhľadanie ukazuje na tunel, distribúcia fungovala a zostávajúci problém je inde. Ak ukazuje na predvolenú bránu, trasa nebola nainštalovaná, bola odfiltrovaná voľbou na strane klienta alebo patrí profilu, ktorý klient nepoužíva.
Predpokladajte, že distribúcia fungovala, a napriek tomu nič neodpovedá: potom skontrolujte preposielanie na bráne, spiatočnú trasu protiľahlej strany a akýkoľvek firewall medzi nimi. Trasa vyberá cestu, neprideľuje prístup.