VPN на рутерот работи, но LAN клиентите немаат интернет

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

Прочитајте го дефектот од LAN домаќин

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

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

Локалниот и проследениот сообраќај се различни

Linux и повеќето фармвери за рутери ги третираат пакетите создадени од кутијата поинаку од пакетите што минуваат низ неа. Излезниот синџир го гледа првиот вид, синџирот за проследување го гледа вториот, и политиката прилагодена на сообраќајот на самиот рутер може да го остави проследувањето недопрено.

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'

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

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

Преводот на изворот одлучува дали е потребна повратна патека. Со маскарада на интерфејсот за тунел, одговорите се враќаат на адресата на тунелот и рутерот ги преведува назад. Без неа, далечната порта бара експлицитна рута до подмрежата на клиентот, и нејзината сопствена политика мора да го дозволи тој правец.

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

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

Проверете еден дозволен и еден забранет тек

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

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

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

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