У Windows встановлено VPN, Linux завантажується без мережі: що перевірити

Ви встановлюєте VPN у Windows, перезавантажуєтеся в Linux, і дротове з'єднання мертве. Очевидна історія пишеться сама собою: VPN щось залишив по собі. Історія хибна, бо два завантаження запускають окремі ядра з окремими драйверами, окремими таблицями маршрутизації та окремими резолверами. Мережевий фільтр Windows не виконується всередині Linux, тому несправність або в стеку Linux, або в тому, що обидва завантаження справді поділяють, наприклад в обладнанні, прошивці чи маршрутизаторі.

Симптом і хибний висновок

Корисна частина спостереження — час: несправність з'явилася після зміни. Некорисна частина — причинний стрибок до VPN у Windows, який не може працювати в іншій операційній системі. Розділення цих двох і є вся робота. Запишіть хронологію, перш ніж торкатися кабелю.

Спільне для обох завантажень — фізичний адаптер, кабель, порт комутатора і все, що вище. Це справжні спільні змінні, і вони заслуговують перевірки після огляду стеку Linux.

Зафіксуйте стек Linux чотирма командами

Почніть у режимі лише читання і зафіксуйте стан, перш ніж щось змінювати: ip -br link для наявності інтерфейсів, ip -br address для адрес, ip route для маршрутів IPv4 і ip -6 route там, де важливий IPv6. Довідник утиліти ip розрізняє ці об'єкти, а поява інтерфейсу в списку не доводить, що він має робочу адресу або придатний маршрут.

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

Це канал, адреса, маршрут чи ім'я?

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

Кожен випадок указує на іншу роботу: драйвер або прошивка для відсутнього пристрою, кабелі або комутатор за відсутності носія, DHCP або статична конфігурація для відсутньої адреси та маршрутизація чи політика для відсутнього шляху. Проблема резолвера вказує на systemd-resolved, NetworkManager або локальну конфігурацію DNS.

Перевірте, чи має інсталяція Linux власний VPN або постійну конфігурацію брандмауера. Локальний тунель або набір правил nftables — причина з боку Linux, і вона значно ймовірніше пояснює несправність, ніж програма Windows, яка не працює.

Потім порівняйте перехід між завантаженнями

Windows Fast Startup — це гібридне вимкнення, яке зберігає стан сеансу ядра замість повного завантаження. Документація Microsoft про стани живлення відрізняє його від перезавантаження та від повного вимкнення, тому те саме обладнання може поводитися по-різному в двох переходах.

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

Запишіть, яка операційна система останньою використовувала адаптер, тип переходу, стан каналу в Linux і першу невдалу операцію. Відтворювана різниця між холодним завантаженням і теплим переходом варта значно більше, ніж видалення VPN-програми з обох інсталяцій без розуміння, який стек зламався.

Що не змінювати

Не скидайте обидва мережеві стеки першим кроком. Це руйнує порівняння і часто нічого не виправляє, бо справжню причину так і не було встановлено. Не перевстановлюйте VPN у Windows, щоб полагодити Linux, і не змінюйте налаштування прошивки навмання лише тому, що перехід під час завантаження корелював з несправністю.

Довідник утиліти ip описує використані вище об'єкти каналу, адреси та маршруту. Спершу прочитайте бік Linux, збережіть знімок і лише потім вирішуйте, чи варто досліджувати спільний шар обладнання.