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

Ментальна модель: як Windows насправді обирає маршрут

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

1. Найдовший префікс: /32 перемагає /24, а /24 перемагає /0. Більш конкретні маршрути виграють.
2. Метрика маршруту: менша — перевага.
3. Метрика інтерфейсу: якщо кілька маршрутів рівні, метрика інтерфейсу може вирішити нічию.
4. Досяжність наступного хопа: якщо шлюз недосяжний, Windows може перейти до іншого маршруту (іноді після таймаутів, що здаються нескінченними).

Найпоширеніша помилка в багатомережевому середовищі банальна: хтось поставив дефолтний шлюз на двох адаптерах. Тепер є два маршрути 0.0.0.0/0, і Windows обирає один на основі метрик. Якщо ці метрики автоматичні, Windows може змінити рішення після зміни швидкості лінку, оновлень драйвера, VPN або випадкової зміни в налаштуваннях інтерфейсу. (Добре, можливо, не через космічну частинку. Ймовірно.)

Є й інший режим відмови, що виглядає як маршрутизація, але фактично це резолюція імен: Windows вибирає «неправильний» DNS-сервер для запиту, отримує внутрішню адресу, і маршрутизація робить саме те, що ви наказали. Ви годинами перевіряєте таблицю маршрутів, поки DNS-клієнт тихо псує вам день.

Що має означати «багатомережевий» у здоровому проєкті

Багатомережевий Windows-сервер працює нормально, коли кожен NIC має чітку задачу:

• Один інтерфейс має дефолтний шлюз для загального вихідного трафіку.
• Інші інтерфейси не мають дефолтного шлюзу і використовують конкретні статичні маршрути (або динамічну маршрутизацію, якщо у вас така організація).
• DNS налаштовано обдумано, а не копіюється між адаптерами як ритуал.
• Трафік перевіряють захопленням пакетів і реальними тестами додатків, а не відчуттями.

Якщо ваш дизайн відходить від цього, ви все ще можете змусити його працювати. Але ви платитимете «відсотки за складність» щоразу після Patch Tuesday.

Цитата, яку варто тримати поруч із runbook-ами: «Надія — це не стратегія.» — генерал Гордон Р. Салліван. Це не мережевий вислів, але точно підходить до операцій.

Жарт #1: Маршрутизація Windows не зачарована; вона просто робить саме те, що ви налаштували, і трохи підсуджує вас за це.

Швидкий план діагностики (перший/другий/третій)

Це потік «заходиш напівпритомний о 2:00 ранку». Ви не тут, щоб милуватися пакетами. Ви тут, щоб зупинити кровотечу.

Перше: підтвердіть неправильний шлях, не припускайте

• Перевірте активний маршрут до реального призначення (ваш DC, файловий сервер, моніторинговий кінцевий пункт).
• Підтвердіть, який інтерфейс використовується і який шлюз.
• Підтвердіть, чи це маршрутизація, чи DNS (куди резолвиться ім’я?).

Друге: знайдіть конкуренцію дефолтів і метрик

• Шукайте кілька маршрутів 0.0.0.0/0.
• Перевірте метрики інтерфейсів і чи вони автоматичні.
• Перевірте, чи VPN-клієнт не вставив маршрути або не змінив метрики.

Третє: застосуйте мінімальне безпечне виправлення

• Видаліть дефолтний шлюз з неосновних NIC.
• Встановіть явні метрики інтерфейсів (припиніть дозволяти «Automatic» приймати рішення політики).
• Додайте постійні маршрути для конкретних підмереж, що належать іншому NIC.
• Повторно перевірте шлях додатку, а не лише ping.

Якщо ви виконаєте ці три кроки, більшість інцидентів «Windows обрав неправильний NIC» завершаться швидко. Решта — це DNS, WFP/політика фаєрвола або віртуалізаційна дивина, про які ми розповімо нижче.

Цікаві факти та контекст (чому Windows поводиться так)

