Чаму падсетка за кліентам OpenVPN недасяжная?

Пінгі да адраса тунеля сервера праходзяць, уласная табліца маршрутаў кліента выглядае слушна, а LAN за гэтым кліентам усё яшчэ недасяжная. Табліца маршрутызацыі кліента выглядае правільна, на серверы ёсць маршрут, накіраваны ў тунель, а пакеты ўсё роўна знікаюць. Гэта класічны сімптом тунеля layer-3, які не ведае, што адзін з яго кліентаў таксама з'яўляецца шлюзам.

Інтэрфейс tun не мае наступнага пераходу для кожнага кліента. Ядро бачыць адзіны інтэрфейс з мноствам партнёраў, таму рашэнне пра тое, які кліент атрымае пакет для аддаленай LAN, трэба прымаць унутры працэсу OpenVPN. Гэтае рашэнне наладжваецца праз iroute, і без яго пакету няма куды ісці.

Сервер маршрутызуе па кліенце, а не па інтэрфейсе

Калі серверу трэба адправіць пакет на адрас тунеля кліента, адказ адназначны: адрас належыць сесіі гэтага кліента. Калі ж прызначэннем з'яўляецца цэлая падсетка за гэтым кліентам, адрас не належыць нікому, каго ведае сервер, і маршрут ядра да тунеля кажа толькі "праз гэты інтэрфейс", не ўказваючы партнёра.

OpenVPN вырашае гэта ўнутранай табліцай маршрутаў, якая суадносіць прэфікс прызначэння з пэўным кліентам. Гэтая табліца будуецца з запісаў iroute, таму звычайнага маршруту на хасту сервера недастаткова. Маршрут ядра даносіць пакет да інтэрфейсу тунеля; унутранае супастаўленне вырашае, якая сесія яго атрымае. Таму і выпраўленне ніколі не паказваецца ў вывадзе маршрутаў ядра.

Калі супастаўлення няма, пакет даходзіць да сервера, супадае з маршрутам тунеля і адкідваецца, бо ніводзін кліент не заяўляе прызначэнне. Нішто не піша ў лаг чыстую памылку, таму збой выглядае як ціхая чорная дзірка, а не як пятля маршрутызацыі.

Запіс iroute, які называе кліента

iroute жыве ў канфігурацыйным файле канкрэтнага кліента, а не ў асноўнай канфігурацыі сервера. Накіруйце сервер на каталог опцыяй client-config-dir, затым стварыце файл, імя якога — агульнае імя сертыфіката кліента, і пакладзіце прэфікс унутр.

Для філіяла, чыя LAN — 10.20.0.0/24, а агульнае імя сертыфіката — branch-router, файл па гэтым шляху змяшчае радок накшталт iroute 10.20.0.0 255.255.255.0. Асноўнай канфігурацыі патрэбна толькі опцыя каталога; прэфікс жыве ў кліента.

Агульнае імя — гэта крохкая частка. Сертыфікат, выдадзены з іншым суб'ектам, або разгортванне, якое аўтэнтыфікуе карыстальнікаў па імені карыстальніка, тады як файл названы па сертыфікаце, дае файл, які ніколі не чытаецца. Праверце імя, якое сервер фактычна паведамляе для сесіі, і разгледзьце опцыю, якая прымушае неадпаведнага кліента пацярпець няўдачу замест ціхага падключэння без яго маршрутаў. Перайменаванне файла ў адпаведнасць з сертыфікатам — пяціхвіліннае выпраўленне, якое прадухіляе вельмі доўгі вечар.

Адзін кліент можа валодаць некалькімі прэфіксамі. Дадайце адзін радок iroute на кожную сетку і трымайце спіс побач з астатнімі наладамі гэтага кліента, каб супастаўленне заставалася правяральным.

Пабудова зваротнага шляху ў абодвух кірунках

Дастаўка пакетаў да аддаленай LAN — палова справы. Кліент таксама павінен адпраўляць трафік гэтай LAN у тунель, што звычайна робіцца штурханнем маршруту кліенту: радок накшталт push "route 10.8.0.0 255.255.255.0" кажа кожнаму кліенту, як дасягнуць сеткі на баку сервера. Для філіяла эквівалентны маршрут паказвае на тунель для ўсяго, чаго ён павінен дасягнуць на баку сервера.

Зваротны кірунак патрабуе ўласніка на далёкім баку. На тым баку хтосьці павінен ведаць шлях назад: статычны маршрут на маршрутызатары LAN, які накіроўвае пул VPN на сервер, або трансляцыя адрасоў на серверы перад уваходам трафіку ў LAN. Статычны маршрут захоўвае арыгінальныя адрасы бачнымі ў лагах і правілах доступу, але патрабуе супрацоўніцтва ўласніка LAN; трансляцыя самадастатковая, але хавае, хто насамрэч падключыўся.

Перасыланне павінна быць уключана на хасту сервера. Без яго ядро прымае пакет з тунеля і адмаўляецца перадаць яго ў інтэрфейс LAN, што з пункту гледжання кліента выглядае гэтак жа, як адсутны iroute.

Праверка дасяжнасці правільнымі пробамі

Тэстуйце па ўзроўнях, а не пінгуйце далёкі канец і здагадвайцеся. З сервера праверце, што ўнутранае супастаўленне для прэфікса існуе і што маршрут ядра паказвае на тунель. З кліента пераканайцеся, што ўкінуты маршрут усталяваны і што яго шлях па змаўчанні для адраса LAN — гэта тунель.

Затым назірайце за пакетамі. Захоп на інтэрфейсе тунеля паказвае, ці перадае сервер у бок кліента, а захоп на інтэрфейсе LAN паказвае, ці перасылае ён. Калі першы паказвае пакеты, а другі — не, праблема ў перасыланні або фільтры; калі ніводзін нічога не паказвае, пошук праваліўся раней.

Два серверы, злучаныя тунелем, паўтараюць тое ж правіла з абодвух бакоў: кожнаму патрэбны iroute для пула іншага, і кожнаму патрэбныя маршрут і перасыланне, якія робяць шлях сіметрычным. Маршрутызацыя і палітыка тут — асобныя пытанні. Маршрутызацыя вырашае, куды можа ісці пакет, а правіла FORWARD — ці можна, таму кліент з двума радкамі iroute можа дасягнуць абодвух прэфіксаў, калі фільтр не скажа інакш.