Kada se rute podijeljenog tunela preklapaju: koji prefiks pobjeđuje

Dva profila podijeljenog tunela, dva privatna prefiksa i jedan host koji oba polažu. Simptom rijetko je čist kvar: usluga radi u ponedjeljak, prestane odgovarati nakon ponovnog spajanja drugog klijenta i ponovno radi nakon restarta. Redoslijed kojim ste spojili klijente ne odlučuje o ishodu, kao ni redoslijed redova u sučelju klijenta. Izvedite ove provjere redom i zaustavite se na prvoj koja ne vrijedi, jer kasnije imaju smisla samo kad su prethodne istinite.

1. Zapišite odredište i izvor

Počnite s točnom adresom na koju ide neuspjeli zahtjev, a ne s imenom hosta i ne s imenom aplikacije. Razriješite ime jednom, zabilježite svaki odgovor i odaberite onaj koji neuspjeli tok stvarno koristi. Zatim zabilježite lokalnu adresu istog toka, jer adresa izvora može promijeniti koje pravilo politike se podudara i time koja se tablica pregledava.

Zahtjev koji ide na jedan od nekoliko A zapisa može neuspjeti dok susjedna adresa uspijeva, što izgleda kao nestabilan tunel, a zapravo su dva različita puta. Ako je odredište ime s nekoliko odgovora, testirajte svaki odgovor zasebno prije nego što išta promijenite.

2. Pitajte jezgro koju je rutu odabralo

Ne čitajte tablicu ruta i ne izvodite zaključak. Postavite isto pitanje koje postavlja stog, s istom adresom izvora: ip route get 10.20.4.10 from 10.8.0.2 na Linuxu ili Find-NetRoute -RemoteIPAddress 10.20.4.10 u PowerShellu. Izlaz navodi rutu koja bi se stvarno koristila, a to često nije ona koju ste očekivali čitajući tablicu.

Među rutama koje se podudaraju obično pobjeđuje specifičniji prefiks: /24 pobjeđuje /16 za adresu unutar oba. Između podudaranja iste dužine pobjeđuje niža metrika, a ruta instalirana na isključenom sučelju se preskače. Dva tunela koji guraju isti /24 s istom metrikom drugi su slučaj: jezgro zadržava obje rute i bira među njima, pa ishod može izmjenjivati umjesto da slijedi redoslijed kojim su se klijenti spajali. To je upravo situacija koja stvara obrazac da u ponedjeljak radi a u utorak ne, i ponovno spajanje drugim redoslijedom to ne mijenja.

3. Provjerite da li je pravilo politike preusmjerilo pretragu

Prije nego što se pregleda tablica ruta, jezgro prolazi kroz svoja pravila politike. Pravilo može poslati saobraćaj s određenog izvora, korisnika ili firewall oznake u posve drugu tablicu, pa se pobjednički prefiks u glavnoj tablici možda nikada ne pregleda za taj tok. ip rule show ih navodi redom ocjenjivanja, a ip route show table 100 pokazuje šta odabrana tablica stvarno sadrži.

Ovdje vrebaju dvije zamke. Pravilo koje pokazuje na praznu tablicu stvara pretragu koja propada na sljedeće pravilo, pa pravilo izgleda kao da ne radi ništa. Druga je sam broj prioriteta: pravila se čitaju uzlazno, a ugrađene vrijednosti su 0 local, 32766 main i 32767 default. Pravilo s brojem ispod 32767 pregledava se prije sveobuhvatnog zadanog pravila. Pravilo s brojem iznad 32767 stoji iza njega i dosegne se samo kad nijedna ranija tablica ne odgovori, što normalna zadana ruta u main sprječava, pa se u praksi nikada ne dosegne i tiho ne radi ništa dok izgleda instalirano. Ako je klijent napisao pravilo i rutu, provjerite oboje i provjerite ih ponovo nakon ponovnog spajanja, jer prepisani profil može dodati drugo pravilo s drugim prioritetom.

4. Odvojite izjednačenje ruta od dupliciranog plana adresa

Ponekad prefiks uopšte nije problem. Dvije lokacije koje koriste 192.168.1.0/24 znače da ista adresa označava dva različita hosta i nijedna ruta ih ne može razlikovati. Ruta do hosta prema jednom od dva odgovora radi samo dok druga lokacija ne odgovori za isto ime, a tada izuzetak tiho postaje greška.

Znak je da je adresa odredišta identična na oba puta i da se razlikuje samo namjeravani vlasnik. To je odluka o planu adresa, a ne podešavanje ruta: prenumerišite jednu stranu, stavite jednu stranu iza mrežnog prolaza koji prevodi, ili dohvatite drugu lokaciju kroz proxy koji sam razrješava svoja imena. Spuštanje zadane rute ili gomilanje izuzetaka za hostove samo premješta sudar na drugo mjesto.

5. Potvrdite da se razrješivač slaže s rutom

Ime koje se razrješava na pogrešnu privatnu adresu proizvodi sve simptome sukoba ruta i nijedan njegov uzrok. Uporedite odgovor koji host dobije s adresom koju odredište stvarno koristi i provjerite koji je razrješivač odgovorio. Ako tunel gura razrješivač, klijent ga treba instalirati za tokove koji koriste tunel; ako ne, host nastavlja pitati lokalni razrješivač, koji može odgovoriti iz domene pretrage ili iz keširanog zapisa.

Pitajte razrješivač direktno i zabilježite server koji je odgovorio. Keširani odgovor s kratkim TTL-om takođe može objasniti zašto se prvi zahtjev nakon ponovnog spajanja ponaša drugačije od petog.

6. Ponovo se spojite, pregledajte primijenjeno stanje, pa testirajte oba toka

Nakon ispravke ponovo se spojite i pregledajte šta je klijent stvarno instalirao umjesto da vjerujete uređivaču profila. Pročitajte ponovo pravila, tablice i dobijeni odgovor ip route get. Drugi klijent može ponovo instalirati svoju rutu pri spajanju i ponovno stvoriti sukob, zato provjera stanja mora uslijediti nakon spajanja posljednjeg klijenta, a ne prije.

Testirajte dva toka, ne jedan: zahtjev koji je prije neuspijevao i resurs koji bi trebao koristiti drugi tunel. Prebacivanje cjelokupnog privatnog saobraćaja na jednu vezu učinit će prvi test uspješnim, ali će pokvariti drugi, a to hvata samo upareni test. Zabilježite svaki izuzetak koji zadržite, s odredištem i razlogom, kako bi sljedeća osoba mogla razlikovati namjernu rutu do hosta od preostale.