Када се руте подељеног тунела преклапају: који префикс побеђује

Два профила подељеног тунела, два приватна префикса и један домаћин на који обоје полажу право. Симптом је ретко чист квар: услуга ради у понедељак, престане да одговара после поновног повезивања другог клијента и поново ради после рестартовања. Редослед којим сте повезали клијенте не одлучује о исходу, нити редослед редова у сучељу клијента. Изведите ове провере по реду и зауставите се на првој која не важи, јер касније имају смисла само када су претходне истините.

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. Други клијент може при повезивању поново да инсталира своју руту и поново створи сукоб, зато провера стања мора да уследи после повезивања последњег клијента, а не пре тога.

Тестирајте два тока, не један: захтев који је раније неуспешно пролазио и ресурс који би требало да користи други тунел. Премештање целог приватног саобраћаја на једну везу пустиће први тест, али сломити други, а то хвата само упарен тест. Забележите сваки изузетак који задржите, са одредиштем и разлогом, како би следећа особа могла да разликује намерну руту до домаћина од преостале.