Дзе месціцца маршрут у OpenVPN: у кліенце ці ў серверы?
Голы маршрут у канфігурацыі сервера змяняе сервер, а не кліент. Выберыце кліенцкі файл, глабальны push або push для асобнага кліента і праверце, што прыйшло.
Вы дадаяце route 10.60.0.0 255.255.255.0 у канфігурацыю сервера, перазапускаеце, зноў падключаеце ноўтбук, а падсетка да гэтага ноўтбука ўсё яшчэ недаступная. Радок быў прыняты, служба стартавала чыста, і ў журнале нішто не выглядае няправільным. Адбылося тое, што маршрут быў усталяваны на машыне, якую вы рэдагавалі: шлюз цяпер лічыць, што можа дасягнуць гэтага прэфікса, а кліенту нічога не паведамілі. Размяшчэнне — гэта ўсё пытанне, і ёсць чатыры месцы, дзе можа жыць той самы радок.
Чатыры месцы і хто кожнае атрымлівае
Маршрут можа быць дададзены ўласнай канфігурацыяй кліента, прапанаваны кожнаму кліенту праз глабальны push, прапанаваны аднаму кліенту праз файл для пэўнага кліента або запісаны ва ўласны кантэкст маршрутызацыі сервера.
Гэтыя чатыры выпадкі выкарыстоўваюць амаль аднолькавы сінтаксіс і даюць цалкам розныя вынікі. Першыя тры ўплываюць на тое, што кліент адпраўляе ў тунель; чацвёрты ўплывае на тое, як сервер дасягае сеткі, што карысна, калі серверу самому патрэбны шлях, і шкодна, калі гэта памылкова прымаюць за раздачу.
Вызначце, які з чатырох вам патрэбны, перш чым пісаць радок, затым пацвердзіце атрымальніка.
| 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 |
Чаму голы серверны маршрут здзіўляе людзей
Канфігурацыя сервера — гэта тое, куды адміністратары глядзяць перш за ўсё, і дырэктыва маршруту там чытаецца як сцвярджэнне пра VPN-сетку. Гэта не так. OpenVPN разглядае яе як лакальную ўстаноўку маршруту на машыне, дзе працуе дэман, — гэта менавіта такое змяненне, якое вы зрабілі б з ip route і потым забыліся.
Раздача патрабуе, каб маршрут быў адпраўлены праз push, а push патрабуе, каб кліент яго забраў. Кліент, запушчаны з адключанымі атрыманымі опцыямі, цалкам ігнаруе прапанову. Праверце абодва канцы гэтага рукапаціскання, перш чым перапісваць серверны файл, бо журнал сервера не паскардзіцца: з яго боку прапанова была адпраўлена. Прыняты маршрут таксама ўступае ў сілу толькі пры наступным падключэнні і ніколі ў сеансе, у якім вы ўжо знаходзіцеся.
Калі вы ўбачыце дзве аперацыі як асобныя, збой перастане быць загадкавым: сервер дасягае прэфікса, кліент не можа, і абодва сцвярджэнні праўдзівыя адначасова.
Файлы для асобных кліентаў і ідэнтычнасць, якой яны адпавядаюць
Файл для пэўнага кліента называецца па ідэнтычнасці, якую сервер аўтэнтыфікаваў, а па змаўчанні гэта агульная назва сертыфіката. Зручная назва злучэння ў настольным кліенце не з'яўляецца гэтым значэннем, і неадпаведнасць стварае файл, які ніколі не чытаецца.
Праверце каталог, які сервер фактычна выкарыстоўвае, затым пацвердзіце, што імя файла дакладна адпавядае аўтэнтыфікаванай ідэнтычнасці, уключаючы рэгістр.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Унутры гэтага файла маршрут усё яшчэ трэба адпраўляць праз push, бо кантэкст асобнага кліента — гэта набор опцый, якія прымяняюцца да сеансу гэтага кліента, а не лакальная табліца маршрутызацыі. Голы маршрут там мае тую ж праблему, што і голы маршрут у глабальным файле.
Уласны файл кліента і інструмент, які ім валодае
Маршрут, змешчаны ў канфігурацыі кліента, усталёўваецца, калі гэты кліент падключаецца, і выдаляецца, калі ён адключаецца, што з'яўляецца правільным жыццёвым цыклам для статычнага прызначэння.
Калі профілем валодае сеткавы менеджэр, ён можа аднойчы імпартаваць гэтыя опцыі, а потым захоўваць уласную копію. Рэдагаванне спампаванага файла пазней нічога не змяняе, і гэта частая прычына фразы "маршрут ёсць, але не дзейнічае".
Праверце актыўны профіль, а не файл, які вы спампавалі, і праверце імпартаваныя налады, якія паказвае менеджэр. Затым падключыцеся і спытайце ў сістэмы, які шлях выкарыстоўвае канкрэтны адрас, замест таго каб меркаваць, што тунель перамог, бо маршрут быў у тэкставым файле.
Праверце на кліенце, затым праверце зваротны шлях
Спытайце ўласную табліцу маршрутызацыі кліента пра прызначэнне, а не табліцу сервера. Пошуку аднаго хоста ўнутры прэфікса дастаткова, каб паказаць інтэрфейс і наступны хоп, якія будуць выкарыстаны.
ip route get 10.60.0.10Калі пошук паказвае на тунель, раздача спрацавала, і астатняя праблема ў іншым месцы. Калі ён паказвае на шлюз па змаўчанні, маршрут не ўсталяваны, быў адфільтраваны опцыяй на баку кліента або належыць профілю, які кліент не выкарыстоўвае.
Выкажам здагадку, што раздача спрацавала, а нішто не адказвае: тады праверце перанакіраванне на шлюзе, зваротны маршрут на процілеглым баку і любы файрвол паміж імі. Маршрут выбірае шлях, ён не дае доступу.