Kur rrugët e tunelit të ndarë mbivendosen: cili prefiks fiton

Dy profile të tunelit të ndarë, dy prefikse private dhe një host që të dy e pretendojnë. Simptoma rrallë është një dështim i pastër: një shërbim punon të hënën, skadon pasi klienti i dytë rilidhet dhe punon përsëri pas një rindezjeje. Rendi në të cilin lidhët klientët nuk vendos rezultatin, as rendi i rreshtave në ndërfaqen e klientit. Kryeni këto kontrolle me radhë dhe ndaloni në të parën që nuk qëndron, sepse ato pasardhëse kanë kuptim vetëm kur ato të mëparshmet janë të vërteta.

1. Shkruani destinacionin dhe burimin

Filloni me adresën e saktë ku shkon kërkesa që dështon, jo me emrin e hostit dhe jo me emrin e aplikacionit. Zgjidhni emrin një herë, shënoni çdo përgjigje dhe zgjidhni atë që rryma që dështon përdor në të vërtetë. Më pas shënoni adresën lokale të së njëjtës rrymë, sepse adresa burimore mund të ndryshojë cili rregull i politikës përputhet dhe për rrjedhojë cila tabelë konsultohet.

Një kërkesë drejt njërit prej disa regjistrave A mund të dështojë ndërsa një adresë motër ka sukses, gjë që duket si tunel i paqëndrueshëm dhe në të vërtetë janë dy shtigje të ndryshme. Nëse destinacioni është një emër me disa përgjigje, provoni secilën përgjigje veçmas përpara se të ndryshoni diçka.

2. Pyetni bërthamën cilën rrugë zgjodhi

Mos lexoni tabelën e rrugëve dhe mos e nxirrni përgjigjen prej saj. Bëni të njëjtën pyetje që bën stivi, me të njëjtën adresë burimore: ip route get 10.20.4.10 from 10.8.0.2 në Linux, ose Find-NetRoute -RemoteIPAddress 10.20.4.10 në PowerShell. Dalja emërton rrugën që do të përdorej vërtet, dhe shpesh nuk është ajo që prisnit kur lexonit tabelën.

Ndër rrugët që përputhen, zakonisht fiton prefiksi më specifik: një /24 mposht një /16 për një adresë që ndodhet në të dyja. Midis përputhjeve me të njëjtën gjatësi fiton metrika më e ulët, dhe një rrugë e instaluar në një lidhje që është jashtë anashkalohet. Dy tunele që shtyjnë të njëjtin /24 me të njëjtën metrikë janë një rast tjetër: bërthama mban të dyja rrugët dhe zgjedh midis tyre, kështu që rezultati mund të alternojë në vend që të ndjekë rendin në të cilin u lidhën klientët. Pikërisht kjo situatë prodhon modelin e hënë-punon-e-martë-dështon, dhe rilidhja në një rend tjetër nuk e ndryshon.

3. Kontrolloni nëse një rregull i politikës e ridrejtoi kërkimin

Para se të konsultohet tabela e rrugëve, bërthama kalon nëpër rregullat e saj të politikës. Një rregull mund të dërgojë trafikun nga një burim, përdorues ose shenjë e caktuar e murit të zjarrit në një tabelë krejt tjetër, kështu që prefiksi fitues në tabelën kryesore mund të mos konsultohet kurrë për atë rrymë. ip rule show i liston ato sipas rendit të vlerësimit, dhe ip route show table 100 tregon çfarë përmban vërtet tabela e zgjedhur.

Këtu fshihen dy kurthe. Një rregull që tregon një tabelë të zbrazët prodhon një kërkim që bie te rregulli pasardhës, kështu që rregulli duket se nuk bën asgjë. Tjetri është vetë numri i përparësisë: rregullat lexohen në rend rritës, dhe vlerat e integruara janë 0 local, 32766 main dhe 32767 default. Një rregull me numër nën 32767 konsultohet para rregullit të parazgjedhur që kap gjithçka. Një rregull me numër mbi 32767 qëndron pas tij dhe arrihet vetëm kur asnjë tabelë e mëparshme nuk përgjigjet, gjë që një rrugë normale e parazgjedhur në main e pengon, kështu që në praktikë nuk arrihet kurrë dhe nuk bën asgjë në heshtje ndërsa duket e instaluar. Nëse klienti ka shkruar një rregull dhe një rrugë, kontrolloni të dyja, dhe kontrollojini përsëri pas një rilidhjeje, sepse një profil i rishkruar mund të shtojë një rregull të dytë me përparësi tjetër.

4. Ndani një barazi rrugësh nga një plan adresash i dubluar

Ndonjëherë prefiksi nuk është fare problemi. Dy vende që të dy përdorin 192.168.1.0/24 nënkuptojnë se e njëjta adresë identifikon dy hoste të ndryshëm, dhe asnjë rrugë nuk mund t'i dallojë. Një rrugë hosti drejt njërës prej dy përgjigjeve punon vetëm derisa vendi tjetër të përgjigjet për të njëjtin emër, dhe atëherë përjashtimi bëhet në heshtje vetë defekti.

Treguesi është se adresa e destinacionit është identike në të dy shtigjet dhe ndryshon vetëm pronari i synuar. Ky është një vendim për planin e adresave, jo një rregullim i rrugëtimit: rinumëroni njërën anë, vendosni njërën anë pas një portë që përkthen, ose arrini vendin e dytë përmes një përfaqësuesi që i zgjidh vetë emrat e tij. Ulja e një rrugë të parazgjedhur ose grumbullimi i përjashtimeve për hoste thjesht e zhvendos përplasjen.

5. Konfirmoni se zgjidhësi pajtohet me rrugën

Një emër që zgjidhet në adresën e gabuar private prodhon çdo simptomë të një konflikti rrugëtimi dhe asnjë nga shkaqet e tij. Krahasoni përgjigjen që merr hosti me adresën që destinacioni përdor vërtet, dhe kontrolloni cili zgjidhës u përgjigj. Nëse tuneli shtyn një zgjidhës, klienti duhet ta instalojë atë për rrymat që përdorin tunelin; nëse jo, hosti vazhdon t'i pyesë zgjidhësit lokal, i cili mund të përgjigjet nga një domen kërkimi ose nga një regjistrim i ruajtur në memorie.

Pyetni zgjidhësin drejtpërdrejt dhe shënoni serverin që u përgjigj. Një përgjigje e ruajtur në memorie me TTL të shkurtër mund të shpjegojë gjithashtu pse kërkesa e parë pas një rilidhjeje sillet ndryshe nga e pesta.

6. Rilidhuni, shqyrtoni gjendjen e aplikuar, pastaj provoni të dyja rrymat

Pas një korrigjimi, rilidhuni dhe shqyrtoni çfarë ka instaluar vërtet klienti në vend që të besoni redaktorin e profileve. Lexoni përsëri rregullat, tabelat dhe përgjigjen e ip route get që rezulton. Një klient i dytë mund të riinstalojë rrugën e vet kur lidhet dhe të rikrijojë konfliktin, prandaj kontrolli i gjendjes duhet të bëhet pasi lidhet klienti i fundit, jo përpara.

Provoni dy rryma, jo një: kërkesën që dështonte më parë dhe një burim që supozohet të përdorë tunelin tjetër. Zhvendosja e të gjithë trafikut privat në një lidhje do ta bëjë provën e parë të kalojë ndërsa thyejnë të dytën, dhe vetëm një provë e çiftuar e kap këtë. Shënoni çdo përjashtim që mbani, me destinacionin dhe arsyen, që personi tjetër të mund të dallojë një rrugë hosti të qëllimshme nga një e mbetur.