• Факт 1: Windows давно підтримує автоматичні метрики інтерфейсів; воно часто корелює «швидший лінк» з «кращим маршрутом», що не завжди відповідає вашим політикам маршрутизації.
• Факт 2: «Порядок зв’язування» був важливим у старіших стек-процесах Windows; сьогодні це має менше значення для чистої маршрутизації, але все ще впливає на деякі застарілі поведінки та преференції резолюції імен.
• Факт 3: Windows може підтримувати кілька дефолтних маршрутів; переможе той, у кого найнижча комбінована метрика, а не той, якого ви мали на увазі.
• Факт 4: VPN-клієнти часто додають маршрути і регулюють метрики, щоб примусити трафік через тунель. Дехто робить це ввічливо, а дехто — ні.
• Факт 5: SMB Multichannel існує і може використовувати кілька NIC одночасно, коли це налаштовано і мережа це підтримує. Це чудово — допоки ви випадково не змусите SMB іти через управлінський NIC з неправильним DNS.
• Факт 6: «Виявлення мертвого шлюзу» може змусити Windows переключитися з одного шлюзу після збоїв, що виглядає як випадкове флапання маршрутів, коли один шлях синхронно переривається.
• Факт 7: Hyper-V vSwitch та vEthernet-адаптери можуть додати додаткові інтерфейси, які конкурують за метрики та реєстрацію DNS, якщо залишити налаштування за замовчуванням.
• Факт 8: Рекомендації для iSCSI давно радять не ставити дефолтний шлюз на адаптерах зберігання і використовувати явні маршрути за потреби. Люди все ще ігнорують це, зазвичай прямо перед простоєм.
• Факт 9: В корпоративному Windows Group Policy та агенти кінцевих точок можуть змінювати налаштування фаєрволу та мережі після того, як ви «виправили» їх локально, тому стійкість означає розуміння площини управління.

Практичні завдання: команди, висновки та рішення (12+)

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

Завдання 1: Перерахуйте інтерфейси та подивіться, які підключені

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object -Property Status,LinkSpeed -Descending | Format-Table -Auto Name,Status,LinkSpeed,MacAddress"
Name                  Status LinkSpeed MacAddress
----                  ------ --------- ----------
Ethernet0             Up     1 Gbps    00-15-5D-01-02-03
Ethernet1             Up     10 Gbps   3C-EC-EF-10-20-30
vEthernet (Default)   Up     10 Gbps   00-15-5D-AA-BB-CC

Значення: У вас щонайменше три інтерфейси. Швидкість лінку може впливати на автоматичні метрики і ваші припущення щодо «переважних» шляхів.

Рішення: Визначте, який NIC має бути дефолтним (зазвичай управління), а які — спеціального призначення (зберігання, реплікація, кластер).

Завдання 2: Показати IP-конфігурацію, включаючи дефолтні шлюзи та DNS

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,Ipv4Address,Ipv4DefaultGateway,DnsServer"
InterfaceAlias     : Ethernet0
Ipv4Address        : 10.20.30.40
Ipv4DefaultGateway : 10.20.30.1
DnsServer          : {10.20.30.10, 10.20.30.11}

InterfaceAlias     : Ethernet1
Ipv4Address        : 172.16.50.40
Ipv4DefaultGateway : 172.16.50.1
DnsServer          : {172.16.50.10}

Значення: Два NIC мають дефолтні шлюзи. Це класичний генератор «неправильного маршруту».

Рішення: Якщо ви спеціально не прагнете поведінки на кшталт ECMP, видаліть дефолтний шлюз з неосновних NIC і замініть його специфічними маршрутами.

Завдання 3: Перевірити таблицю маршрутів на наявність конкурентних дефолтів

cr0x@server:~$ powershell -NoProfile -Command "route print -4"
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.20.30.1     10.20.30.40     25
          0.0.0.0          0.0.0.0      172.16.50.1    172.16.50.40      5
        10.20.30.0    255.255.255.0         On-link     10.20.30.40    281
       172.16.50.0    255.255.255.0         On-link    172.16.50.40    281
