VPN увімкнено, а localhost не працює: ім'я, проксі чи прив'язка?
Localhost перестає означати вашу машину, коли керування бере суфікс пошуку або проксі. Спочатку виправте ім'я, потім маршрут, потім рядок підключення інструмента.
Ваш сервер розробки відповів хвилину тому, а тепер, коли тунель піднято, запит завершується за тайм-аутом з ім'ям хоста, яке ви ніколи не вводили. Майже всі випадки пояснюють два механізми, і ззовні вони виглядають однаково. Суфікс пошуку перетворює коротке ім'я на корпоративне, а проксі надсилає loopback-трафік на хост, який не може до нього дістатися. Розділити ці два коштує одного запиту й економить правило міжмережевого екрана, яке ви збиралися написати.
Коли localhost розв'язується в корпоративну зону
Перевірте, у що розв'язується ім'я, поки тунель піднято, потім виконайте той самий запит з опущеним тунелем і порівняйте дві відповіді. Ознака — адреса в корпоративному діапазоні там, де ви очікували 127.0.0.1. Запис на кшталт localhost.mycompany.corp перемагає запис loopback, щойно клієнт додає цей суфікс до списку пошуку, і запит вирушає на приватний хост, де на цьому порту ніщо не слухає. Читайте список пошуку, а не вгадуйте його, бо клієнт може додати більше одного домену, і порядок вирішує, який кандидат перевіряється першим:
getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080
Замініть ім'я хоста буквальною адресою в застосунку, клієнті бази даних або URL блокнота, потім повторіть запит. Якщо збій зникає, у вас була проблема з іменуванням, а тунель був лише спусковим гачком. Якщо він залишається, наступний підозрюваний — слухач або маршрут, а ім'я було лише хибним слідом.
Налаштування проксі, які перехоплюють loopback
Системний проксі, застосований під час підняття тунелю, прийме запит до 127.0.0.1 і передасть його віддаленому проксі, який гадки не має, що ви мали на увазі. Порожній список винятків перетворює локальний запит на віддалений, і повідомлення про помилку рідко це каже. Додайте loopback-адреси до списку винятків на всю сесію, а не на одну команду, потім підтвердьте, що інструмент це поважає, перш ніж робити висновки про мережу.
Фреймворки застосунків читають власні змінні середовища, а іноді й власний файл конфігурації, тож виняток, що працює для одного інструмента, нічого не доводить для наступного. Браузери додають нюанс: браузери на Chromium неявно обходять проксі для loopback, і токен винятку може прибрати цю поведінку. Перевіряйте фактичне рішення проксі, а не припускайте, що налаштування операційної системи — це вся історія. Дві команди вирішують це для всього, що запускається з оболонки:
curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool
Адреса прив'язки вирішує, хто може підключитися
Сервер, запущений на 127.0.0.1, приймає підключення лише з цієї машини, що зазвичай і є правильним типовим вибором для розробки. Сервер на 0.0.0.0 відповідає на кожному інтерфейсі, включно з адаптером VPN, а це більше відкритості, ніж мають на увазі більшість людей. Коли буквальна loopback-адреса не працює, спершу перевірте прив'язку.
Подивіться на сокет, що слухає, і запишіть адресу, до якої він прив'язаний, а не лише порт. Якщо інший пристрій або контейнер має дістатися сервісу через тунель, прив'яжіть його до конкретного інтерфейсу, який він використовуватиме, і свідомо дозвольте цей порт. Якщо він потрібен лише вашій машині, залиште вузьку прив'язку і виправте клієнт, а не розширюйте сервер. Проброс портів або шар тунелів може з'єднати обидва, але кожен додає компонент, якому згодом знадобиться власне налагодження.
Де інструмент налагодження очікує LAN
Інструменти налагодження несуть припущення, які тунель тихо ламає. Міст налагодження телефона втрачає пристрій, коли VPN захоплює підмережу пристрою, тож повторне підключення через LAN-адресу або кабель уникає конфлікту. Центр автоматизації браузера вичерпує час, коли центр доступний лише через проксі або коли локальний міжмережевий екран скидає його порт керування. Віддалений налагоджувач може вимагати підвищення прав і loopback-адресу там, де клієнт переписав маршрут.
Визначте порт керування й порт даних окремо, бо часто один виживає, а інший ні. Потім вирішіть, чи виправлення належить до конфігурації інструмента, до маршруту для цієї підмережі чи правила роздільного тунелювання. Редагування файлу hosts на кожній машині розробника масштабується найгірше і забувається першим. Віддайте перевагу налаштуванню, яке живе з профілем і яке може переглянути кожен, кому належить тунель.
Зупиніться на першому збійному етапі
Пройдіть три етапи: розв'яжіть ім'я, відкрийте сокет до буквальної адреси, потім дайте інструменту встановити власне з'єднання. Кожен етап усуває один шар, тож перший збій називає шар, який треба виправити, а все після нього залишається неперевіреним. Запишіть результат, перш ніж щось змінювати, бо виправлення, застосоване до вимірювання, не відрізнити від удачі. Якщо перша спроба не вдалася, а повторна працює, тунель, імовірно, не був готовий, коли інструмент запускався.
Замініть фіксовану паузу обмеженою перевіркою готовності, яка чекає на маршрут, і залиште збійний етап у журналі, щоб наступна людина бачила, де все зупинилося. Інструмент, який відновлюється сам, не виправлено, йому просто пощастило, а удача закінчується на чужій машині. Змінюйте тунель останнім і лише для етапу, який справді збійнув. Цей порядок — ще й найкоротший шлях назад до робочої збірки, бо не дає переробляти компонент, який ніколи не брав участі.