Падключыліся да OpenVPN, але нічога не адкрываецца: праходжанне з боку кліента

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

Пачніце з кліента і ідзіце вонкі

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

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

Два перахопы паказваюць, дзе спыняюцца пакеты

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

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

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

ip -4 route get 9.9.9.9

Поле dev у гэтым вывадзе — гэта назва, якая спатрэбіцца правілу NAT пазней, таму захавайце яе.

Перасылка — гэта перамыкач у ядры і палітыка міжсеткавага экрана

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

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Перасылка — гэта толькі палова. На хосте з UFW палітыка перасылкі задаецца ў /etc/default/ufw і павінна быць ACCEPT, перш чым перазагрузка набудзе моц. Правіла скіду па змаўчанні на шляху перасылкі пакідае рукапоцісканне цалкам здаровым, але моўчкі адкідае кожны пакет, які спрабуе выйсці праз тунэль, — гэта менавіта той сімптом, з якога вы пачалі.

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

Назавіце сапраўдны інтэрфейс выхаду ў правіле NAT

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

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Класічная няўдача — правіла, скапіяванае з дапаможніка, дзе сказана -o eth0 на машыне, чый адаптар называецца інакш. Правіла ўсталёўваецца без папярэджання, ні з чым не супадае, і кліент па-ранейшаму без інтэрнэту. Пул — другая палова той жа памылкі: калі сервер выдае 10.44.0.0/24, а правіла пакрывае 10.8.0.0/24, нішто ніколі не супадзе.

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

iptables -t nat -L POSTROUTING -v -n

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

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

DNS — другая няўдача за першай

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

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

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Кліенты Windows могуць потым усё роўна вярнуцца да лакальнага распазнавальніка, і менавіта гэтаму перашкаджае block-outside-dns, але цаной страты імёнаў, якія можа развязаць толькі лакальная сетка. Кліенты Linux з systemd-resolved часта ігнаруюць выдадзены распазнавальнік, пакуль скрыпт яго не ўсталюе, таму праверце resolvectl status для прылады тунэля, перш чым рабіць выснову, што выдачу праігнаравалі.

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