Проксі досі на старій адресі тунелю після перепідключення VPN?

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

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

Почніть зі слухача, а не з тунелю

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

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

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

Чотири перевірки, перш ніж щось змінювати

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

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

Адреса пристрою проста: ip -4 addr show dev tun0 виводить поточну, а ip -4 route get 1.1.1.1 показує, який інтерфейс ядро вибрало б для цього призначення. Пересилач, прив'язаний до точної адреси, гучно падає, коли адреса зникає. Пересилач, прив'язаний до пристрою або відкочується до джерела за замовчуванням, продовжує працювати і тече, і це тихий результат.

Узгодьте документацію з тією версією, яку ви запускаєте, а не з першим результатом пошуку. Директива вихідної адреси Squid документована для v7 і раніших, а документація v8 прямо каже, що там директива недоступна, тож скрипт, побудований навколо неї, не переживає цієї межі (дивіться довідку Squid tcp_outgoing_address). Перевірте власним аналізатором продукту, перш ніж щось перезавантажувати: squid -k parse повідомляє про помилки і завершується, не торкаючись робочого процесу.

Пронумеруйте кожен тунель і відкидайте застарілі заміни

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

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

Відкриті сокети не підуть за новою адресою

Переконфігурація пересилача нічого не каже про вже встановлені з'єднання. Чи вони вичерпаються, чи помруть — залежить від продукту, тож спостерігайте поведінку, а не припускайте.

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

Доведіть новий вихід свіжим запитом

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

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

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

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