Tunnel püsib, marsruut kadus: kahe VPN-tõrke eristamine
Eesliite saab vastu võtta, valida ja paigaldada kolmes erinevas etapis. Lugege esmalt edastustabelit, seejärel protokollitabelit ja lõpuks kellasid.
Üks host muutub kättesaamatuks, samal ajal kui tunneli liides teatab endiselt, et see on loodud, ja need kaks tähelepanekut ei ole vastuolus. Miski eemaldas tee, mida liiklus kasutas: naaber võttis oma eesliite tagasi, jälgitud staatiline marsruut eemaldati või teine marsruut muutus eelistatumaks. Turvaassotsiatsioon võib kõigil kolmel juhul täiesti terveks jääda. Sündmuste eraldamine tähendab küsimist, milline kiht muutus esimesena, mitte kas VPN ebaõnnestus.
Kolm etappi, mis näevad välja nagu üks sündmus
Marsruudiotsusel on kolm etappi. Eesliide võetakse vastu, valitakse parimaks ja paigaldatakse edastustabelisse. Iga etapp võib iseseisvalt ebaõnnestuda ja tõrge näeb rakenduse poolelt ühesugune välja. Eesliidet, mis õpiti, kuid kaotas valiku, ei saa eristada sellest, mis ei saabunud kunagi, kui ainus tõend, mida vaatate, on edastustabel.
Seetõttu on esimene küsimus, milline etapp purunes, mitte milline protokoll on süüdi. Vastus otsustab, kellele juhtum kuulub ja millist tööriista järgmine kontroll kasutab.
Lugege esmalt paigaldatud marsruuti
Küsige kernelilt, kuhu liiklus ebaõnnestunud sihtkohta tegelikult läheb. ip route get prindib järgmise hüppe, liidese ja lähteaadressi, mida kernel kasutaks, ning vastab ühe sihtkoha kohta, mitte kogu tabeli kohta. Kui vastus nimetab tunnelit, usub edastustabel endiselt, et tee on olemas, ja probleem asub selle kohal.
ip route get 10.20.5.10
ip route show 10.20.0.0/16
Vastus «unreachable» tähendab, et paigaldatud marsruuti pole üldse, mis viitab tagasivõtmisele või puuduvale paigaldusele. Füüsilist liidest nimetav vastus tähendab, et liiklus lahkus tunnelist ilma kellegi otsuseta, ja järgmine kontroll on eelistus, mis võitis. Tunnelit nimetav vastus ajal, mil paketid ikka kaovad, viitab tee kaugemale osale, filtreerimisele või vastasküljele.
Seejärel vaadake protokolli enda vaadet
Marsruutimisdemon hoiab rohkem kui ühte tabelit ja huvitav võrdlus on nende vahel. BGP puhul on naabersessiooni olek, vastuvõetud teadaanne ja paigaldatud marsruut kolm eraldi tõendit. Eesliide võib seista vastuvõetud tabelis ja mitte kunagi kerneleni jõuda, sest lühema administratiivse kaugusega marsruut võidab. Kontrollige kõiki kolme, enne kui järeldate, et teine pool lõpetas teavitamise.
vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"
Kokkuvõte ütleb, kas sessioon on loodud, eesliitepõhine vaade ütleb, kas eesliide võeti vastu, ja kerneli otsing ütleb, kas see paigaldati. Nende lugemine selles järjekorras hoiab ära sessiooni väreluse segamise tagasivõtmisega ja tagasivõtmise segamise poliitikapõhise keeldumisega.
Kui kellad ei nõustu
Pange tunneli logi, marsruutimislogi ja rakenduse esimene tõrge ühele ajateljele, kasutades nende tegelikke ajavööndeid. Kui naabri kadu tuleb esimesena, tõmbas tunnel marsruudi koos endaga maha. Kui tagasivõtmine tuleb esimesena, muutus marsruutimine ja tunnel reageeris hiljem. Need on erinevad juhtumid erinevate omanikega ja järjekord on kogu leid.
Üks minut kella nihkumist on piisav, et see järeldus ümber pöörata, seega kinnitage ajavöönd ja nihe enne, kui järjestust usaldate. Seadmed, mis logivad kohalikus ajas ilma nihketa, on tavaline enesekindla, kuid vale ajatelje allikas.
Taastamine ilma silmuseta
Pärast tagasivõtmist võivad kõne alla tulla kaks teed: see, mille protokoll valib, ja see, mille kinnitate käsitsi. Ainult esimene on otsus, mida võrk teie eest jätkuvalt teeb, mistõttu on käsitsi marsruut ajutine lahendus, mitte taastamisplaan. Alternatiivne teadaanne ei säilita ka juba loodud sessiooni tulemüüri ega NAT-i olekut, seega uued vood võivad töötada, samal ajal kui algne jääb katki. Kinnitage, milline varu peaks aktiivseks saama ja kas kaugkoht aktsepteerib tagasiteed selle kaudu.
Ärge paigaldage alalist staatilist alistust enne, kui mõistate, miks tagasivõtmine juhtus. See otsetee võib kinnitada liikluse ebaõnnestunud teele või vaikselt mööda minna kavatsuslikust marsruutimispoliitikast ning matab algse põhjuse uue konfiguratsiooni alla. Testige rakendust uuesti, kui marsruut on taastatud, ja kinnitage, et valitud eesliitel on töötav andmetee, mitte ainult kirje tabelis.