===========================================================================

Значення: Windows віддасть перевагу дефолтному маршруту 172.16.50.1, бо метрика 5 виграє проти 25. Це може бути ваша мережа зберігання, а не мережа для інтернету/управління.

Рішення: Виправте метрики або видаліть зайвий дефолтний шлюз. Не «надійтеся», що Windows обере інший.

Завдання 4: Запитайте Windows, який маршрут він би використовував для конкретного призначення

cr0x@server:~$ powershell -NoProfile -Command "Find-NetRoute -RemoteIPAddress 8.8.8.8 | Format-Table -Auto"
ifIndex DestinationPrefix NextHop       RouteMetric InterfaceMetric
------ ----------------- ------       ----------- ---------------
    12 0.0.0.0/0         172.16.50.1              5              5

Значення: Для цього призначення обраний наступний хоп на Ethernet1.

Рішення: Якщо Ethernet1 не призначений для загального виходу, припиніть його перемагати (видаліть шлюз або підвищте його метрику).

Завдання 5: Перевірити метрики інтерфейсів і чи вони автоматичні

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceMetric | Format-Table -Auto InterfaceAlias,InterfaceMetric,AutomaticMetric,ConnectionState"
InterfaceAlias        InterfaceMetric AutomaticMetric ConnectionState
--------------        -------------- --------------- ---------------
Ethernet1                          5            True Connected
Ethernet0                         25            True Connected

Значення: AutomaticMetric увімкнено; Windows сам підрахував ці метрики і вирішив, що Ethernet1 «кращий».

Рішення: Вимкніть автоматичні метрики і встановіть явні значення, які відображають ваші наміри (не швидкість лінку).

Завдання 6: Встановити явні метрики інтерфейсів (політика замість припущень)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetIPInterface -InterfaceAlias 'Ethernet0' -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 10; Set-NetIPInterface -InterfaceAlias 'Ethernet1' -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 50; Get-NetIPInterface -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,InterfaceMetric,AutomaticMetric"
InterfaceAlias InterfaceMetric AutomaticMetric
-------------- -------------- ---------------
Ethernet0                  10           False
Ethernet1                  50           False

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

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

Завдання 7: Видалити дефолтний шлюз з неосновного NIC

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -InterfaceAlias 'Ethernet1' -DestinationPrefix '0.0.0.0/0' | Remove-NetRoute -Confirm:\$false; Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Format-Table -Auto"
ifIndex DestinationPrefix NextHop     RouteMetric PolicyStore
------ ----------------- ------     ----------- -----------
     8 0.0.0.0/0         10.20.30.1          25 ActiveStore

Значення: Залишається лише один дефолтний маршрут. Саме це вам потрібно у 95% випадків.

Рішення: Якщо Ethernet1 все ще повинен досягати конкретних віддалених підмереж, додайте для цього конкретні маршрути наступним кроком.

Завдання 8: Додати постійний статичний маршрут для конкретної підмережі через вторинний NIC

cr0x@server:~$ powershell -NoProfile -Command "New-NetRoute -DestinationPrefix '172.16.60.0/24' -InterfaceAlias 'Ethernet1' -NextHop '172.16.50.1' -PolicyStore PersistentStore -RouteMetric 5; Get-NetRoute -DestinationPrefix '172.16.60.0/24' | Format-Table -Auto"
ifIndex DestinationPrefix  NextHop       RouteMetric PolicyStore
------ ------------------  ------       ----------- -----------
    12 172.16.60.0/24      172.16.50.1           5 PersistentStore

Значення: Трафік до 172.16.60.0/24 йтиме через Ethernet1, незважаючи на дефолтний маршрут.

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

Завдання 9: Перевірити вибір DNS-серверів по інтерфейсу і зупинити «корисну» реєстрацію

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,ServerAddresses"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet0      {10.20.30.10, 10.20.30.11}
Ethernet1      {172.16.50.10}

