mitmproxy, DevTools, Gradle: три шари за VPN
Loopback ніколи не потрапляє в тунель. Віднесіть симптом до слухача, сховища довіри або пакетного фільтра і виправте той шар, який справді відмовив.
VPN підключається, і три не пов'язані інструменти відмовляють трьома різними способами того самого дня. mitmproxy перестає бачити запити, Chrome відмовляє налагоджувачу, а Gradle кидає BindException під час прив'язки локального сокета. Спільний підозр — тунель блокує localhost. Він не може: 127.0.0.1 обробляється всередині ядра і ніколи не доходить до адаптера, а не те що до шлюзу.
Три шари, три різні поломки
З клієнтом змінився не маршрут до loopback. Це локальний проксі, сховище довіри машини і пакетний фільтр, і кожен із них ламає іншу частину робочого процесу розробника. Віднести симптом до правильного рядка — це більша частина діагностики:
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
Майже кожен звіт такого типу починається з останнього рядка і йде вгору, що неправильно. Тунель — єдиний шар, який доведено не бачить трафік loopback, тому він заслуговує найменшої підозри. Почніть з того, що прив'язав процес, потім запитайте, яким сертифікатам він довіряє, і лише після цього подивіться на політику на машині.
Почніть зі слухача, а не з тунелю
Коли проксі на 127.0.0.1:8080 перестає отримувати трафік, сталося одне з трьох: він не запустився, прив'язав інший порт, або фільтр скинув з'єднання loopback. Перелік слухаючих сокетів відповідає на це однією командою і показує, який процес володіє портом, коли два інструменти розходяться в тому, хто був першим.
Локальна адреса в пошуку маршруту підтверджує те саме з іншого боку. ip route get до цілі loopback повідомляє пристрій loopback, ніколи не тунель, і це корисна фраза напоготові, коли хтось пропонує зміну маршрутизації як рішення.
Шар проксі: середовище — це не конфігурація
Багато корпоративних клієнтів запускають HTTP-проксі і очікують, що застосунки ним користуватимуться. Встановлення HTTPS_PROXY в оболонці виправляє інструменти командного рядка, які його поважають, і нічого не робить для інструмента, який читає власний файл налаштувань. Gradle, Selenium і gRPC кожен звертається до своєї конфігурації, а проксі, експортований в одному терміналі, невидимий для демона, запущеного IDE.
Інструменти контейнерів — звичайне місце, де це стає помітним. Loopback контейнера — його власний, тому 127.0.0.1 всередині контейнера ніколи не означає проксі хоста; потрібна адреса хоста або налаштування мережі хоста. Виправлення, яке працює в оболонці і падає під час збірки, зазвичай і є цим рядком, а не тунель.
Шар довіри: інструмент читає інше сховище
Перехоплення — друга зміна, і воно дає найбільш оманливі помилки. Клієнт пред'являє власний сертифікат для перевірюваних з'єднань, тому браузер, який довіряє корпоративному кореню, досягає успіху, а інструмент із вбудованим сховищем CA зазнає невдачі. requests Python через certifi — класичний випадок: сховище операційної системи може бути правильним, і запит усе одно падає, бо це середовище виконання ніколи його не читає. Текст помилки рідко згадує перехоплення, тому цей рядок помилково діагностують як зламану кінцеву точку.
Порівняйте, що кінцева точка насправді пред'являє, з тим, що інструмент перевірив. openssl s_client показує ланцюжок, надісланий сервером; власний вивід перевірки інструмента показує, що він вирішив. Коли вони не збігаються, REQUESTS_CA_BUNDLE або SSL_CERT_FILE є важелем для цього середовища виконання, і корпоративний корінь належить до сховища, яке читає це середовище, а не до глобального місця, яке поважають лише деякі інструменти.
Зміна версії, що виправляє помилку SSL, — це доказ про політику довіри й шифрування, а не про VPN. Пониження версії Python, після якого запрацював клієнт SOAP, змінило вбудоване сховище CA і типові налаштування TLS; мережевий шлях не зрушив.
Шар фільтра: він теж може скинути loopback
Третя зміна — пакетний фільтр, і деякі продукти встановлюють правила, що скидають трафік, який не потрапляє в тунель. Локальні слухачі можуть бути включені. Це перетворює робочий сокет на відхилене або прострочене з'єднання, і отримана помилка виглядає як дефект застосунку, а не як політика машини.
Володіння портом — друга половина цього шару. BindException означає, що сокет не вдалося відкрити, а це інша відмова, ніж відхилене з'єднання. Перевірте, чи не тримає порт уже інший процес, перш ніж звинувачувати фільтр, потім пошукайте правило, що скидає локальний трафік, і додайте найвужчий дозвіл, який підтримує продукт. Два інструменти, що змагаються за той самий порт налагодження, дають точно те саме повідомлення, що й блокування політикою, і лише один із них виправляється зміною брандмауера.
Порт налагодження Chrome падає в тій самій родині. Браузер запускається, драйвер не досягає кінцевої точки DevTools, і повідомлення називає DevTools, а не мережу. Додаткові прапорці запуску й зайвий менеджер драйверів змінюють те, який процес володіє портом, тому їхнє видалення іноді виглядає як виправлення VPN.
Виправте шар, який відмовив
Виправте шар, який відмовив, а не тунель. Недоступному слухачу loopback потрібно виправити слухач або порт. Недовіреному сертифікату потрібен корпоративний корінь, встановлений там, де дивиться саме це середовище виконання, з вузьким винятком. Фільтру, що скидає локальний трафік, потрібне конкретне правило дозволу, а не вимкнений фільтр, бо вимкнення знову відкриває й усе інше, що він захищав.
Повторне підключення VPN не перевіряє жодного з цих шарів. Воно лише повторно виконує зміну, яка їх зламала, тому ті самі три відмови повертаються після кожного перепідключення і зникають після кожного перезавантаження, що залишає клієнт неактивним.