Когато маршрутите на разделен тунел се застъпват: кой префикс печели

Два профила на разделен тунел, два частни префикса и един хост, който и двата претендират. Симптомът рядко е чиста повреда: услуга работи в понеделник, спира да отговаря след повторно свързване на втория клиент и отново работи след рестарт. Редът, в който сте свързали клиентите, не определя резултата, нито редът на редовете в интерфейса на клиента. Изпълнете тези проверки по ред и спрете на първата, която не издържа, защото следващите имат смисъл само след като предходните са верни.

1. Запишете дестинацията и източника

Започнете с точния адрес, към който отива неуспешната заявка, а не с името на хоста и не с името на приложението. Разрешете името веднъж, запишете всеки отговор и изберете този, който неуспешният поток действително използва. След това запишете локалния адрес на същия поток, защото адресът на източника може да промени кое правило за политика съвпада и следователно коя таблица се преглежда.

Заявка към един от няколко A записа може да се провали, докато съседен адрес успява, което изглежда като нестабилен тунел, а всъщност са два различни пътя. Ако дестинацията е име с няколко отговора, тествайте всеки отговор поотделно, преди да промените нещо.

2. Попитайте ядрото кой маршрут е избрало

Не четете таблицата с маршрути и не правете извод. Задайте същия въпрос, който задава стекът, със същия адрес на източника: ip route get 10.20.4.10 from 10.8.0.2 в Linux или Find-NetRoute -RemoteIPAddress 10.20.4.10 в PowerShell. Изходът посочва маршрута, който действително ще бъде използван, а той често не е този, който сте очаквали от четенето на таблицата.

Сред съвпадащите маршрути обикновено печели по-конкретният префикс: /24 побеждава /16 за адрес в двата. При съвпадения с еднаква дължина печели по-ниската метрика, а маршрут, инсталиран на изключен интерфейс, се пропуска. Два тунела, които налагат един и същ /24 с еднаква метрика, са друг случай: ядрото запазва и двата маршрута и избира между тях, така че резултатът може да се редува, вместо да следва реда на свързване на клиентите. Точно тази ситуация създава модела, при който в понеделник работи, а във вторник не, и повторното свързване в различен ред не го променя.

3. Проверете дали правило за политика е пренасочило търсенето

Преди да се прегледа таблицата с маршрути, ядрото обхожда правилата си за политика. Правило може да изпрати трафик от даден източник, потребител или маркер на защитна стена към съвсем друга таблица, така че печелившият префикс в основната таблица може никога да не бъде прегледан за този поток. ip rule show ги изброява в ред на оценяване, а ip route show table 100 показва какво действително съдържа избраната таблица.

Тук има два капана. Правило, сочещо към празна таблица, създава търсене, което пропада към следващото правило, така че правилото изглежда, че не прави нищо. Другият е самият номер на приоритет: правилата се четат във възходящ ред, а вградените са 0 local, 32766 main и 32767 default. Правило с номер под 32767 се преглежда преди правилото по подразбиране, което прихваща всичко. Правило с номер над 32767 стои зад него и се достига само когато никоя по-ранна таблица не отговори; нормален маршрут по подразбиране в main предотвратява това, затова на практика то никога не се достига и мълчаливо не прави нищо, докато изглежда инсталирано. Ако клиентът е записал правило и маршрут, проверете и двете и ги проверете отново след повторно свързване, защото пренаписан профил може да добави второ правило с различен приоритет.

4. Отделете равенство в маршрутизацията от дублиран адресен план

Понякога префиксът изобщо не е проблемът. Два обекта, които използват 192.168.1.0/24, означават, че един и същ адрес идентифицира два различни хоста и никой маршрут не може да ги различи. Маршрут до хост към един от двата отговора работи само докато другият обект отговори за същото име, и тогава изключението тихо се превръща в дефекта.

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

5. Потвърдете, че резолверът е съгласен с маршрута

Име, което се разрешава до грешен частен адрес, дава всички симптоми на конфликт в маршрутизацията и нито една от причините му. Сравнете отговора, който хостът получава, с адреса, който дестинацията действително използва, и проверете кой резолвер е отговорил. Ако тунелът налага резолвер, клиентът трябва да го инсталира за потоците, които използват тунела; ако не, хостът продължава да пита локалния резолвер, който може да отговори от домейн за търсене или от кеширан запис.

Запитайте резолвера директно и запишете сървъра, който е отговорил. Кеширан отговор с кратък TTL също може да обясни защо първата заявка след повторно свързване се държи различно от петата.

6. Свържете се отново, прегледайте приложеното състояние, след което тествайте двата потока

След корекция се свържете отново и прегледайте какво действително е инсталирал клиентът, вместо да се доверявате на редактора на профили. Прочетете отново правилата, таблиците и получения отговор на ip route get. Втори клиент може да преинсталира собствения си маршрут при свързване и да възстанови конфликта, затова проверката на състоянието трябва да се прави след свързването на последния клиент, а не преди него.

Тествайте два потока, не един: заявката, която преди се проваляше, и ресурс, който трябва да използва другия тунел. Преместването на целия частен трафик към една връзка ще направи първия тест успешен, но ще счупи втория, и само сдвоен тест хваща това. Записвайте всяко изключение, което запазвате, с дестинацията и причината, за да може следващият човек да различи умишлен маршрут до хост от остатъчен.