Значення: Ethernet1 має налаштований DNS. Якщо цей DNS-простір не призначено для загальної резолюції, виникають проблеми «неправильного призначення», що виглядають як маршрутизація.

Рішення: Зазвичай: лише управлінський NIC отримує DNS-сервери. Для ізольованих мереж (iSCSI, резервне копіювання) краще не вказувати DNS і вимкнути динамічну реєстрацію DNS на цьому адаптері.

Завдання 10: Перевірити резолюцію і звідки вона прийшла

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName fileserver.corp.local | Select-Object -First 1 Name,IPAddress,Server | Format-List"
Name      : fileserver.corp.local
IPAddress : 172.16.60.25
Server    : 172.16.50.10

Значення: DNS-сервер зі сторони зберігання відповів і повернув адресу у діапазоні зберігання/реплікації. Тепер SMB/RDP може спробувати використовувати цю мережу, навіть якщо ви «виправили» маршрути.

Рішення: Виправте DNS: або видаліть DNS з Ethernet1, або виправте split-horizon DNS, щоб клієнти отримували правильну адресу для їхньої ролі.

Завдання 11: Доведіть фактичний інтерфейс виходу трасою (не лише ping)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.30.10 -Port 445 -InformationLevel Detailed"
ComputerName           : 10.20.30.10
RemoteAddress          : 10.20.30.10
RemotePort             : 445
InterfaceAlias         : Ethernet0
SourceAddress          : 10.20.30.40
TcpTestSucceeded       : True

Значення: Для SMB до DC/файлової точки трафік виходить через Ethernet0 з правильним IP-джерелом.

Рішення: Якщо InterfaceAlias або SourceAddress неправильні, маршрутизація і/або DNS ще не узгоджені з вашими намірами.

Завдання 12: Перевірити ін’єкцію маршрутів VPN (тихий конкурент)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Format-Table -Auto ifIndex,InterfaceAlias,NextHop,RouteMetric,PolicyStore"
ifIndex InterfaceAlias          NextHop      RouteMetric PolicyStore
------ --------------          ------      ----------- -----------
    22 MyCorpVPN               0.0.0.0               1 ActiveStore
     8 Ethernet0               10.20.30.1           25 ActiveStore

Значення: Ваш VPN-адаптер вставив дефолтний маршрут з метрикою 1. Це очікувано для full-tunnel VPN; катастрофічно, якщо ви не планували його на сервері.

Рішення: Визначте політику: full-tunnel чи split-tunnel. Потім забезпечте її на рівні конфігурації VPN-клієнта, а не ручними правками маршрутів після кожного підключення.

Завдання 13: Виявити постійні маршрути, що виживуть після перезавантаження (і здивують вас пізніше)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -PolicyStore PersistentStore | Sort-Object DestinationPrefix | Select-Object -First 12 | Format-Table -Auto DestinationPrefix,NextHop,InterfaceAlias,RouteMetric"
DestinationPrefix NextHop       InterfaceAlias RouteMetric
----------------- ------       -------------- -----------
172.16.60.0/24    172.16.50.1  Ethernet1                5

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

Рішення: Аудитуйте постійні маршрути під час змін NIC, VLAN та перенумерації IP. Ставтесь до них як до конфігурації, а не як до фольклору.

Завдання 14: Перевірити, чи включено IP-форвардинг (ви могли випадково зробити маршрутизатор)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Select-Object -First 5 InterfaceAlias,Forwarding | Format-Table -Auto"
InterfaceAlias Forwarding
-------------- ----------
Ethernet0      Disabled
Ethernet1      Disabled

Значення: Форвардинг вимкнено, отже цей хост не маршрутизує між мережами. Це звична серверна позиція.

Рішення: Якщо Forwarding увімкнено ненавмисно — з’ясуйте чому. Випадковий роутинг між VLAN може створити асиметричні шляхи та інциденти безпеки.

Завдання 15: Підтвердити, що проблема не у фаєрволі Windows або політиці

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Format-Table -Auto Name,Enabled,DefaultInboundAction,DefaultOutboundAction"
Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain  True    Block                Allow
Private True    Block                Allow
Public  True    Block                Allow

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

