Ця адреса L2TP — це IPCP, а не оренда DHCP у локальній мережі

Внутрішня адреса надходить із переговорів PPP, а не від DHCP-сервера офісу. Подивіться, який етап її призначає, чому локальна мережа не може відповісти і що перевіряти.

З’єднання піднімається, і адаптер показує адресу з діапазону офісу, тож природний висновок — VPN дав вам адресу локальної мережі й тим самим помістив вас у неї. Жодна з цих двох половин не є цілком правильною. L2TP несе сеанс PPP, а PPP узгоджує внутрішню адресу IPv4 за допомогою IPCP. Ця адреса — параметр сеансу, узгоджений двома сторонами, а не оренда, видана DHCP-сервером офісу, і володіння нею не робить вас сусідом на офісному кабелі.

Дві адреси в одному з’єднанні

У з’єднанні L2TP є два незалежні переговори. Зовнішній прокладає захищений шлях між вашим пристроєм і кінцевою точкою VPN будь-якою мережею, яка у вас уже є. Внутрішній — це сеанс PPP, і саме там узгоджуються адреса вашого сеансу й адреса іншої сторони. Інтернет-трафік може виходити зовсім під третьою адресою — публічною адресою кінцевої точки, тому сторінка перевірки VPN і адреса адаптера рідко збігаються.

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

Що саме робить IPCP

IPCP — це протокол керування IPv4 для PPP. Кожна сторона надсилає повідомлення Configure-Request з описом потрібних опцій, і опція адреси є однією з них. Клієнт, який ще не має адреси, зазвичай запитує з 0.0.0.0, а сервер відповідає повідомленням Configure-Nak, що несе адресу, яку він хоче надати клієнтові. Далі клієнт запитує цю адресу, і сеанс піднімається з локальною та віддаленою адресою.

Цей обмін описано в специфікаціях PPP та IPCP, і він пояснює деталь, що виглядає як помилка: адресу обирає сервер за власною політикою, яка може бути пулом, налаштуванням для окремого користувача або адресою, прив’язаною до автентифікованої особи. Коли пул вичерпано або політика суперечить запиту, автентифікація може пройти, а узгодження адреси — ні, і клієнт повідомляє про з’єднання, яке так і не стабілізується.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

Рядок журналу pppd із локальною та віддаленою адресою — це успішний кінець тих переговорів. Його відсутність поруч з успішною автентифікацією вказує на етап адреси, а не на облікові дані.

Чому локальна мережа не може вам відповісти

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

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

Спочатку перевірте сеанс, потім маршрут

Спочатку перевірте інтерфейс, потім маршрути, потім одне важливе призначення. Кожен крок має власний режим відмови, а перевірка всіх трьох одразу дає висновок, який ви потім не зможете захистити.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

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

Тримайте три етапи окремо

Автентифікація, узгодження адреси й пересилання відмовляють по-різному, і кожен має окремого відповідального. Облікові дані — проблема ідентичності, вичерпання IPCP — проблема політики сервера, а відсутній зворотний маршрут — проблема проєктування мережі. Повідомляти про всі три як «VPN зламана» гарантує повільне виправлення.

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

Схожі статті