Kui poolitatud tunnelite marsruudid kattuvad: milline prefiks võidab

Kaks poolitatud tunneli profiili, kaks privaatset prefiksit ja üks host, mida mõlemad nõuavad. Sümptom on harva puhas rike: teenus töötab esmaspäeval, lakkab vastamast pärast teise kliendi uuesti ühendamist ja hakkab pärast taaskäivitust jälle tööle. Järjekord, milles kliente ühendasite, ei otsusta tulemust, samuti mitte ridade järjekord kliendi liideses. Tehke need kontrollid järjekorras ja peatuge esimesel, mis ei kehti, sest järgnevad on mõttekad alles siis, kui eelnevad on tõesed.

1. Kirjutage üles sihtkoht ja lähtekoht

Alustage täpsest aadressist, kuhu ebaõnnestunud päring läheb, mitte hosti nimest ja mitte rakenduse nimest. Lahendage nimi üks kord, kirjutage üles iga vastus ja valige see, mida ebaõnnestunud voog tegelikult kasutab. Seejärel kirjutage üles sama voo kohalik aadress, sest lähteaadress võib muuta, milline poliitikareegel sobib ja seega, millist tabelit vaadatakse.

Päring ühele mitmest A-kirjest võib ebaõnnestuda, samal ajal kui sõsaraadress õnnestub, mis näeb välja nagu kõikuv tunnel, kuid on tegelikult kaks erinevat teed. Kui sihtkoht on nimi, millel on mitu vastust, testige enne millegi muutmist iga vastust eraldi.

2. Küsige tuumalt, millise marsruudi see valis

Ärge lugege marsruuditabelit ja tehke sellest järeldust. Esitage sama küsimus, mille esitab virn, sama lähteaadressiga: ip route get 10.20.4.10 from 10.8.0.2 Linuxis või Find-NetRoute -RemoteIPAddress 10.20.4.10 PowerShellis. Väljund nimetab marsruudi, mida tegelikult kasutataks, ja sageli pole see see, mida tabelit lugedes ootasite.

Sobivate marsruutide hulgas võidab tavaliselt täpsem prefiks: /24 võidab /16-st aadressi puhul, mis asub mõlema sees. Sama pikkusega vastete vahel võidab väiksem meetrika, ja lingil, mis on maas, paigaldatud marsruut jäetakse vahele. Kaks tunnelit, mis suruvad sama /24 sama meetrikaga, on teine juhtum: tuum hoiab mõlemat marsruuti ja valib nende vahel, seega võib tulemus vahelduda, selle asemel et järgida järjekorda, milles kliendid ühendusid. Just see olukord tekitab mustri esmaspäeval töötab ja teisipäeval ei tööta, ja teises järjekorras uuesti ühendamine ei muuda seda.

3. Kontrollige, kas poliitikareegel suunas otsingu ümber

Enne marsruuditabeli vaatamist käib tuum läbi oma poliitikareeglid. Reegel võib saata liikluse antud lähtekohast, kasutajast või tulemüüri märgisest hoopis teise tabelisse, seega ei pruugita põhitabeli võiduprefiksit selle voo jaoks kunagi vaadata. ip rule show loetleb need hindamisjärjekorras ja ip route show table 100 näitab, mida valitud tabel tegelikult sisaldab.

Siin varitseb kaks lõksu. Tühjale tabelile osutav reegel tekitab otsingu, mis langeb läbi järgmisele reeglile, seega tundub reegel mitte midagi tegevat. Teine on prioriteedinomber ise: reegleid loetakse kasvavas järjekorras ja sisseehitatud väärtused on 0 local, 32766 main ja 32767 default. Reeglit numbriga alla 32767 vaadatakse enne kõike hõlmavat vaikereeglit. Reegel numbriga üle 32767 asub selle taga ja selleni jõutakse ainult siis, kui ükski varasem tabel ei vasta, mida tavaline vaikemarsruut mainis takistab, seega praktikas ei jõuta selleni kunagi ja see ei tee vaikselt midagi, samal ajal kui näeb paigaldatuna välja. Kui klient kirjutas reegli ja marsruudi, kontrollige mõlemat ja kontrollige neid uuesti pärast uuesti ühendamist, sest ümber kirjutatud profiil võib lisada teise reegli erineva prioriteediga.

4. Eraldage marsruudi viik duplitseeritud aadressiplaanist

Mõnikord pole prefiks üldse probleem. Kaks kohta, mis mõlemad kasutavad 192.168.1.0/24, tähendavad, et sama aadress tähistab kahte erinevat hosti ja ükski marsruut ei suuda neid eristada. Hostimarsruut ühele kahest vastusest töötab ainult seni, kuni teine koht vastab sama nime kohta, ja siis muutub erand vaikselt veaks.

Tunnus on see, et sihtaadress on mõlemal teel identne ja erineb ainult kavatsatud omanik. See on aadressiplaani otsus, mitte marsruutimise nõke: nummerdage üks pool uuesti, asetage üks pool tõlkiv lüüs taha või jõudke teise kohta puhverserveri kaudu, mis lahendab omaenda nimesid. Vaikemarsruudi langetamine või hostierandite kuhjamine liigutab ainult kokkupõrget mujale.

5. Kinnitage, et lahendaja on marsruudiga nõus

Nimi, mis laheneb vale privaatse aadressina, tekitab kõik marsruudikonflikti sümptomid ja mitte ühtegi selle põhjust. Võrrelge vastust, mille host saab, aadressiga, mida sihtkoht tegelikult kasutab, ja kontrollige, milline lahendaja vastas. Kui tunnel surub peale lahendaja, peaks klient selle paigaldama voogude jaoks, mis tunnelit kasutavad; kui ei, jätkab host kohalikult lahendajalt küsimist, mis võib vastata otsingudomeenist või vahemällu salvestatud kirjest.

Küsige lahendajalt otse ja kirjutage üles server, mis vastas. Lühikese TTL-iga vahemällu salvestatud vastus võib samuti selgitada, miks esimene päring pärast uuesti ühendamist käitub teisiti kui viies.

6. Ühendage uuesti, uurige rakendatud olekut ja testige siis mõlemat voogu

Pärast parandust ühendage uuesti ja uurige, mida klient tegelikult paigaldas, selle asemel et usaldada profiiliredaktorit. Lugege uuesti reeglid, tabelid ja tulemuseks olev ip route get vastus. Teine klient võib ühendamisel oma marsruudi uuesti paigaldada ja konflikti taas luua, mistõttu peab olekukontroll toimuma pärast viimase kliendi ühendamist, mitte enne.

Testige kahte voogu, mitte ühte: päringut, mis varem ebaõnnestus, ja ressurssi, mis peaks kasutama teist tunnelit. Kogu privaatse liikluse viimine ühele ühendusele paneb esimese testi läbima, kuid rikub teise, ja seda tabab ainult paaris test. Kirjutage üles iga erand, mille jätate, koos sihtkoha ja põhjusega, et järgmine inimene suudaks eristada tahtlikku hostimarsruuti ülejäänust.