VPN-кліенты дасягаюць сервера, але не LAN: якое рашэнне?

Кліент пінгуе адрас тунэля OpenVPN-сервера і атрымлівае адказ, потым спрабуе хаст у LAN-сетцы сервера і не атрымлівае нічога. Гэтае раздзяленне моцна звужае няспраўнасць: тунэль узняты, перасылка напэўна працуе, а адказ выходзіць праз дзверы, якія не вядуць назад. Ёсць тры рашэнні, і правільнае залежыць ад таго, што вы кантралюеце і ад чаго гатовы адмовіцца. Адказайце на тры пытанні ніжэй па парадку, і выбар перастане быць справай смаку.

Спачатку вызначце, які напрамак зламаны

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Калі хаст у LAN-сетцы ўжо паказвае на VPN-сервер, ваша праблема — правіла фаервола або абмежаванне MTU, а не адсутны зваротны шлях. Не дадавайце маршрут, каб выправіць фільтр.

Пытанне першае: ці можаце вы рэдагаваць маршрутызатар далёкай LAN-сеткі?

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

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

NAS або Layer 3 камутатар, які хостыць паслугу, патрабуе таго ж маршруту, калі ён не адпраўляе ўсё праз маршрутызатар, які яго мае. Праверце прыладу, якая завяршае падсетку, а не толькі тую, што павернута да інтэрнэту. Малыя сеткі часта маюць тры прылады з думкай пра маршрутызацыю.

Пытанне другое: ці можа LAN-сетка перастаць бачыць адрасы кліентаў?

Калі маршрутызатар належыць камусьці іншаму, пераклад на VPN-серверы не патрабуе супрацоўніцтва. Хаст у LAN-сетцы бачыць адрас LAN-сеткі сервера, адказвае яму, а сервер перакладае назад. Таму прылады і ролі аддаленага доступу на базе NAT паводзяць сябе так.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Цана — гэта атрыбуцыя: адрасы на кліента знікаюць з запісаў LAN-сеткі. Любы спіс дазволеных на хасце ў LAN-сетцы тады павінен называць сервер замест пула.

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

Пытанне трэцяе: ці сервер сам з'яўляецца кліентам іншага тунэля?

Уявіце іншую тапалогію: VPN-сервер таксама тэлефануе камерцыйнаму правайдэру, таму мае два тунэлі і два наборы адрасоў. Трафік, які ён перасылае сваім кліентам, выходзіць праз правайдэра, а той не будзе маршрутызаваць адказы назад да адрасоў пула. Таму адказы знікаюць, хоць абодва тунэлі здаровыя.

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

Потым праверце абодва напрамкі і абодва памеры

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

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

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