VPN на рутеру ради, али LAN клијенти немају интернет

Рутер стиже на интернет кроз свој тунел, док уређаји иза њега не. Прослеђивање, превођење и повратне руте су одвојене дозволе.

Статус каже да је тунел активан, прегледач на самом рутеру учитава странице, а сваки уређај иза њега и даље истиче. Та комбинација сужава проблем на слој који већина VPN водича никада не спомиње: рутер није једини хост чији пакети морају да преживе тунел. Локално генерисан саобраћај и прослеђени саобраћај иду различитим путевима кроз исту кутију. Тестирајте са клијента и разлика престаје да буде теоријска.

Прочитајте квар са LAN хоста

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

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

Локални и прослеђени саобраћај се разликују

Linux и већина фирмвера рутера третирају пакете настале у кутији другачије од пакета који кроз њу пролазе. Output ланац види прву врсту, forward ланац види другу, а политика прилагођена саобраћају самог рутера може оставити прослеђивање нетакнутим.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Проверите да ли је прослеђивање уопште омогућено, па читајте forward ланац уместо output ланца. Правило које дозвољава шифровану спољну везу није правило које дозвољава прослеђивање дешифрованих пакета, а мешање та два производи тачно овај симптом. Активан тунел доказује само прво.

Повратни пут такође мора да постоји

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

Забележите који од два нацрта примењује постављање пре него што било шта промените, јер поправке воде у супротним смеровима. Додавање превођења крије повратну руту која недостаје и квари апликације којима је потребна оригинална изворна адреса. Додавање повратне руте без превођења тихо не успева када удаљени заштитни зид одбаци непознат извор. Изаберите један, документујте га и ускладите другу страну.

DNS клијента припада истом прегледу. Рутеров резолвер може да одговори док клијент усмерен на други сервер не добија ништа.

Проверите један дозвољен и један забрањен ток

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

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

Држите правила ограничена на клијентске мреже којима је потребан тунел и одуприте се искушењу да искључите филтер прослеђивања да би један тест прошао. Та промена поправља тест и уклања границу коју је тунел требало да обезбеди. Запишите изворну адресу, одлуку о превођењу и повратну руту у једну белешку, са датумом.

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