Wanneer gesplete tonnelroetes oorvleuel: watter voorvoegsel wen

Twee gesplete-tonnelprofiele, twee private voorvoegsels en een gasheer wat albei opeis. Die simptoom is selde 'n skoon fout: 'n diens werk Maandag, hou op reageer nadat die tweede kliënt weer koppel, en werk weer ná 'n herstart. Die volgorde waarin jy die kliënte gekoppel het, bepaal nie die uitkoms nie, en die volgorde van die rye in die kliënt se koppelvlak ook nie. Voer hierdie kontroles in volgorde uit, en stop by die eerste een wat nie hou nie, want die latere maak eers sin sodra die vroeëre waar is.

1. Skryf die bestemming en die bron neer

Begin met die presiese adres waarheen die mislukte versoek gaan, nie die gasheernaam nie en nie die toepassing se naam nie. Los die naam een keer op, noteer elke antwoord en kies die een wat die mislukte vloei werklik gebruik. Noteer dan die plaaslike adres van dieselfde vloei, want die bronadres kan bepaal watter beleidsreël pas en dus watter tabel geraadpleeg word.

'n Versoek na een van verskeie A-rekords kan misluk terwyl 'n susteradres slaag, wat soos 'n wispelturige tonnel lyk maar in werklikheid twee verskillende paaie is. As die bestemming 'n naam met verskeie antwoorde is, toets elke antwoord afsonderlik voordat jy iets verander.

2. Vra die kern watter roete dit gekies het

Moenie die roetetabel lees en die antwoord aflei nie. Vra dieselfde vraag wat die stapel vra, met dieselfde bronadres: ip route get 10.20.4.10 from 10.8.0.2 op Linux, of Find-NetRoute -RemoteIPAddress 10.20.4.10 in PowerShell. Die uitset noem die roete wat werklik gebruik sou word, wat dikwels nie die een is wat jy uit die tabel verwag het nie.

Onder roetes wat pas, wen die meer spesifieke voorvoegsel gewoonlik: 'n /24 klop 'n /16 vir 'n adres binne albei. Tussen passinge van gelyke lengte wen die laer metriek, en 'n roete op 'n skakel wat af is, word oorgeslaan. Twee tonnels wat dieselfde /24 met dieselfde metriek druk, is 'n ander geval: die kern hou albei roetes en kies tussen hulle, so die uitkoms kan wissel in plaas van die volgorde volg waarin die kliënte gekoppel het. Dit is juis die situasie wat die patroon Maandag-werk-Dinsdag-faal lewer, en weer koppel in 'n ander volgorde verander dit nie.

3. Kyk of 'n beleidsreël die opsoek herlei het

Voordat die roetetabel geraadpleeg word, loop die kern sy beleidsreëls deur. 'n Reël kan verkeer van 'n gegewe bron, gebruiker of firewallmerk na 'n heeltemal ander tabel stuur, so die wen-voorvoegsel in die hoof-tabel word dalk nooit vir daardie vloei geraadpleeg nie. ip rule show lys hulle in evalueringsorde, en ip route show table 100 wys wat die gekose tabel werklik bevat.

Twee strikke lê hier. 'n Reël wat na 'n leë tabel wys, lewer 'n opsoek wat na die volgende reël deurval, so die reël lyk of dit niks doen. Die ander is die prioriteitsnommer self: reëls word in stygende orde gelees, en die ingeboude waardes is 0 local, 32766 main en 32767 default. 'n Reël met 'n nommer onder 32767 word voor die allesomvattende verstekreël geraadpleeg. 'n Reël met 'n nommer bo 32767 sit agter dit en word net bereik wanneer geen vroeëre tabel antwoord nie, wat 'n normale verstekroete in main verhoed, so in die praktyk word dit nooit bereik nie en doen dit stil niks terwyl dit geïnstalleer lyk. As die kliënt 'n reël en 'n roete geskryf het, kyk na albei, en kyk weer daarna ná 'n herkoppeling, want 'n herskrewe profiel kan 'n tweede reël met 'n ander prioriteit byvoeg.

4. Skei 'n roetegelykop van 'n gedupliseerde adresplan

Soms is die voorvoegsel glad nie die probleem nie. Twee terreine wat albei 192.168.1.0/24 gebruik, beteken dat dieselfde adres twee verskillende gashere aandui, en geen roete kan hulle onderskei nie. 'n Gasheerroete na een van die twee antwoorde werk net totdat die ander terrein vir dieselfde naam antwoord, en dan word die uitsondering stilweg die fout.

Die aanduiding is dat die bestemmingsadres op albei paaie identies is en net die bedoelde eienaar verskil. Dit is 'n adresplanbesluit, nie 'n roeteverstelling nie: hernommer een kant, sit een kant agter 'n vertalende poort of bereik die tweede terrein deur 'n instaanbediener wat sy eie name oplos. Om 'n verstekroete te verlaag of gasheeruitsonderings te stapel, skuif net die botsing rond.

5. Bevestig die oplosser stem met die roete ooreen

'n Naam wat na die verkeerde private adres oplos, lewer elke simptoom van 'n roetekonflik en nie een van die oorsake daarvan nie. Vergelyk die antwoord wat die gasheer kry met die adres wat die bestemming werklik gebruik, en kyk watter oplosser geantwoord het. As die tonnel 'n oplosser stoot, moet die kliënt dit installeer vir die vloei wat die tonnel gebruik; as dit nie doen nie, bly die gasheer die plaaslike oplosser vra, wat dalk uit 'n soekdomein of 'n gekaste rekord antwoord.

Vra die oplosser direk en noteer die bediener wat geantwoord het. 'n Gekaste antwoord met 'n kort TTL kan ook verduidelik waarom die eerste versoek ná 'n herkoppeling anders optree as die vyfde.

6. Koppel weer, ondersoek die toegepaste toestand en toets dan albei vloei

Ná 'n regstelling, koppel weer en ondersoek wat die kliënt werklik geïnstalleer het eerder as om die profielredigeerder te vertrou. Lees die reëls, die tabelle en die gevolglike ip route get-antwoord weer. 'n Tweede kliënt kan sy eie roete met koppeling herinstalleer en die konflik herskep, en daarom moet die toestandkontrole ná die laaste kliënt se koppeling plaasvind, nie voor dit nie.

Toets twee vloei, nie een nie: die versoek wat vroeër misluk het, en 'n hulpbron wat veronderstel is om die ander tonnel te gebruik. Om alle private verkeer op een verbinding te plaas, laat die eerste toets slaag terwyl dit die tweede breek, en net 'n gepaarde toets vang dit. Teken elke uitsondering aan wat jy hou, met die bestemming en die rede, sodat die volgende persoon 'n doelbewuste gasheerroete van 'n oorblyfsel kan onderskei.