Kad sadalītā tuneļa maršruti pārklājas: kurš prefikss uzvar

Divi sadalītā tuneļa profili, divi privāti prefiksi un viens resursdators, uz kuru abi pretendē. Simptoms reti ir tīrs bojājums: pakalpojums strādā pirmdien, pēc otrā klienta atkārtotas pievienošanās beidzas gaidīšanas laiks, un pēc pārstartēšanas tas atkal strādā. Secība, kādā pievienojāt klientus, nenosaka iznākumu, un arī rindu secība klienta saskarnē to nenosaka. Veiciet šīs pārbaudes pēc kārtas un apstājieties pie pirmās, kas neizpildās, jo vēlākās ir jēgpilnas tikai tad, kad iepriekšējās ir patiesas.

1. Pierakstiet galamērķi un avotu

Sāciet ar precīzu adresi, uz kuru iet neveiksmīgais pieprasījums, nevis ar resursdatora nosaukumu un nevis ar lietotnes nosaukumu. Vienreiz atrisiniet nosaukumu, pierakstiet katru atbildi un izvēlieties to, ko neveiksmīgā plūsma patiešām izmanto. Pēc tam pierakstiet tās pašas plūsmas lokālo adresi, jo avota adrese var mainīt, kurš politikas noteikums atbilst un līdz ar to kura tabula tiek skatīta.

Pieprasījums uz vienu no vairākiem A ierakstiem var neizdoties, kamēr blakus adrese izdodas, un tas izskatās kā nestabils tunelis, bet patiesībā ir divi dažādi ceļi. Ja galamērķis ir nosaukums ar vairākām atbildēm, pirms kaut ko mainīt pārbaudiet katru atbildi atsevišķi.

2. Pajautājiet kodolam, kuru maršrutu tas izvēlējās

Nelasiet maršrutu tabulu un neizdariet no tās secinājumu. Uzdodiet to pašu jautājumu, ko uzdod stek, ar to pašu avota adresi: ip route get 10.20.4.10 from 10.8.0.2 Linux vai Find-NetRoute -RemoteIPAddress 10.20.4.10 PowerShell. Izvade nosauc maršrutu, kas patiešām tiktu izmantots, un tas bieži nav tas, ko gaidījāt, lasot tabulu.

No atbilstošajiem maršrutiem parasti uzvar konkrētākais prefikss: /24 pārspēj /16 adresei, kas atrodas abos. Starp vienāda garuma atbilstībām uzvar zemāka metrika, un maršruts, kas instalēts izslēgtā saitē, tiek izlaists. Divi tuneļi, kas izsludina vienu un to pašu /24 ar vienu un to pašu metriku, ir cits gadījums: kodols patur abus maršrutus un izvēlas starp tiem, tāpēc iznākums var mainīties, nevis sekot klientu pievienošanās secībai. Tieši šī situācija rada modeli pirmdien-strādā-otrdien-neizdodas, un atkārtota pievienošanās citā secībā to nemaina.

3. Pārbaudiet, vai politikas noteikums novirzīja meklēšanu

Pirms tiek skatīta maršrutu tabula, kodols iziet cauri saviem politikas noteikumiem. Noteikums var sūtīt trafiku no noteikta avota, lietotāja vai ugunsmūra atzīmes uz pavisam citu tabulu, tāpēc galvenās tabulas uzvarošais prefikss šai plūsmai var tikt nekad skatīts. ip rule show uzskaita tos vērtēšanas secībā, un ip route show table 100 parāda, kas izvēlētajā tabulā patiešām ir.

