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

Dva profila podijeljenog tunela, dva privatna prefiksa i jedno računalo koje oba polažu. Simptom rijetko je čist kvar: usluga radi u ponedjeljak, prestane odgovarati nakon ponovnog spajanja drugog klijenta i proradi nakon restarta. Redoslijed kojim ste spojili klijente ne odlučuje o ishodu, kao ni redoslijed redaka u klijentovu sučelju. Provedite ove provjere redom i zaustavite se na prvoj koja ne vrijedi, jer kasnije imaju smisla tek kad su prethodne istinite.

1. Zapišite odredište i izvor

Pođite od točne adrese na koju ide neuspjeli zahtjev, a ne od imena računala ni od imena aplikacije. Razriješite ime jednom, zabilježite svaki odgovor i odaberite onaj koji neuspjeli tok doista rabi. Zatim zabilježite lokalnu adresu istog toka, jer adresa izvora može promijeniti koje se pravilo politike podudara i time koja se tablica pregledava.

Zahtjev upućen na jedan od nekoliko A zapisa može ne uspjeti dok srodna adresa uspijeva, što izgleda kao nestabilan tunel, a zapravo su dva različita puta. Ako je odredište ime s nekoliko odgovora, isprobajte svaki odgovor zasebno prije nego što išta promijenite.

2. Pitajte jezgru koju je rutu odabrala

Nemojte čitati tablicu ruta i iz nje izvoditi odgovor. 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 doista rabila, a to često nije ona koju ste očekivali čitajući tablicu.

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

3. Provjerite je li pravilo politike preusmjerilo pretragu

Prije nego što se pregleda tablica ruta, jezgra prolazi kroz svoja pravila politike. Pravilo može poslati promet s određenog izvora, korisnika ili oznake vatrozida 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 što odabrana tablica doista 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 čini 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 zadanog pravila koje hvata sve. Pravilo s brojem iznad 32767 stoji iza njega i doseže 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 čini ništa dok izgleda instalirano. Ako je klijent napisao pravilo i rutu, provjerite oboje i provjerite ih ponovno nakon ponovnog spajanja, jer prepisani profil može dodati drugo pravilo s drukčijim prioritetom.

4. Razdvojite izjednačenje ruta od udvostručenog plana adresa

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

Znak je da je adresa odredišta jednaka na obama putovima i da se razlikuje samo namjeravani vlasnik. To je odluka o planu adresa, a ne podešavanje usmjeravanja: prenumerirajte jednu stranu, stavite jednu stranu iza pristupnika koji prevodi ili dohvatile drugu lokaciju kroz proxy koji sam razrješava svoja imena. Spuštanje zadane rute ili gomilanje iznimaka za računala samo premješta sukob na drugo mjesto.

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

Ime koje se razrješava na pogrešnu privatnu adresu stvara svaki simptom sukoba usmjeravanja i nijedan njegov uzrok. Usporedite odgovor koji računalo dobije s adresom koju odredište doista rabi i provjerite koji je razrješivač odgovorio. Ako tunel gura razrješivač, klijent bi ga trebao instalirati za tokove koji rabe tunel; ako ne, računalo nastavlja pitati lokalni razrješivač, koji može odgovoriti iz domene pretraživanja ili iz predmemoriranog zapisa.

Pitajte razrješivač izravno i zabilježite poslužitelj koji je odgovorio. Predmemorirani odgovor s kratkim TTL-om također može objasniti zašto se prvi zahtjev nakon ponovnog spajanja ponaša drukčije od petoga.

6. Ponovno se spojite, pregledajte primijenjeno stanje, pa isprobajte oba toka

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

Isprobajte dva toka, ne jedan: zahtjev koji je prije ne uspijevao i resurs koji bi trebao rabiti drugi tunel. Premještanje svega privatnog prometa na jednu vezu pustit će prvi test, ali slomiti drugi, a to hvata samo upareni test. Zabilježite svaku iznimku koju zadržite, s odredištem i razlogom, kako bi sljedeća osoba mogla razlikovati namjernu rutu do računala od preostale.