Kako razlikovati petlju usmjeravanja od lepršanja rute na VPN lokacijama

Dvije lokacije, jedan tunel i udaljeni prefiks koji neko vrijeme odgovara, a zatim umukne. Refleks je nazvati to petljom usmjeravanja, a ponekad to upravo i jest. No petlja i lepršava ruta daju istu pritužbu, a traže suprotne popravke: jedno je odluka o prosljeđivanju koja nikada ne završava, drugo je prefiks koji stalno napušta tablicu. Tri zapažanja ih razdvajaju, a sva tri možete prikupiti iz naredbenog retka gatewaya prije nego što dotaknete filtar ili ponovno pokrenete tunel.

Petlja se odlučuje skok po skok. Lokacija A bira B kao sljedeći skok za odredište, B bira A za isto odredište, a paket istječe na TTL-u nakon dva kruga. Lepršanje pak odlučuje protokol usmjeravanja: prefiks se povlači, ponovno instalira ili zamjenjuje alternativnim sljedećim skokom, pa neki paketi uopće nemaju rutu, dok drugi slijede posve dobru.

Tri provjere koje rješavaju pitanje

Da biste donijeli prvu odluku, nije vam potrebno hvatanje paketa. Potrebni su vam stanje prefiksa na oba kraja, sljedeći skok koji svaka strana bira i broj skokova koji se ili ponavlja ili ne. Ako prefiks ostaje instaliran s istim sljedećim skokom dok promet ne uspijeva, petlja živi u putu prosljeđivanja. Ako prefiks nestane i vrati se, kvar je iznad prosljeđivanja i popravak pripada protokolu usmjeravanja, a ne statičnoj ruti.

Jedno upozorenje prije početka. Ako ovo čitate preko tunela koji radi petlju, vaša sesija umire u trenutku kada promijenite rutu. Otvorite konzolu ili put upravljanja koji ne ovisi o prefiksu koji ćete popravljati.

Provjera prva: je li prefiks stabilan ili se koprca

Pitajte kernel što je instalirao, a ne što obećava konfiguracijska datoteka. Na Linux gatewayu ip route get 10.20.30.40 izvodi isto pretraživanje koje izvodi put prosljeđivanja, uključujući tablice pravila, dok ip route show 10.20.30.0/24 prikazuje sam zapis. ip monitor route prenosi svaku promjenu u trenutku nastanka, što je najbrži način da gledate kako prefiks dolazi i odlazi.

Na usmjerivaču s FRR ili BIRD zanimljiva nije tablica prosljeđivanja. show ip bgp 10.20.30.0/24 vraća odabrani put i njegovo vrijeme rada; vrijeme rada koje se stalno resetira svakih nekoliko minuta je lepršanje koje možete imenovati, a ne petlja. show ip bgp summary prikazuje stanje susjeda i broj prefiksa, pa susjed koji stalno pada skida krivnju s puta prosljeđivanja.

Zapišite odgovor prije nego što bilo što promijenite. Stabilnost deset minuta dok su pingovi propadali i nestajanje četiri puta u deset minuta vode do različitih sljedećih koraka. Drugi slučaj čini svaku teoriju o statičnoj ruti nevažnom.

Provjera druga: pokazuje li sljedeći skok natrag u tunel dolaska

Petlja traži da se dva gatewaya slože. Na lokaciji koja prima paket pogledajte rutu kojom će paket izaći: ip route get 10.20.30.40 from 10.10.5.20 s pravom izvornom adresom, jer pravilo politike može odgovoriti drukčije od glavne tablice. Zatim ponovite pretraživanje na lokaciji koja ga je poslala. Ako svaka strana bira onu drugu kao sljedeći skok za isti prefiks, petlja je dokazana i nikakvo hvatanje neće ništa dodati.

Uzrok je gotovo uvijek oglas koji nije smio prijeći tunel. Zadana ruta redistribuirana u tunel, agregat koji pokriva vlastitu podmrežu udaljene lokacije ili statična ruta prema partneru za svaki slučaj — svi stvaraju isti uzajamni sljedeći skok. Tunel može biti potpuno uspostavljen i ipak nositi promet u krug; strongSwanove bilješke o prosljeđivanju opisuju usmjerivačku stranu tog zahtjeva.

WireGuard zaslužuje vlastitu bilješku jer nema oglasa kojeg biste okrivili. wg show navodi AllowedIPs za svakog partnera, a kernel prihvaća odredište za partnera samo ako pada unutar tog raspona. Petlja je ondje preklapajući raspon AllowedIPs ili statična ruta koja pokazuje natrag preko sučelja, pa popravak živi samo na ta dva mjesta.

Provjera treća: čitajte broj skokova, ne zvjezdice

traceroute -n -I 10.20.30.40 i mtr -n -r -c 20 10.20.30.40 oba pokazuju put, a ICMP način često preživi filtriranje koje jede UDP probe. Petlja izgleda kao kratki ponavljajući slijed istih dvaju gateway adresa, pri čemu TTL svaki put raste. Ispad izgleda kao zvjezdice nakon zadnjeg gatewaya koji je odgovorio, a jedan tihi skok nije dokaz ničega.

Kada je put dvosmislen, čitajte TTL na žici. tcpdump -ni any -vv icmp na oba gatewaya pokazuje TTL svakog paketa i izvornu adresu svakog odgovora o isteku vremena. Ako paket stigne na udaljenu lokaciju s TTL-om nižim od broja skokova koje put može sadržavati, nešto dodaje skokove koje vam traceroute ne pokazuje, a to se događa kada vatrozid jedne lokacije odgovara na probe u ime druge.

Popravite vlasnika prefiksa, zatim provjerite oba smjera

Odlučite koja lokacija stvara odredište i koje su tranzitne putanje dopuštene, pa promijenite oglas ili statičnu rutu kod tog vlasnika. Ispravljanje prijemne lokacije primamljivo je i obično pogrešno: skriva petlju za jedan prefiks i ostavlja loš oglas na mjestu za sljedeći. Oznake ruta, distribucijske liste i pravila split-horizon postoje da to zaustave na izvoru i jeftinija su od filtra koji odgovara jednom prefiksu.

Nakon promjene provjerite odlazni i povratni smjer odvojeno, jer petlja može biti zamijenjena crnom rupom bez ikakvog vidljivog poboljšanja simptoma. Pokrenite ip route get s oba kraja, pošaljite promet s hosta koji nije gateway i ostavite ip monitor route da radi barem jedan timer zadržavanja kako se lepršanje ne bi zamijenilo za popravak.

Prije nego što bilo što promijenite, potvrdite ovih pet točaka: prefiks je stabilan ili se koprca, sljedeći skok na oba kraja pokazuje na tunel, broj skokova se ponavlja ili ne, jedna lokacija posjeduje prefiks i imate put upravljanja koji preživljava promjenu. Ako je bilo koja od pet nepoznata, ostale četiri su nagađanja.