Повезано, икона у траци је зелена, а страница која приказује адресу и даље приказује адресу провајдера — то још не значи квар. Клијент обавља два одвојена посла: гради тунел и уређује табелу рутирања. Било који може постојати без оног другог, а селективно рутирање је конфигурација у којој се други намерно прескаче.

Шта је клијент заиста инсталирао

Питајте које би сучеље однело пакет до стварног одредишта, уместо да питате да ли је тунел подигнут. Тунел без руте за то одредиште је приватни пут којим нико не иде.

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

Када провера падне унутар тунела, а одјек и даље пријављује адресу провајдера, превода на излазу нема. Када провера падне на физички адаптер, профил је селективан и јавна адреса никада није била у обухвату. Замените услугу одјека оном којој верујете и забележите четири запажања заједно, јер су одвојено само анегдоте. Заједно показују који је од два посла клијент стварно обавио.

Повезани чланци