Kāpēc maršruti ar vienādām izmaksām padara VPN kļūmes grūti pamanāmas
Kad vairāki tuneļi dala vienas izmaksas, katra plūsma var izvēlēties citu. Veiksmīgs ping neko neizsaka par ceļu, ko jūsu lietojumprogramma faktiski izmanto.
Lietotājs ziņo, ka iekšējā lietojumprogramma strādā no vienas mašīnas un neizdodas no citas, savukārt ping, ko palaižat no vārtejas, izdodas abos gadījumos. Ja ir vairāki vienādu izmaksu tuneļi, tā nav pretruna. Katra plūsma tiek ievietota uz sava nākamā lēciena, tāpēc jūsu pārbaude un lietotāja sesija var vienkārši izmantot dažādus ceļus. Tālāk sniegtais izklāsts atveido šo izvēli pirms kaut kā maiņas.
Viens ping, vairāki iespējami ceļi
Kad maršrutam ir vairāk nekā viens nākamais lēciens ar vienādām izmaksām, maršrutētājam ir jāizvēlas viens katram paketam. Lielākā daļa implementāciju jauc paketes laukus, parasti avota un galamērķa adreses kopā ar protokolu un portiem, lai atbildes paliktu tajā pašā ceļā. Dažādas lietojumprogrammas, pat vienas programmas dažādi savienojumi, rada dažādas jaucējvērtības.
Tāpēc diagnostika no vārtejas pierāda tik maz. Pašas vārtejas pārbaudei ir savas adreses un porti, tātad arī sava jaucējvērtība. Tā var nonākt uz veselā tuneļa, kamēr lietotājs turpina nonākt uz bojātā.
Kā platforma izvēlas nākamo lēcienu
Atveidojiet izvēli, nevis miniet to. Pajautājiet kodolam, kuru maršrutu tas izmantotu tam pašam avotam un galamērķim kā neizdevusies sesija. Šajā meklēšanā ietilpst lauki, ko vienkārša galamērķa meklēšana ignorē. Palaidiet to arī no strādājoša klienta un salīdziniet abas atbildes:
ip route get 10.20.5.7 from 10.20.0.14Jaunākas iproute2 versijas pieņem arī protokolu un galamērķa portu, kas ir svarīgi, ja jaucējvērtība tos ietver. Salīdziniet šo izvadi ar to pašu meklēšanu no strādājoša klienta, un atšķirība ir tas pierādījums, kura jums trūka.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Sekojiet neizdevušajai plūsmai, nevis maršrutu tabulai
Maršrutu tabula uzskaita abus tuneļus un pēc definīcijas izskatās pareiza. Jautājums ir, ko katrs tunelis dara ar paketi pēc izvēles. Pārbaudiet, vai abi nes tos pašus aizsargātos prefiksus, to pašu pārsūtīšanas atļauju un atgriešanās ceļu, kas sasniedz to pašu klientu.
Pievērsiet uzmanību stāvokļa ierīcēm vidū. Ja pieprasījums iziet caur vienu tuneli un atbilde atgriežas caur otru, ugunsmūris vai NAT, kas nekad nav redzējis sākotnējo plūsmu, to izmetīs. Abi tuneļi pareizi pārsūta datplūsmu, un savienojums tomēr neizdodas.
Pārbaudiet arī MTU katram ceļam. Ceļš ar papildu iekapsulējumu samazina izmantojamo izmēru, un pārsūtīšana, kas izdodas vienā tunelī, otrā apstājas tieši tajā izmērā, kur mazākais lūzt.
Salīdziniet vienu ceļu vienlaikus
Kur projektējums pieļauj apkopi, izņemiet vienu tuneli no ekspluatācijas un atkārtojiet lietotāja uzdevumu. Ja kļūme pazūd, problēma pieder noņemtajam ceļam, un nākamais solis ir salīdzināt tā konfigurāciju ar kaimiņa konfigurāciju, nevis no jauna pārbaudīt maršrutēšanas tabulu.
Salīdziniet īsto lietojumprogrammu, nevis atkārtotus ping. Pierakstiet, vai kļūme seko noteiktam nākamajam lēcienam, paketes izmēram vai pārejai pēc atkārtotas pievienošanās, jo šie trīs modeļi norāda uz dažādiem remontiem.
Visbeidzot pierakstiet, kāpēc ceļi tiek uzskatīti par līdzvērtīgiem un kā kļūmei vajadzētu izņemt vienu no tiem no ekspluatācijas. Daudzceļu režīms ir drošs tikai tad, ja ceļi patiešām ir aizvietojami, un tas ir projektējuma apgalvojums, ko ir vērts pārbaudīt, nevis pieņemt.