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

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

На серверу, посматрајте спољни интерфејс док клијент учитава страницу. Саобраћај који излази са приватним изворном адресом значи да недостаје превод, а потпуно одсуство одговора значи да га пут прослеђивања или узводни повратни пут одбацује.

Ако удаљени клијенти треба да достигну и домаћине на LAN-у сервера, запамтите да LAN-у треба повратни пут до подмреже тунела. То је рутирање, а не превод, и то је корак који се најчешће заборавља када интернет пут коначно проради.

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