Повезани на OpenVPN, али ништа се не учитава: пут од клијента ка споља

Прозор клијента каже Connected, адреса тунела је ту, а прегледач се и даље врти. Та комбинација је нормална, јер успешно руковање доказује само да је тунел изграђен; оно не говори ништа о томе да ли ће сервер проследити ваше пакете, преписати њихов извор или одговорити на ваше DNS упите. Грешка коју већина прави је да прво отвори конфигурацију сервера. Уместо тога радите од клијента ка споља, јер сваки корак испод каже да ли следећи уопште вреди проверити.

Почните на клијенту и идите ка споља

Урадите три теста у овом редоследу и запишите где први пада. Пингујте адресу тунела на серверу, што доказује да сам тунел преноси саобраћај. Пингујте јавну адресу по броју, што доказује прослеђивање и превођење без укључивања разрешавања имена. Затим покушајте да разрешите име домаћина, што је једини тест који користи 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 је други неуспех иза првог

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

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

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 за уређај тунела пре него што закључите да је слање игнорисано.

Завршите пут онако како га корисник доживљава. Учитајте праву страницу са клијента, потврдите адресу са које излази, рестартујте сервер, поново се повежите и поновите три теста. Само тај други круг доказује да су сачувана правила, политика заштитног зида и послати резолвер сви заједно преживели.