Šeit slēpjas divas lamatas. Noteikums, kas norāda uz tukšu tabulu, rada meklēšanu, kas pārkrīt uz nākamo noteikumu, tāpēc šķiet, ka noteikums neko nedara. Otra ir pats prioritātes numurs: noteikumi tiek lasīti augošā secībā, un iebūvētās vērtības ir 0 local, 32766 main un 32767 default. Noteikums ar numuru zem 32767 tiek skatīts pirms visu pārtverošā noklusējuma noteikuma. Noteikums ar numuru virs 32767 atrodas aiz tā un tiek sasniegts tikai tad, kad neviena iepriekšējā tabula neatbild, ko novērš parasts noklusējuma maršruts main, tāpēc praksē tas nekad netiek sasniegts un klusi neko nedara, kamēr izskatās instalēts. Ja klients ierakstīja noteikumu un maršrutu, pārbaudiet abus un pārbaudiet tos vēlreiz pēc atkārtotas pievienošanās, jo pārrakstīts profils var pievienot otru noteikumu ar citu prioritāti.

4. Atšķiriet maršrutu neizšķirtu no dublēta adrešu plāna

Dažkārt prefikss nemaz nav problēma. Divas vietnes, kas abas izmanto 192.168.1.0/24, nozīmē, ka viena un tā pati adrese identificē divus dažādus resursdatorus, un neviens maršruts tos nevar atšķirt. Resursdatora maršruts uz vienu no divām atbildēm darbojas tikai tik ilgi, kamēr otra vietne neatbild uz to pašu nosaukumu, un tad izņēmums klusi kļūst par pašu kļūdu.

Pazīme ir tā, ka galamērķa adrese abos ceļos ir identiska un atšķiras tikai paredzētais īpašnieks. Tas ir adrešu plāna lēmums, nevis maršrutēšanas pielāgojums: pārnumurējiet vienu pusi, novietojiet vienu pusi aiz tulkojošas vārtejas vai sasniedziet otro vietni caur starpniekserveri, kas pats atrisina savus nosaukumus. Noklusējuma maršruta pazemināšana vai resursdatoru izņēmumu krāšana tikai pārvieto sadursmi.

5. Apstipriniet, ka atrisinātājs piekrīt maršrutam

Nosaukums, kas tiek atrisināts uz nepareizu privāto adresi, rada visas maršrutēšanas konflikta pazīmes un nevienu no tā cēloņiem. Salīdziniet atbildi, ko saņem resursdators, ar adresi, ko galamērķis patiešām izmanto, un pārbaudiet, kurš atrisinātājs atbildēja. Ja tunelis piespiež atrisinātāju, klientam tas jāinstalē tām plūsmām, kas izmanto tuneli; ja tas to nedara, resursdators turpina jautāt vietējam atrisinātājam, kas var atbildēt no meklēšanas domēna vai kešatmiņā saglabāta ieraksta.

Jautājiet atrisinātājam tieši un pierakstiet serveri, kas atbildēja. Kešatmiņā saglabāta atbilde ar īsu TTL var arī izskaidrot, kāpēc pirmais pieprasījums pēc atkārtotas pievienošanās uzvedas citādi nekā piektais.

6. Pievienojieties atkārtoti, apskatiet piemēroto stāvokli un pēc tam pārbaudiet abas plūsmas

Pēc labojuma pievienojieties atkārtoti un apskatiet, ko klients patiešām instalēja, tā vietā lai uzticētos profila redaktoram. Vēlreiz izlasiet noteikumus, tabulas un iegūto ip route get atbildi. Otrs klients var pievienojoties no jauna instalēt savu maršrutu un atkal radīt konfliktu, tāpēc stāvokļa pārbaudei jānotiek pēc pēdējā klienta pievienošanās, nevis pirms tās.

Pārbaudiet divas plūsmas, nevis vienu: pieprasījumu, kas agrāk neizdevās, un resursu, kam būtu jāizmanto otrs tunelis. Ja viss privātais trafiks tiek pārvietots uz vienu savienojumu, pirmais tests izturēs, bet otrais salūzīs, un to notver tikai pāru tests. Pierakstiet katru paturēto izņēmumu ar galamērķi un iemeslu, lai nākamais cilvēks varētu atšķirt tīšu resursdatora maršrutu no atlikuma.