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

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

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

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