Жоден маршрут не виправить пул VPN, що перекривається з вашою LAN

Коли пул тунелю й домашня LAN ділять 192.168.1.0/24, перемагає локальна підмережа. Перенумеруйте бік, яким керуєте, або перекладіть віддалений діапазон.

Застосунок стверджує, що тунель здоровий, і все ж половина потрібних адресатів ніколи не відповідає. Перший рефлекс — додати маршрут або знизити метрику, і саме цей рефлекс і є міф, який варто вбити першим. Коли власна LAN клієнта й пул тунелю претендують на той самий префікс, таблиця маршрутизації тримає два несумісні факти, і ні маршрут за замовчуванням, ні метрика їх не розв'язують. Виправлення — це рішення про адресацію, і жодне редагування маршрутів його не замінює.

Чому додатковий маршрут не може розділити один префікс

Маршрут не може розвести дві заявки на один префікс, тому розумний крок — перестати шукати правильний рядок маршруту. Стек не поставить ідентичний префікс перед підключеним маршрутом, а конкретніший запис перехоплює адресу, але робить локальний хост, якому вона належить, недосяжним. Те, що виглядає як проблема маршрутизації, є конфліктом адресації, і обидва виправлення змінюють адреси, а не маршрути. Перевірте це твердження на своїй машині, перш ніж його прийняти.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Запитайте систему про одну адресу й зауважте, який інтерфейс вона називає. Linux, macOS і Windows відповідають пошуком лише для читання, який повідомляє вибраний інтерфейс і наступний стрибок, нічого не передаючи. Коли відповідь указує на фізичний адаптер, поки тунель піднятий, ядро вважає адресу такою, що на каналі, а не тим, що тунель міг би нести.

Поставте префікс, наданий провайдером, поряд із тим, який обслуговує домашній маршрутизатор, і порівняйте їх як рядки. Точний збіг — очевидний випадок, а ширший пул провайдера, що містить домашню підмережу, збігається так само, лише його легше проґавити. Два префікси, які лише виглядають схоже, не є конфліктом, тож запишіть обидва, перш ніж щось змінювати.

Прочитайте пул, який клієнт справді отримав

Читайте те, що отримав клієнт, а не маркетингову сторінку провайдера. Підвищте докладність журналу клієнта OpenVPN, і маршрути, які проштовхує сервер, з'являться в ньому, розкриваючи префікси тунелю; в інших місцях пул видно в деталях з'єднання або на самому адаптері. Попросіть у провайдера повний список приватних діапазонів, які він використовує, бо одна /24 сьогодні може стати двома завтра. Уникати звичних блоків RFC 1918 — не те саме, що уникати виділення, яке вам справді дали.

Пул може й зменшитися, і переїхати між регіонами, тож списку потрібні дата й відповідальний. Будь-яку відповідь провайдера, старшу за вашу останню зміну плану, вважайте здогадом, а не фактом. Запитайте ще раз, перш ніж закріпитися за діапазоном, і зберігайте відповідь разом із мережевими нотатками, щоб наступна людина успадкувала доказ.

Перенумерація — це виправлення, яке ви можете зробити

Якщо сервер VPN не ваш, щоб його змінювати, перенесення домашньої LAN — єдине доступне виправлення, і це звичайна ситуація з комерційним провайдером. Виберіть діапазон поза пулом провайдера й поза діапазонами, які можуть знадобитися пізніше, і перевірте його проти кожного іншого місця, куди ви потрапляєте через тунель. Чекайте на коротку перерву й довший хвіст забутих пристроїв: пристрій, що досі має стару адресу, виглядає робочим, доки йому не знадобиться шлюз.

  1. Спершу інвентаризація: власна адреса маршрутизатора, область DHCP, резервування, переспрямування портів і кожен пристрій, адресу якого введено вручну.
  2. Потім змініть префікс LAN маршрутизатора й область DHCP разом у межах вікна обслуговування та оновіть дротові оренди раніше за бездротові.
  3. Далі виправте статичні адреси: принтери, мережеве сховище, усе з жорстко прописаним шлюзом.
  4. Нарешті, перепідключіть клієнт VPN і підтвердьте, що адреса тунелю більше не конфліктує з LAN.

Проходьте адреси в цьому порядку, а не всі одразу, і залиште старий діапазон на якийсь час задокументованим, щоб застарілий пристрій був упізнаваний, а не загадковий. Пристрій, що ніколи не поновлює оренду, виказує себе тим, що не доходить до шлюзу, і це значно краща підказка, ніж дзвінок у підтримку. Якщо маршрутизатор видає оренди довші за добу, скоротіть їх на час вікна.

Що може й чого не може псевдонім

Коли сервер ваш, трансляція адрес на клієнті може показати віддалений префікс усередині вільного локального діапазону, так що той самий хост відповідає за другою адресою. Громадський OpenVPN робить це за допомогою client-nat, і ця директива властива саме тому клієнтові, її немає в комерційних і мобільних клієнтах, з якими її зазвичай порівнюють. Схема потребує маршруту, що відповідає трансляції, вільного діапазону для псевдоніма й сервера, готового відповідати на нетрансльовану адресу клієнта. Ніщо з цього не допомагає, коли клієнт належить керованому провайдеру, якого ви не можете налаштувати.

Коли зміна набуде чинності, дістаньтеся локального й віддаленого хоста спершу за адресою, а потім за іменем, позначаючи маршрут, який система вибирає щоразу. Ім'я може ще розв'язуватися в старий діапазон, тож адреси й імена заслуговують на незалежні перевірки. Перезапустіть одного клієнта й один пристрій на боці сервера, якщо хтось із них стояв увесь час зміни, бо кешовані записи сусідів живуть довше за правку.

Запишіть префікси, на яких ви зупинилися, там, куди люди справді дивляться: у мережевих нотатках, у полі коментаря маршрутизатора, на сторінці знайомства. Хтось знову вибере 192.168.1.0/24, і конфлікт повернеться разом із ним.

Схожі статті