Nakatayo pa ang tunel, wala na ang ruta: paghihiwalay ng dalawang pagkabigo ng VPN

Isang host ang hindi maabot habang ang interface ng tunel ay nag-uulat pa rin na naitatag ito, at ang dalawang obserbasyon ay hindi magkasalungat. May nag-alis ng landas na ginagamit ng trapiko: nagbawi ang kapitbahay ng prefix nito, inalis ang sinusubaybayang static na ruta, o may ibang rutang naging ginustong. Ang asosasyon ng seguridad ay maaaring manatiling ganap na malusog sa tatlong kaso. Ang paghihiwalay ng mga pangyayari ay nangangahulugang tanungin kung aling antas ang unang nagbago, hindi kung nabigo ang VPN.

Tatlong yugto na mukhang isang pangyayari

Ang desisyon sa pagruruta ay may tatlong yugto. Ang prefix ay tinatanggap, pinipili bilang pinakamahusay, at ikinakabit sa talahanayan ng pagpapasa. Bawat yugto ay maaaring mabigo nang mag-isa, at ang pagkabigo ay mukhang pareho mula sa panig ng aplikasyon. Ang prefix na natutunan ngunit natalo sa pagpili ay hindi matukoy mula sa isa na hindi kailanman dumating kapag ang tanging ebidensiyang tinitingnan mo ay ang talahanayan ng pagpapasa.

Kaya ang unang tanong ay aling yugto ang nasira, hindi aling protocol ang may kasalanan. Ang sagot ang magpapasya kung kanino ang insidente at aling kasangkapan ang gagamitin ng susunod na pagsusuri.

Basahin muna ang naka-install na ruta

Tanungin ang kernel kung saan talaga pupunta ang trapiko patungo sa nabigong destinasyon. ip route get ay nagpi-print ng susunod na hop, ang interface at ang source address na gagamitin ng kernel, at sumasagot ito para sa isang destinasyon hindi para sa buong talahanayan. Kung pinangalanan ng sagot ang tunel, naniniwala pa rin ang talahanayan ng pagpapasa na umiiral ang landas at ang problema ay nasa itaas nito.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Ang sagot na «unreachable» ay nangangahulugang walang naka-install na ruta, na tumuturo sa pagbawi o sa kulang na pag-install. Ang sagot na nagpapangalan ng pisikal na interface ay nangangahulugang umalis ang trapiko sa tunel nang walang nagpasya, at ang susunod na pagsusuri ay ang priority na nanalo. Ang sagot na nagpapangalan ng tunel habang naglalaho pa rin ang mga packet ay tumuturo nang mas malalim sa landas, sa pag-filter o sa kabilang dulo.

Pagkatapos tingnan ang sariling pananaw ng protocol

Ang daemon ng pagruruta ay may hawak na higit sa isang talahanayan, at ang kawili-wiling paghahambing ay sa pagitan nila. Para sa BGP, ang estado ng session ng kapitbahay, ang natanggap na anunsyo at ang naka-install na ruta ay tatlong magkakahiwalay na ebidensiya. Ang prefix ay maaaring umupo sa natanggap na talahanayan at hindi kailanman umabot sa kernel dahil nananalo ang rutang may mas maikling administratibong distansya. Suriin ang tatlo bago magpasya na tumigil ang kabilang panig sa pag-anunsyo.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

Sinasabi ng buod kung naitatag ang session, sinasabi ng pananaw ayon sa prefix kung tinanggap ang prefix, at sinasabi ng paghahanap sa kernel kung naikabit ito. Ang pagbasa sa kanila sa ganoong pagkakasunod-sunod ay pumipigil na mapagkamalan ang pagyanig ng session bilang pagbawi, at ang pagbawi bilang pagtanggi dahil sa patakaran.

Kapag hindi nagkasundo ang mga orasan

Ilagay ang log ng tunel, ang log ng pagruruta at ang unang pagkabigo ng aplikasyon sa isang linya ng panahon gamit ang kanilang tunay na mga time zone. Kung ang pagkawala ng kapitbahay ang mauna, ibinaba ng tunel ang ruta kasama nito. Kung ang pagbawi ang mauna, nagbago ang pagruruta at tumugon ang tunel pagkatapos. Iba't ibang insidente ito na may iba't ibang may-ari, at ang pagkakasunod-sunod ang buong natuklasan.

Isang minutong paglihis ng orasan ay sapat na para baliktarin ang konklusyong iyon, kaya kumpirmahin ang time zone at ang offset bago magtiwala sa pagkakasunod-sunod. Ang mga device na naglo-log sa lokal na oras na walang offset ang karaniwang pinagmumulan ng isang tiwala ngunit maling linya ng panahon.

Pagbawi nang walang loop

Pagkatapos ng pagbawi, dalawang landas ang maaaring maging karapat-dapat: ang pipiliin ng protocol at ang ipi-pin mo sa kamay. Tanging ang una ang desisyong patuloy na ginagawa ng network para sa iyo, kaya ang manu-manong ruta ay pansamantalang hakbang hindi isang plano sa pagbawi. Ang alternatibong anunsyo ay hindi rin nagpapanatili ng estado ng firewall o NAT para sa session na naitatag na, kaya ang mga bagong daloy ay maaaring gumana habang ang orihinal ay nananatiling sira. Kumpirmahin kung aling backup ang dapat maging aktibo at kung tatanggapin ng malayong site ang landas ng pagbabalik sa pamamagitan nito.

Huwag mag-install ng permanenteng static na override bago maunawaan kung bakit nangyari ang pagbawi. Ang shortcut na iyon ay maaaring mag-pin ng trapiko sa nabigong landas o tahimik na laktawan ang sinadyang patakaran sa pagruruta, at inililibing ang orihinal na dahilan sa ilalim ng bagong configuration. Subukan muli ang aplikasyon kapag naibalik na ang ruta, at kumpirmahin na ang piniling prefix ay may gumaganang landas ng data at hindi lamang isang entry sa isang talahanayan.