Рішення: Якщо «неправильний» NIC класифіковано як Public і політика блокує його, ваша «проблема маршрутизації» фактично — політика. Виправте класифікацію мережі та правила фаєрвола усвідомлено.

Правила проєктування для багатомережевих Windows, що не старіють погано

Правило 1: Рівно один дефолтний шлюз на домен маршрутизації

Якщо ваш Windows-сервер має два дефолтні шлюзи, це не «резервність». Це неоднозначність. Якщо вам потрібна справжня багатовихідна поведінка — робіть це в мережі (маршрутизатори, протоколи динамічної маршрутизації), а не давайте серверу дві точки виходу. Windows спробує, але не дуже чемно.

Правило 2: Сприймайте метрики інтерфейсів як конфігурацію, а не пропозицію

Автоматичні метрики підходять для ноутбуків і десктопів користувачів. На серверах це — вичікування збою після наступного драйверного оновлення або перемовин лінку. Явні метрики дають стабільність за низьку ціну.

Правило 3: NIC для зберігання — не «ще один NIC»

iSCSI, SMB Direct (RDMA), резервні реплікації, heartbeat кластера: вони потребують передбачуваних шляхів і джерельних IP. Це означає:

• Немає дефолтного шлюзу
• Зазвичай — немає DNS-серверів
• Вимкнути динамічну реєстрацію DNS, якщо вона плутає клієнтів
• Тільки статичні маршрути для підмереж, що належать цьому полотну

Правило 4: DNS — частина маршрутизації, подобається вам це чи ні

Коли ім’я резолвиться в адресу в «іншій» мережі, Windows охоче відправляє туди трафік. Потім ви дивитеся на таблицю маршрутів і дивуєтесь, чому використовується неправильний NIC, тоді як правда: саме призначення хоста не відповідає його ролі.

Правило 5: Віртуальні адаптери заслуговують тієї ж уваги, що і фізичні

Hyper-V vEthernet-адаптери, мережі контейнерів і VPN-адаптери можуть вставляти маршрути, DNS і дивні метрики. Не ігноруйте їх, бо «вони віртуальні». Віртуальні проблеми — все ще реальні відмови.

Жарт #2: Другий дефолтний шлюз — як дати серверу два керма: технічно можливо, емоційно — жалюгідно.

Три корпоративні міні-історії з рутин маршрутів

Міні-історія 1: Інцидент через хибне припущення

Файловий сервер департаменту фінансів отримав другий NIC для нової мережі бекапу. Інженер, що робив зміну, припустив: «шлюзи на обох NIC означають більше надійності», бо вдома його mesh Wi‑Fi так поводиться. Вони не намагалися бути необережними; просто хотіли допомогти під тиском часу.

Під час вікна технічного обслуговування все працювало. Бекапи почалися. Всі розійшлися. Вночі upstream на VLAN бекапу мав періодичні проблеми з шлюзом — короткі втрати пакетів, достатні для повторів, але не для повного відключення.

До ранку доступ до файлового сервера для деяких користувачів був повільним, для інших — нормальним. RDP на сервер став млявим. Моніторинг показував втрати пакетів до випадкових адрес. Команда шукала проблеми в зберіганні, антивірусі, навіть «може це комутатор». У таблиці маршрутів було два дефолтні маршрути, і Windows віддав перевагу VLAN бекапу через автоматичні метрики. Кожного разу, коли нестабільний шлюз підглючував, Windows переживав таймаути і переключався на інший дефолт… поки знову не повертався.

Виправлення було простим: видалити дефолтний шлюз з NIC бекапу, додати маршрут лише до підмережі бекапу і встановити явні метрики інтерфейсів. Постмортем був складнішим: оновили стандарт побудови серверів, щоб «один дефолтний шлюз» був не народною мудрістю, а аудиторським вимогою.

Міні-історія 2: Оптимізація, що повернулася бумерангом

