Két osztott alagút profil, két privát előtag és egy gép, amelyre mindkettő igényt tart. A tünet ritkán tiszta hiba: egy szolgáltatás hétfőn működik, a második kliens újracsatlakozása után túllépi az időkorlátot, és újraindítás után ismét működik. Nem a kliensek csatlakozási sorrendje dönti el az eredményt, és a kliens felületén látható sorok sorrendje sem. Hajtsa végre ezeket az ellenőrzéseket sorrendben, és álljon meg az elsőnél, amely nem teljesül, mert a későbbiek csak akkor értelmesek, ha a korábbiak igazak.

1. Jegyezze fel a célt és a forrást

A hibás kérés pontos címével kezdje, ne a gépnévvel és ne az alkalmazás nevével. Oldja fel a nevet egyszer, jegyezze fel minden választ, és azt válassza, amelyet a hibás folyam valóban használ. Ezután jegyezze fel ugyanazon folyam helyi címét, mert a forráscím megváltoztathatja, melyik házirendszabály illeszkedik, és ezáltal azt is, melyik táblát nézik.

Egy kérés, amely több A rekord valamelyikére megy, meghiúsulhat, miközben egy testvér-cím sikeres, ami ingatag alagútnak látszik, valójában azonban két különböző útvonal. Ha a cél több válasszal rendelkező név, minden választ külön teszteljen, mielőtt bármit módosítana.

2. Kérdezze meg a kernelt, melyik útvonalat választotta

Ne olvassa ki az útvonaltáblából a választ, és ne következtessen rá. Tegye fel ugyanazt a kérdést, amelyet a verem tesz fel, ugyanazzal a forráscímmel: ip route get 10.20.4.10 from 10.8.0.2 Linuxon, vagy Find-NetRoute -RemoteIPAddress 10.20.4.10 PowerShellben. A kimenet megnevezi az útvonalat, amelyet valóban használnának, és ez gyakran nem az, amelyre a tábla olvasásakor számított.

Az illeszkedő útvonalak között általában a pontosabb előtag nyer: a /24 legyőzi a /16-ot egy olyan címnél, amely mindkettőben benne van. Azonos hosszúságú egyezések között az alacsonyabb metrika nyer, a lekapcsolt kapcsolaton telepített útvonal pedig kimarad. Két alagút, amely ugyanazt a /24-et hirdeti azonos metrikával, más eset: a kernel mindkét útvonalat megtartja, és közöttük választ, így az eredmény váltakozhat ahelyett, hogy a kliensek csatlakozási sorrendjét követné. Pontosan ez a helyzet hozza létre a hétfőn működik, kedden nem mintát, és a más sorrendben történő újracsatlakozás nem változtat rajta.

3. Ellenőrizze, hogy egy házirendszabály másfelé irányította-e a keresést

Mielőtt az útvonaltáblát megnézik, a kernel végigjárja a házirendszabályait. Egy szabály adott forrásból, felhasználótól vagy tűzfaljelölésből származó forgalmat teljesen másik táblába küldhet, így előfordulhat, hogy a fő tábla nyertes előtagját soha nem nézik meg ahhoz a folyamhoz. A ip rule show kiértékelési sorrendben listázza őket, a ip route show table 100 pedig megmutatja, mi van valójában a kiválasztott táblában.

Itt két csapda lapul. Az üres táblára mutató szabály olyan keresést eredményez, amely átcsúszik a következő szabályra, így a szabály úgy tűnik, mintha semmit nem tenne. A másik maga a prioritásszám: a szabályokat növekvő sorrendben olvassák, a beépített értékek pedig 0 local, 32766 main és 32767 default. A 32767 alatti számú szabályt a mindent elkapó alapértelmezett szabály előtt vizsgálják. A 32767 feletti számú szabály mögötte helyezkedik el, és csak akkor érhető el, ha egyetlen korábbi tábla sem válaszol, amit a mainben lévő szokásos alapértelmezett útvonal megakadályoz, így a gyakorlatban soha nem érhető el, és csendben semmit nem tesz, miközben telepítettnek látszik. Ha a kliens szabályt és útvonalat is írt, ellenőrizze mindkettőt, és ellenőrizze őket újra újracsatlakozás után, mert az újraírt profil második szabályt adhat hozzá eltérő prioritással.

4. Válassza külön az útvonal-döntetlent a megkettőzött címtervtől

Néha az előtag egyáltalán nem a probléma. Ha két telephely ugyanazt a 192.168.1.0/24 használja, az azt jelenti, hogy ugyanaz a cím két különböző gépet azonosít, és egyetlen útvonal sem tudja megkülönböztetni őket. A két válasz egyikére mutató gépútvonal csak addig működik, amíg a másik telephely nem válaszol ugyanarra a névre, és akkor a kivétel csendben maga lesz a hiba.

A jele az, hogy a célcíme mindkét útvonalon azonos, és csak a szándékolt tulajdonos tér el. Ez címterv-kérdés, nem útvonal-hangolás: számozza újra az egyik oldalt, tegye az egyik oldalt fordító átjáró mögé, vagy érje el a második telephelyet olyan proxyval, amely a saját neveit oldja fel. Az alapértelmezett útvonal csökkentése vagy a gépkivételek halmozása csak arrébb tolja az ütközést.

5. Erősítse meg, hogy a feloldó egyetért az útvonallal

A rossz privát címre feloldódó név az útvonal-ütközés minden tünetét produkálja, és egyetlen okát sem. Hasonlítsa össze a gépek kapott választ azzal a címmel, amelyet a cél valóban használ, és ellenőrizze, melyik feloldó válaszolt. Ha az alagút feloldót küld, a kliensnek telepítenie kellene azt azokhoz a folyamokhoz, amelyek az alagutat használják; ha nem teszi, a gép tovább kérdezi a helyi feloldót, amely válaszolhat keresési tartományból vagy gyorsítótárazott rekordból.

Kérdezze meg közvetlenül a feloldót, és jegyezze fel a válaszoló kiszolgálót. A rövid TTL-lel gyorsítótárazott válasz azt is megmagyarázhatja, miért viselkedik másképp az újracsatlakozás utáni első kérés, mint az ötödik.

6. Csatlakozzon újra, vizsgálja meg az alkalmazott állapotot, majd tesztelje mindkét folyamot

Javítás után csatlakozzon újra, és vizsgálja meg, mit telepített valójában a kliens, ahelyett hogy a profil szerkesztőjében bízna. Olvassa el újra a szabályokat, a táblákat és az abból adódó ip route get választ. Egy második kliens csatlakozáskor újratelepítheti a saját útvonalát, és újra létrehozhatja az ütközést, ezért az állapotellenőrzésnek az utolsó kliens csatlakozása után kell megtörténnie, nem előtte.

Két folyamot teszteljen, ne egyet: azt a kérést, amely korábban meghiúsult, és egy olyan erőforrást, amelynek a másik alagutat kellene használnia. Ha minden privát forgalmat egyetlen kapcsolatra tesz át, az első teszt átmegy, de a második elromlik, és ezt csak a páros teszt fogja meg. Jegyezze fel minden megtartott kivételt a céllal és az indokkal, hogy a következő ember meg tudja különböztetni a szándékos gépútvonalat a maradéktól.

Kapcsolódó cikkek