Новий клієнт хотспота, що завис на отриманні IP, — не збій VPN

Телефон підключається до хотспота, залишається на «Отримання IP-адреси» і зрештою здається. Природний висновок — що VPN телефона заважає DNS, і люди починають правити резолвери та додані правила. Це не той етап. Клієнт так і не отримав локальну адресу, а без неї в нього немає ні шлюзу, ні резолвера, ні чого пересилати далі, тож жодне налаштування VPN на телефоні-хості не пояснює збій. Підключення, призначення локальної адреси й подальше пересилання — три окремі етапи, і лише останній стосується тунелю.

Три етапи і на якому ви

Спершу йде підключення: клієнт приєднується до бездротової мережі хотспота. Неправильний пароль, невідповідність WPA3 або проблема сумісності радіо зазнають невдачі тут, і клієнт зазвичай так і каже. Другий — призначення адреси: для IPv4 клієнт запитує оренду й отримує адресу плюс локальні налаштування шлюзу, тоді як IPv6 зазвичай використовує оголошення маршрутизатора замість DHCP, як описує документація AOSP щодо tethering. Третій — подальший доступ: телефон-хост пересилає дозволений трафік на обраний ним шлях угору, який може бути його тунелем, а може й не бути.

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

Міф: маршрутизований VPN перетворює локальний DHCP на віддалений запит

Маршрутизований тунель переносить IP-пакети для тих призначень, які він обирає. Виявлення DHCP — це широкомовний запит у власному сегменті хотспота, і служба tethering на телефоні відповідає на нього локально, тому клієнт може отримати адресу, поки тунель піднятий. Лише навмисно мостове або ретрансляційне рішення надсилає цей обмін кудись інде, і це інша схема з іншим підписом збою.

Тож «сервер VPN не відповідає на DHCP» — не діагноз, а помилка моделі. Локальний посередник розташований на телефоні. Якщо він перестає відповідати, причини локальні: служба tethering, ліміт клієнтів, пул оренди або клієнт, який так і не завершив підключення як слід. Ніщо з цього не живе на дальньому боці тунелю.

Що насправді доводить робочий наявний клієнт

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

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

Тримайте порівняння локальним і оборотним

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

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

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

Чого оренда не доводить

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

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