Kako ločiti zanko usmerjanja od plahutanja poti na mestih VPN

Dve mesti, en tunel in oddaljena predpona, ki nekaj časa odgovarja in nato utihne. Refleks je to imenovati zanka usmerjanja, in včasih je točno to. Toda zanka in plahutajoča pot dajeta isto pritožbo in zahtevata nasprotni popravili: eno je odločitev o posredovanju, ki se nikoli ne konča, drugo je predpona, ki vedno znova zapusti tabelo. Tri opažanja ju ločijo, in vse tri lahko zberete iz ukazne vrstice prehoda, preden se dotaknete filtra ali znova zaženete tunel.

Zanka se odloči skok za skokom. Mesto A izbere B kot naslednji skok do cilja, B izbere A za isti cilj, in paket poteče na TTL po dveh krogih. Plahutanje pa odloči usmerjevalni protokol: predpona se umakne, znova namesti ali nadomesti z nadomestnim naslednjim skokom, zato nekateri paketi nimajo nobene poti, drugi pa sledijo povsem dobri.

Tri preverjanja, ki razrešijo vprašanje

Za prvo odločitev ne potrebujete zajema paketov. Potrebujete stanje predpone na obeh koncih, naslednji skok, ki ga izbere vsaka stran, in število skokov, ki se bodisi ponavlja bodisi ne. Če predpona ostane nameščena z istim naslednjim skokom, medtem ko promet ne uspeva, zanka živi v posredovalni poti. Če predpona izgine in se vrne, je napaka nad posredovanjem in popravilo pripada usmerjevalnemu protokolu, ne statični poti.

Eno opozorilo pred začetkom. Če to berete skozi tunel, ki dela zanko, vaša seja umre v trenutku, ko spremenite pot. Odprite konzolo ali pot upravljanja, ki ni odvisna od predpone, ki jo nameravate popraviti.

Prvo preverjanje: je predpona stabilna ali se vre

Vprašajte jedro, kaj je namestilo, ne kaj obljublja konfiguracijska datoteka. Na prehodu Linux ip route get 10.20.30.40 izvede isto iskanje kot posredovalna pot, vključno s tabelami pravil, medtem ko ip route show 10.20.30.0/24 prikaže sam vnos. ip monitor route prenaša vsako spremembo v trenutku, ko se zgodi, kar je najhitrejši način opazovanja predpone, kako prihaja in odhaja.

Na usmerjevalniku s FRR ali BIRD ni zanimiva posredovalna tabela. show ip bgp 10.20.30.0/24 vrne izbrano pot in njen čas delovanja; čas delovanja, ki se ponastavi vsakih nekaj minut, je plahutanje, ki ga lahko poimenujete, ne zanka. show ip bgp summary prikaže stanje sosedov in število predpon, zato sosed, ki nenehno pada, sname krivdo s posredovalne poti.

Zapišite odgovor, preden karkoli spremenite. Stabilnost deset minut, medtem ko so pingi spodleteli, in izginotje štirikrat v desetih minutah vodita do različnih naslednjih korakov. Drugi primer naredi vsako teorijo statične poti nepomembno.

Drugo preverjanje: ali naslednji skok kaže nazaj v prihodni tunel

Zanka potrebuje soglasje dveh prehodov. Na mestu, ki paket prejme, poglejte pot, ki jo bo paket uporabil za izhod: ip route get 10.20.30.40 from 10.10.5.20 z resničnim izvornim naslovom, ker lahko pravilo politike odgovori drugače kot glavna tabela. Nato ponovite iskanje na mestu, ki ga je poslalo. Če vsaka stran izbere drugo kot naslednji skok za isto predpono, je zanka dokazana in noben zajem ne bo ničesar dodal.

Vzrok je skoraj vedno najava, ki ne bi smela prečkati tunela. Privzeta pot, prerazporejena v tunel, agregat, ki pokriva lastno podomrežje oddaljenega mesta, ali statična pot na partnerja za vsak primer ustvarijo vsi isti vzajemni naslednji skok. Tunel je lahko popolnoma vzpostavljen in še vedno vodi promet v krogu; opombe o posredovanju strongSwana opisujejo usmerjevalno stran te zahteve.

WireGuard si zasluži svojo opombo, ker ni nobene najave za obtoževanje. wg show navaja AllowedIPs vsakega partnerja, in jedro sprejme cilj za partnerja le, če pade v to območje. Zanka tam je prekrivajoče se območje AllowedIPs ali statična pot, ki kaže nazaj čez vmesnik, zato popravilo živi samo na tistih dveh mestih.

Tretje preverjanje: berite število skokov, ne zvezdic

traceroute -n -I 10.20.30.40 in mtr -n -r -c 20 10.20.30.40 oba prikažeta pot, in način ICMP pogosto preživi filtriranje, ki poje UDP sonde. Zanka je videti kot kratko ponavljajoče se zaporedje istih dveh naslovov prehoda, pri čemer TTL vsakič narašča. Izpad je videti kot zvezdice po zadnjem prehodu, ki je odgovoril, in en sam tih skok ni dokaz za nič.

Ko je pot dvoumna, berite TTL na žici. tcpdump -ni any -vv icmp na obeh prehodih prikaže TTL vsakega paketa in izvorni naslov vsakega odgovora o preseženem času. Če paket prispe na oddaljeno mesto z nižjim TTL od števila skokov, ki jih pot lahko vsebuje, nekaj dodaja skoke, ki jih traceroute ne prikaže, in to se zgodi, ko požarni zid enega mesta odgovarja na sonde v imenu drugega.

Popravite lastnika predpone, nato preverite obe smeri

Odločite, katero mesto ustvari cilj in katere tranzitne poti so dovoljene, nato spremenite najavo ali statično pot pri tem lastniku. Popravljanje prejemnega mesta je vabljivo in običajno napačno: skrije zanko za eno predpono in pusti slabo najavo na mestu za naslednjo. Oznake poti, distribucijski seznami in pravila split-horizon obstajajo zato, da to ustavijo pri viru, in so cenejša od filtra, ki se ujema z eno predpono.

Po spremembi preverite pot tja in nazaj ločeno, ker je zanko mogoče nadomestiti s črno luknjo brez vidnega izboljšanja simptoma. Zaženite ip route get z obeh koncev, pošljite promet z gostitelja, ki ni prehod, in pustite ip monitor route delovati vsaj en časovnik zadrževanja, da se plahutanje ne zamenja s popravilom.

Preden karkoli spremenite, potrdite teh pet točk: predpona je stabilna ali se vre, naslednji skok na obeh koncih kaže na tunel, število skokov se ponavlja ali ne, eno mesto ima predpono, in imate pot upravljanja, ki spremembo preživi. Če je katera od petih neznana, so ostale štiri ugibanja.