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

Проверете наблюдавания адрес на източника в далечния край, защото той показва кой дизайн всъщност работи. Проверете и търсене на име, както и адрес, защото поведението на резолвера е отделен път през същата кутия.

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

Подобни статии