Wannear’t rûtes fan in dielde tunnel oerlaapje: hokker foarheaksel wint

Twa profilen fan in dielde tunnel, twa partikuliere foarheaksels en ien host dy’t beide opeaskje. It symptoom is selden in skjinne flater: in tsjinst wurket moandei, rint yn in tiidlimyt nei’t de twadde klant wer ferbynt, en wurket wer nei in werstart. De folchoarder wêryn’t jo de klanten ferbûn hawwe, bepaalt de útkomst net, en de folchoarder fan de rigen yn de ynterfaasje fan de klant likegoed net. Fier dizze kontrôles yn folchoarder út, en stopje by de earste dy’t net stiet, want de lettere hawwe pas sin as de eardere wier binne.

1. Skriuw de bestimming en de boarne op

Begjin mei it krekte adres dêr’t de mislearjende oanfraach hinne giet, net de hostnamme en net de namme fan de applikaasje. Los de namme ien kear op, notearje elk antwurd en kies it antwurd dat de mislearjende stream echt brûkt. Notearje dan it lokale adres fan deselde stream, want it boarneadres kin feroarje hokker beliedsregel oerienkomt en dêrtroch hokker tabel rieplachte wurdt.

In oanfraach nei ien fan ferskate A-records kin mislearje wylst in sustersadres slagget, wat as in ûnstabile tunnel liket mar eins twa ferskillende paden binne. As de bestimming in namme is mei ferskate antwurden, testje dan elk antwurd apart foardat jo wat feroarje.

2. Freegje de kearn hokker rûte er keazen hat

Lês de rûtetabel net en lied it antwurd net ôf. Stel deselde fraach dy’t de stack stelt, mei itselde boarneadres: ip route get 10.20.4.10 from 10.8.0.2 op Linux, of Find-NetRoute -RemoteIPAddress 10.20.4.10 yn PowerShell. De útfier neamt de rûte dy’t echt brûkt wurde soe, en dat is faak net dy’t jo ferwachten by it lêzen fan de tabel.

Under rûtes dy’t oerienkomme, wint normaal it mear spesifike foarheaksel: in /24 ferslacht in /16 foar in adres dat yn beide leit. Tusken oerienkomsten fan gelikense lingte wint de legere metryk, en in rûte dy’t op in ferbining stiet dy’t del is, wurdt oerslein. Twa tunnels dy’t deselde /24 mei deselde metryk pushje binne in oar gefal: de kearn hâldt beide rûtes en kiest dertusken, sadat de útkomst ôfwikselje kin ynstee fan de folchoarder te folgjen wêryn’t de klanten ferbûn binne. Dat is krekt de sitewaasje dy’t it patroan moandei-werket-tiisdei-mislearret opsmyt, en op ’e nij ferbine yn in oare folchoarder feroaret dat net.

3. Kontrolearje of in beliedsregel it sykjen om laat hat

Foardat de rûtetabel rieplachte wurdt, rint de kearn syn beliedsregels ôf. In regel kin ferkear fan in opjûne boarne, brûker of firewallmark nei in folslein oare tabel stjoere, sadat it winnende foarheaksel yn de haadtabel miskien nea rieplachte wurdt foar dy stream. ip rule show listet se yn folchoarder fan beoardieling, en ip route show table 100 lit sjen wat de keazen tabel echt befettet.

Hjir lizze twa fallen. In regel dy’t nei in lege tabel wiist, jout in sykjen dat trochfalt nei de folgjende regel, sadat de regel liket oft er neat docht. De oare is it prioriteitsnûmer sels: regels wurde yn oprinnende folchoarder lêzen, en de ynboude wearden binne 0 local, 32766 main en 32767 default. In regel mei in nûmer ûnder 32767 wurdt foar de standertregel rieplachte dy’t alles fangt. In regel mei in nûmer boppe 32767 stiet der efter en wurdt allinnich berikt as gjin eardere tabel antwurdet, wat in normale standertrûte yn main foarkomt, sadat er yn de praktyk nea berikt wurdt en stil neat docht wylst er ynstallearre liket. As de klant in regel en in rûte skreaun hat, kontrolearje beide, en kontrolearje se wer nei in nije ferbining, want in oerskreaun profyl kin in twadde regel mei in oare prioriteit tafoegje.

4. Skied in rûte-lykstand fan in dûbele adresplan

Soms is it foarheaksel hielendal net it probleem. Twa lokaasjes dy’t beide 192.168.1.0/24 brûke, betsjutte dat itselde adres twa ferskillende hosts oanjout, en gjin rûte kin se útinoar hâlde. In hostrûte nei ien fan de twa antwurden wurket allinnich oant it oare lokaasje foar deselde namme antwurdet, en dan wurdt de útsûndering stil de flater.

It teken is dat it bestimmingsadres op beide paden identyk is en allinnich de bedoelde eigner ferskilt. Dat is in beslissing oer it adresplan, net in oanpassing fan de rûtes: nûmerje ien kant op ’e nij, set ien kant efter in gateway dy’t oerset, of berik it twadde lokaasje fia in proxy dy’t syn eigen nammen oplost. In standertrûte ferleegje of host-útsûnderingen opstapelje ferpleatst de botsing allinnich.

5. Befêstigje dat de oplosser it mei de rûte iens is

In namme dy’t nei it ferkearde partikuliere adres oplost, jout elk symptoom fan in rûtekonflikt en net ien fan de oarsaken. Fergelykje it antwurd dat de host krijt mei it adres dat de bestimming echt brûkt, en kontrolearje hokker oplosser antwurde. As de tunnel in oplosser pusht, soe de klant dy foar de streamen dy’t de tunnel brûke ynstallearje moatte; docht er dat net, dan bliuwt de host de lokale oplosser freegje, dy’t antwurdzje kin út in sykdomein of út in bewarre record.

Freegje de oplosser direkt en notearje de tsjinner dy’t antwurde. In bewarre antwurd mei in koarte TTL kin ek ferklearje wêrom’t de earste oanfraach nei in nije ferbining oars gedraacht as de fyfde.

6. Ferbynje op ’e nij, besjoch de tapaste steat, en testje dan beide streamen

Nei in korreksje, ferbynje op ’e nij en besjoch wat de klant echt ynstallearre hat ynstee fan de profylbewurker te fertrouwen. Lês de regels, de tabellen en it dêrút folgjende antwurd fan ip route get nochris. In twadde klant kin by it ferbinen syn eigen rûte opnij ynstallearje en it konflikt wer meitsje, wêrom’t de steatkontrôle nei de ferbining fan de lêste klant barre moat, net dêrfoar.

Testje twa streamen, net ien: de oanfraach dy’t earder mislearre, en in boarne dy’t de oare tunnel brûke moat. Al it partikuliere ferkear nei ien ferbining ferpleatse lit de earste test slagje wylst er de twadde brekt, en allinnich in pearze test fangt dat. Notearje elke útsûndering dy’t jo hâlde, mei de bestimming en de reden, sadat de folgjende persoan in bewuste hostrûte fan in oerbliuwsel skiede kin.