Команда, що керувала Hyper-V хостами, хотіла пришвидшити live migration. Вони додали виділені 25Gb NIC і встановили дуже низькі метрики інтерфейсів, щоб «переконатися, що міграція йде по швидких каналах». Ідея в ізоляції звучить розумно.

Що вони пропустили: ті самі хости також виконували доменну автентифікацію, оновлення та координацію резервних копій по управлінській мережі. Під час напруженого тижня один комутатор тимчасово знизив швидкість переговорної на одному управлінському лінку. Автоматичні метрики перерахувалися; «швидкий NIC для міграції» почав вигравати більше маршрутів, ніж мав. Деякі сервіси почали рекламуватися та звертатися з неправильного джерельного IP.

Втручання було тонким. Live migration дійсно було швидко. Але валідація кластера почала видавати попередження. Інструмент управління періодично втрачав зв’язок з хостами. Резервна задача почала підключатися до IP міграції, недоступного з сегмента резервного копіювання. Це виглядало як випадкова нестабільність, поки хтось не зіставив час з змінами маршрутів.

Вони відкотили «оптимізацію», потім відтворили її правильно: без дефолтного шлюзу на міграційному NIC, статичні маршрути де потрібно і явне налаштування SMB Multichannel, щоб міграція могла використовувати потрібні інтерфейси, не викрадаючи решту мережевої ідентичності хоста.

Міні-історія 3: Нудна, але правильна практика, що врятувала

Виробнича компанія мала суворий чекліст для розгортання серверів. Це не виглядало гламурно. Це дратувало людей, які любили «просто відправити». Чекліст включав явні метрики інтерфейсів, правило одного дефолтного шлюзу та невеличкий набір постійних маршрутів для мереж реплікації. Також була рутина аудиту: щомісячно дампити таблиці маршрутів і порівнювати з базовою.

Одного місяця аудит показав додатковий постійний маршрут 0.0.0.0/0 у PersistentStore на контролері домену. Ще нічого не впало. Це найкращий час знайти потенційну відмову.

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

Чекліст не запобігає помилкам. Він запобігає сюрпризам. В операціях це — більша частина битви.

Типові помилки: симптом → корінь → виправлення

1) RDP працює, але повільно і іноді обривається

Симптом: RDP підключається, але затримки введення; сесії падають під час мережевих спалахів.

Корінь: Два дефолтні маршрути; Windows іноді використовує «неправильний» шлюз при перервах.

Виправлення: Тримайте один дефолтний шлюз. Видаліть 0.0.0.0/0 з вторинного NIC, встановіть явні метрики інтерфейсів і додайте конкретні маршрути для потрібних віддалених підмереж.

2) SMB до файлового сервера йде через NIC зберігання

Симптом: Копіювання файлів використовує несподіваний джерельний IP; логи фаєрвола показують блокування трафіку з VLAN зберігання.

Корінь: DNS резолвить ім’я файлового сервера в адресу, доступну через NIC зберігання (або SMB Multichannel вибирає інтерфейси, яких ви не очікували).

Виправлення: Виправте призначення DNS; управлінський NIC має бути авторитетним для резолюції імен. Якщо використовується SMB Multichannel, перевірте ролі NIC для RSS/RDMA і переконайтеся, що підмережі клієнта/сервера відповідають наміченим шляхам.

3) Доступ в інтернет відсутній після додавання NIC для бекапу

Симптом: Сервер може досягати внутрішніх підмереж, але не зовнішніх адрес.

Корінь: Дефолтний маршрут перемістився в мережу без NAT/egress; шлюз є, але не маршрутизує в інтернет.

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

4) «Працювало, поки не перезавантажили»

Симптом: Ручні виправлення зникають після рестарту.

Корінь: Ви редагували тільки ActiveStore; постійні маршрути/метрики не встановлені, або конфігураційний менеджмент перезаписав налаштування.

Виправлення: Використовуйте PersistentStore для маршрутів. Встановіть явні метрики інтерфейсів. Перевірте Group Policy, скрипти та агенти, що можуть повторно застосовувати мережеві налаштування.

