Hová való az útvonal az OpenVPN-ben: az ügyfélhez vagy a szerverhez?
A szerverkonfigurációban lévő csupasz útvonal a szervert változtatja meg, nem az ügyfelet. Válassza az ügyfélfájlt, egy globális push-t vagy egy ügyfélre szóló push-t, és ellenőrizze, mi érkezett meg.
Hozzáadja a route 10.60.0.0 255.255.255.0 sort a szerverkonfigurációhoz, újraindít, újracsatlakoztat egy laptopot, és az alhálózat továbbra sem érhető el arról a laptopról. A sor elfogadásra került, a szolgáltatás tisztán elindult, és semmi sem tűnik hibásnak a naplóban. Az történt, hogy az útvonal azon a gépen telepítődött, amelyet szerkesztett: az átjáró most azt hiszi, hogy elérheti azt a prefixet, miközben az ügyfélnek semmit sem mondtak. Az elhelyezés az egész kérdés, és négy hely van, ahol ugyanaz a sor élhet.
A négy hely és ki kapja meg mindegyiket
Egy útvonal hozzáadható az ügyfél saját konfigurációjával, felajánlható minden ügyfélnek globális push-sal, felajánlható egy ügyfélnek ügyfélspecifikus fájllal, vagy beírható a szerver saját útválasztási kontextusába.
Ez a négy eset majdnem azonos szintaxist használ, és teljesen eltérő eredményeket ad. Az első három azt befolyásolja, mit küld az ügyfél az alagútba; a negyedik azt, hogyan ér el a szerver egy hálózatot, ami hasznos, ha magának a szervernek kell egy útvonal, és káros, ha összetévesztik a terjesztéssel.
Döntse el, melyiket szeretné a négy közül, mielőtt megírja a sort, majd erősítse meg a fogadót.
| 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 |
Miért lepi meg az embereket a csupasz szerverútvonal
A szerverkonfiguráció az első hely, ahová a rendszergazdák néznek, és az ottani útvonalutasítás úgy hangzik, mint egy állítás a VPN-hálózatról. Nem az. OpenVPN helyi útvonaltelepítésként kezeli a démon futtató gépen, ami pontosan ugyanolyan változtatás, mint amit ip route segítségével tenne, majd elfelejtene.
A terjesztéshez az útvonalat pusholni kell, a pushhoz pedig az ügyfélnek húznia kell. A letöltött opciók kikapcsolásával indított ügyfél teljesen figyelmen kívül hagyja az ajánlatot. Ellenőrizze a kézfogás mindkét végét, mielőtt átírja a szerverfájlt, mert a szervernapló nem fog panaszkodni: az ő oldaláról az ajánlat elküldésre került. Az elfogadott útvonal is csak a következő csatlakozáskor lép életbe, soha nem abban a munkamenetben, amelyben már van.
Amint a két műveletet külön látja, a hiba megszűnik rejtélyes lenni: a szerver eléri a prefixet, az ügyfél nem, és mindkét állítás egyszerre igaz.
Ügyfélspecifikus fájlok és az identitás, amelyhez illeszkednek
Az ügyfélspecifikus fájl neve az az identitás, amelyet a szerver hitelesített, ami alapértelmezésben a tanúsítvány köznapi neve. Az asztali ügyfélbarát kapcsolatnév nem ez az érték, és az eltérés olyan fájlt eredményez, amelyet soha nem olvasnak.
Ellenőrizze a könyvtárat, amelyet a szerver ténylegesen használ, majd erősítse meg, hogy a fájlnév pontosan megegyezik a hitelesített identitással, a kis- és nagybetűket is beleértve.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Ezen a fájlon belül az útvonalat továbbra is pusholni kell, mert az ügyfélkontextus az adott ügyfél munkamenetére alkalmazott opciók halmaza, nem helyi útválasztási tábla. Az ottani csupasz útvonal ugyanazt a problémát hordozza, mint a globális fájlban lévő csupasz útvonal.
Az ügyfél saját fájlja és az azt kezelő eszköz
Az ügyfél konfigurációjába helyezett útvonal akkor telepítődik, amikor az az ügyfél csatlakozik, és akkor törlődik, amikor lecsatlakozik, ami a helyes életciklus egy statikus célállomáshoz.
Ha a profilt hálózatkezelő birtokolja, előfordulhat, hogy egyszer importálja ezeket az opciókat, majd megtartja a saját másolatát. A letöltött fájl utólagos szerkesztése semmit sem változtat, ami gyakori oka a "az útvonal ott van, de nem érvényesül" jelenségnek.
Ellenőrizze az aktív profilt a letöltött fájl helyett, és ellenőrizze az importált beállításokat, amelyeket a kezelő megjelenít. Ezután csatlakozzon, és kérdezze meg a rendszertől, melyik utat használja egy adott cím, ahelyett hogy feltételezné, hogy az alagút nyert, mert az útvonal egy szövegfájlban szerepelt.
Ellenőrizze az ügyfélen, majd ellenőrizze a visszautat
Kérdezze meg az ügyfél saját útválasztási tábláját a célállomásról, ne a szerverét. Egyetlen hoszt keresése a prefixen belül elég ahhoz, hogy megmutassa a használni kívánt interfészt és következő ugrást.
ip route get 10.60.0.10Ha a keresés az alagútra mutat, a terjesztés működött, és a fennmaradó probléma máshol van. Ha az alapértelmezett átjáróra mutat, az útvonal nem települt, egy ügyféloldali opció kiszűrte, vagy olyan profilhoz tartozik, amelyet az ügyfél nem használ.
Tegyük fel, hogy a terjesztés működött, és mégis semmi sem válaszol: akkor ellenőrizze az átjárón a továbbítást, a másik oldal visszaútját és a köztük lévő tűzfalat. Az útvonal utat választ, nem ad hozzáférést.