Свързахте се с 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 за устройството на тунела, преди да заключите, че раздаването е пренебрегнато.

Завършете обхождането така, както го преживява потребителят. Заредете истинска страница от клиента, потвърдете адреса, от който излиза, рестартирайте сървъра, свържете се отново и повторете трите теста. Само този втори проход доказва, че запазените правила, политиката на защитната стена и раздаденият резолвер са оцелели заедно.