5) Трафік до віддаленої підмережі йде не тим NIC, навіть при одному дефолтному шлюзі

Симптом: Лише конкретні призначення йдуть неправильно.

Корінь: Існує більш специфічний маршрут (постійний, вставлений VPN або доданий програмно).

Виправлення: Знайдіть точний маршрут за допомогою Find-NetRoute, потім видаліть/відрегулюйте конфліктний специфічний маршрут або поставте кращу метрику.

6) Після увімкнення Hyper-V маршрути і DNS стали дивними

Симптом: З’явилися нові vEthernet-адаптери; змінилася резолюція імен; змінився вибір дефолтного шлюзу.

Корінь: vSwitch-адаптери беруть участь у метриках/реєстрації DNS; іноді фізичний NIC стає віртуальним uplink і налаштування зсуваються.

Виправлення: Переаудитуйте метрики і DNS на всіх адаптерах після встановлення Hyper-V. Вимкніть реєстрацію DNS там, де це недоцільно. Переконайтеся, що управлінський vNIC — той, який має дефолтний шлюз.

7) «Шлюз доступний, але додатки все одно падають»

Симптом: Ping працює, але SQL/HTTP/SMB таймаутиться.

Корінь: Асиметрична маршрутизація: відповіді виходять іншим NIC/джерельним IP, ніж клієнт очікує, або стан фаєрвола скидається.

Виправлення: Забезпечте консистентний джерельний IP, виправивши вибір маршруту і уникаючи кількох точок виходу. За потреби валідйте Test-NetConnection і захопленням пакетів.

Чеклісти / покроковий план (робіть це, не імпровізуйте)

Чекліст A: Стабілізувати зламаний багатомережевий сервер у виробництві

1. Визначте намічений інтерфейс за замовчуванням (управління/egress). Запишіть його, щоб команда припинила сперечатися.
2. Захопіть поточний стан: адаптери, IP, шлюзи, DNS-сервери, таблиця маршрутів, постійні маршрути.
3. Підтвердіть фактичний маршрут до ключових кінцевих точок: DC, моніторинг, ціль бекапу, ціль зберігання, інтернет-проба.
4. Видаліть зайві дефолтні маршрути: залиште рівно один 0.0.0.0/0 (якщо у вас немає формального багатовихідного дизайну).
5. Встановіть явні метрики інтерфейсів: вимкніть AutomaticMetric на серверних NIC; оберіть стабільні значення (наприклад, mgmt 10, storage 50, migration 60).
6. Виправте призначення DNS: DNS — на управлінському NIC; спеціалізовані NIC зазвичай без DNS. Уникайте хаотичного змішування просторів імен.
7. Додайте конкретні постійні маршрути для віддалених підмереж, які повинні йти через вторинний NIC.
8. Перевірте на рівні додатків (SMB порт 445, SQL порт 1433, HTTP health checks). Ping — потрібний, але недостатній.
9. Вікно перезавантаження (якщо можливо) і повторна перевірка. Якщо не можна перезавантажити — принаймні переконайтеся, що конфігурація стійка.
10. Задокументуйте наміри: який NIC для чого і що ніколи не має бути додано (наприклад, другий дефолтний шлюз).

Чекліст B: Стандарт побудови нових Windows-серверів з кількома NIC

1. Визначте ролі: управління, зберігання, бекап, реплікація, міграція, DMZ тощо.
2. Один дефолтний шлюз лише на управлінні/egress.
3. Явні метрики інтерфейсів; AutomaticMetric вимкнено.
4. DNS лише на управлінському NIC, якщо немає свідомого multi-namespace дизайну.
5. Вимкніть реєстрацію DNS на неуправлінських NIC, якщо це заплутує AD-інтегрований DNS.
6. Постійні статичні маршрути для спеціалізованих віддалених мереж.
7. Моніторингові перевірки, що верифікують джерельний IP для критичних потоків (виявляють помилкові маршрути рано).
8. Крок керування змінами: після додавання NIC повторно аудитуйте маршрути і DNS.

