Рутер в клиентски режим на VPN: защо LAN устройствата изчезват

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

Митът и какво наистина променя клиентският режим

Клиентският режим добавя тунелен интерфейс и маршрут по подразбиране през него, след което препраща LAN трафика в този тунел. Мостът между кабелните портове и безжичните радиостанции остава непокътнат, както и локалното комутиране. Променя се политиката: кой трафик се препраща, къде се преобразува и кой резолвер получават клиентите.

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

Затова полезният първи ход е да намерите кой слой се е счупил, а не да променяте слоя, който подозирате.

Проверете три цели, преди да пипате настройка

От кабелен клиент проверете три цели поотделно и запишете всеки резултат: собствения LAN адрес на рутера, друго устройство на същия комутатор по IP и нещо, достъпно само през тунела. Правете ги в този ред, защото всеки резултат изключва различен слой. Използвайте адреси, а не имена за първия преглед, тъй като неуспехът на име смесва DNS във въпрос за свързаност.

Моделът на отговорите е диагнозата. Рутер, който отговаря, докато локалните устройства не отговарят, сочи към локално комутиране или функция за филтриране, а не към маршрутизиране. Локални устройства, които отговарят, докато страната на тунела не отговаря, сочат към тунелния маршрут или отдалечената защитна стена. Всичко, което отговаря по адрес, докато имената се провалят, е въпрос на резолвер и никакво редактиране на маршрути няма да го поправи.

Дръжте таблицата до резултатите от тестовете. Тя превръща неясното оплакване в един ред, по който можете да действате.

Защитният слой вътре в пътя за препращане

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

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

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

Втората причина: LAN диапазонът се премести

Актуализациите на фърмуера редовно връщат LAN адреса към фабричната стойност на производителя, а някои рутери имат явен превключвател на режима, който решава дали LAN запазва частен диапазон, или наследява такъв от устройството нагоре. Клиент, който очаква 192.168.8.x, може да се окаже на 10.64.0.x, и тогава SSH сесия към хост изтича, въпреки че тунелът е напълно здрав.

ipconfig /all
ip addr show
ip route get 192.168.8.20

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

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

Свържете отново и тествайте отново по реда на пакетите

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

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