Маршрутизатор у режимі клієнта 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. Усі три — це конфігурація, яку наступне оновлення може перезаписати, і два рядки нотаток економлять годину, яку ви щойно витратили.