Чекліст C: Коли вам справді потрібен більше одного шляху виходу

Там, де команди стають креативними і потім отримують виклики на ніч.

1. Визначте, чи взагалі хост повинен виконувати багатовихідну маршрутизацію; часто — ні.
2. Якщо так — чітко визначте політики маршрутизації (які призначення через який egress).
3. Реалізуйте це конкретними маршрутами (і, можливо, динамічною маршрутизацією в мережі), а не «два дефолтні шлюзи і молитва».
4. Тестуйте поведінку відмови при втраті, збільшенні затримки та часткових збоях.
5. Майте операційний план: як виявляєте вибір шляху, як відкатуєте, як запобігаєте дрейфу.

FAQ

1) Чому Windows обирає «неправильний» NIC після додавання другого адаптера?

Тому що ви надали йому два життєздатні шляхи (часто два дефолтні шлюзи) і метрики зробили інший дешевшим. Автоматичні метрики можуть змінюватися з огляду на швидкість лінку та драйвери.

2) Чи коли-небудь доречно налаштовувати два дефолтні шлюзи на Windows-сервері?

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

3) Якщо я видалю дефолтний шлюз з NIC зберігання, як він щось досягатиме?

Він досягатиме підмережі, що знаходиться на каналі «on-link», напряму, а все інше — через специфічні маршрути, які ви додасте (постійні статичні маршрути). Мережі зберігання зазвичай не повинні бути загального призначення.

4) У чому різниця між метрикою маршруту і метрикою інтерфейсу?

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

5) Чому моє «виправлення» зникло після перезавантаження?

Швидше за все, ви змінювали тільки ActiveStore; або система керування конфігурацією перезаписала налаштування. Використовуйте PersistentStore для маршрутів і встановлюйте явні метрики інтерфейсів.

6) Чи може DNS справді створити ілюзію, що маршрутизація зламана?

Абсолютно. Якщо ім’я резолвиться в IP на вторинній мережі, Windows коректно відправить туди трафік. Таблиця маршрутів невинна; провина у політиці резолюції імен.

7) Що з SMB Multichannel — чи не буде він використовувати всі NIC одночасно?

Він може, якщо обидва кінці підтримують це і налаштовано. Але це не виправдовує недбалих шлюзів і DNS. Перевірте, які інтерфейси використовує SMB, і переконайтеся, що підмережі та правила фаєрвола відповідають намірам.

8) Чи варто повсюди вимкнути AutomaticMetric?

На серверах з кількома NIC: зазвичай так. На ноутбуках: можна дозволити. Різниця в тому, що сервери — інфраструктура; передбачуваність важливіша за зручність.

9) Hyper-V додав vEthernet-адаптери — чи потребують вони метрик теж?

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

10) Як дізнатися, який інтерфейс Windows використає перед тим, як ламати продакшн?

Використайте перевірки вибору маршруту (наприклад, Find-NetRoute) для представницьких призначень, потім тестуйте Test-NetConnection і перевіряйте SourceAddress/InterfaceAlias.

Висновок: наступні кроки, які дійсно працюють

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

Зробіть наступне:

1. Аудит на наявність кількох дефолтних шлюзів і видаліть зайві.
2. Вимкніть автоматичні метрики інтерфейсів і встановіть їх свідомо.
3. Перемістіть мережі спеціального призначення на специфічні постійні маршрути.
4. Виправте DNS, щоб імена резолвилися в правильну мережу для конкретної задачі.
5. Після будь-якої зміни NIC/VLAN/VPN заново прогоніть швидкі діагностичні перевірки, поки користувачі не зроблять це за вас.

Якщо ви хочете одну операційну звичку, що окупається назавжди: знімайте базову таблицю маршрутів і метрики інтерфейсів для кожної ролі сервера. Коли наступний інцидент «Windows обрав насильство» станеться, у вас буде diff, а не містерія.