Зялёная іконка, той жа публічны IP: які маршрут прапусціў VPN

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

Што кліент насамрэч усталяваў

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

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

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

Тры формы выбіральнай маршрутызацыі

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

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

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

Той бок павінен перапісаць адрас крыніцы

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

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

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

Развязанне імёнаў ідзе сваім шляхам

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

resolvectl status | head -20
resolvectl query example.org

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

Чатыры назіранні, якія ўсё вырашаюць

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

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

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