Firefox, запущений у namespace, передав URL наявному екземпляру

Команда виконується всередині namespace VPN, з’являється вікно Firefox, але сторінка все одно виходить через звичайне з’єднання. Налаштування маршрутизації, ймовірно, не перше, що потрібно перебудовувати. Перевірте, чи команда створила очікуваний екземпляр браузера чи передала URL тому, який уже працював деінде. Ця різниця пояснює результат за один крок і економить годину роботи з nftables.

Ознака в тому, що вікно з’являється миттєво, без холодного запуску.

Нове вікно — не новий екземпляр

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

Приватний перегляд і опція нового вікна не є засобами ізоляції мережі.

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

Примусово створіть окремий екземпляр у окремому профілі

Використовуйте виділений профіль, створений через підтримуваний робочий процес профілів браузера, і запускайте його явно з цим профілем. У збірках Firefox, які це підтримують, --new-instance запитує новий екземпляр, а не вікно всередині наявного. Перегляньте власний вивід довідки встановленої збірки, бо доступні прапорці різняться залежно від версії.

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

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

Перевірте, який процес несе трафік

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

readlink /proc/ACTUAL_PID/ns/net

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

Коли namespace справді неправильний

Іноді запускач справді зазнає невдачі, і новий екземпляр стартує в неправильному namespace. Перевірте службу або обгортку, яка його створила, бо unit або запис робочого столу може втратити namespace, коли його повторно виконують через шину сеансу. Потім перевірте знову з оболонки всередині правильного namespace, перш ніж звинувачувати браузер. Одна змінна за раз — єдиний спосіб зберегти це діагностичним.

Спільний доступ до екрана не ділить і resolver.

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