Кліенты VPN падключаюцца, але інтэрнэту няма: тры адсутныя часткі

Тунэль, які адказвае на ping, усё яшчэ патрабуе перадачы, трансляцыі і правіла перадачы. Вызначце, якой з трох частак не хапае, перш чым зноў правіць кліент.

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

Чаму працоўны тунэль усё яшчэ не мае шляху вонкі

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

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

Таму правярайце тры ўзроўні, а не кліент, і змяняйце па адным, каб вынік нешта значыў.

Перадача — гэта перамыкач ядра, які трэба замацаваць

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

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

Зрабіце яго пастаянным у файле ў /etc/sysctl.d/, затым прымяніце гэты файл, а не перазагружайцеся, каб даведацца вынік. У FreeBSD эквівалент — net.inet.ip.forwarding, а для захавання — gateway_enable=YES у rc.conf. Прылада, якая паведамляе, што перадача выключана, тлумачыць цэлы клас скаргаў «пакеты прыходзяць, а назад нічога не вяртаецца». Правярайце наладу і пасля кожнага абнаўлення, бо перасабранае ядро ці заменены вобраз прылады могуць скінуць яе без папярэджання.

Выберыце masquerade або адзін фіксаваны адрас трансляцыі

Пры дынамічным знешнім адрасе masquerading — самая простая правільная форма. Назавіце крыніцай падсетку тунэля, а выхадам — знешні інтэрфейс.

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

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

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

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

Табліца фільтраў — трэцяя брама

Перадача і трансляцыя могуць быць абедзве правільнымі, пакуль пакет гіне ў табліцы фільтраў. ufw — часты вінаваты: яго палітыка перадачы пастаўляецца як DROP, і астатняя налада можа выглядаць цалкам правільнай, пакуль гэта адна налада забівае трафік. Падняць яе — гэта свядомае рашэнне па бяспецы, а не птушка ў квадраціку.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

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

Дзе шукаць, калі старонка ніколі не загружаецца

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

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

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

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

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

Падобныя артыкулы