VPN клиентите се свързват, но няма интернет: три липсващи части

Клиентът получава адрес, сървърът отговаря на 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

Първата команда доказва, че тунелът носи трафик до самия сървър, а втората показва колко далеч стига пакетът навън. Следа, която завършва на адреса на тунела, сочи към препращане или транслация на сървъра, докато следа, която спира една стъпка по-късно, сочи към доставчика или обратния път на горния рутер.

На сървъра наблюдавайте външния интерфейс, докато клиент зарежда страница. Трафик, който излиза с частен адрес на източника, означава, че липсва транслация, а пълната липса на отговор означава, че пътят за препращане или горният обратен маршрут го изпуска.

Ако отдалечените клиенти трябва да достигат и хостове в локалната мрежа на сървъра, помнете, че локалната мрежа се нуждае от обратен маршрут към подмрежата на тунела. Това е маршрутизация, а не транслация, и това е стъпката, която най-често се забравя, след като интернет пътят най-накрая проработи.