Kun jaetun tunnelin reitit menevät päällekkäin: mikä etuliite voittaa

Kaksi jaetun tunnelin profiilia, kaksi yksityistä etuliitettä ja yksi isäntä, jota molemmat vaativat. Oire on harvoin puhdas vika: palvelu toimii maanantaina, aikakatkaisee toisen asiakkaan yhdistettyä uudelleen ja toimii taas uudelleenkäynnistyksen jälkeen. Järjestys, jossa yhdistit asiakkaat, ei ratkaise tulosta, eikä asiakkaan käyttöliittymän rivijärjestyskään. Suorita nämä tarkistukset järjestyksessä ja pysähdy ensimmäiseen, joka ei pidä paikkaansa, sillä myöhemmät ovat mielekkäitä vain kun aiemmat ovat tosia.

1. Kirjoita ylös kohde ja lähde

Aloita tarkasta osoitteesta, johon epäonnistuva pyyntö menee, älä isäntänimestä äläkä sovelluksen nimestä. Ratkaise nimi kerran, kirjaa jokainen vastaus ja valitse se, jota epäonnistuva virtaus todella käyttää. Kirjaa sitten saman virtauksen paikallinen osoite, sillä lähdeosoite voi muuttaa sitä, mikä käytäntösääntö täsmää ja siten sitä, mitä taulua tarkastellaan.

Pyyntö yhteen useasta A-tietueesta voi epäonnistua, kun sisarosoite onnistuu, mikä näyttää epävakaalta tunnelilta mutta on todella kaksi eri polkua. Jos kohde on nimi, jolla on useita vastauksia, testaa jokainen vastaus erikseen ennen kuin muutat mitään.

2. Kysy ytimeltä, minkä reitin se valitsi

Älä lue reititystaulua ja päättele vastausta. Esitä sama kysymys, jonka pino esittää, samalla lähdeosoitteella: ip route get 10.20.4.10 from 10.8.0.2 Linuxissa tai Find-NetRoute -RemoteIPAddress 10.20.4.10 PowerShellissä. Tuloste nimeää reitin, jota todella käytettäisiin, ja se ei useinkaan ole se, jota taulua lukemalla odotit.

Täsmäävistä reiteistä voittaa yleensä täsmällisempi etuliite: /24 voittaa /16:n osoitteelle, joka sijaitsee molemmissa. Samanpituisten osumien välillä voittaa pienempi metriikka, ja reitti, joka on asennettu alas olevaan linkkiin, ohitetaan. Kaksi tunnelia, jotka työntävät saman /24:n samalla metriikalla, on toinen tapaus: ydin säilyttää molemmat reitit ja valitsee niiden väliltä, joten tulos voi vaihdella sen sijaan että se noudattaisi järjestystä, jossa asiakkaat yhdistettiin. Juuri tämä tilanne tuottaa kuvion maanantaina toimii ja tiistaina ei, eikä uudelleenyhdistäminen toisessa järjestyksessä muuta sitä.

3. Tarkista, ohjasiko käytäntösääntö haun toisaalle

Ennen kuin reititystaulua tarkastellaan, ydin käy läpi käytäntösääntönsä. Sääntö voi lähettää liikennettä tietystä lähteestä, käyttäjästä tai palomuurimerkinnästä täysin toiseen tauluun, joten päätaulun voittavaa etuliitettä ei ehkä koskaan tarkastella kyseiselle virtaukselle. ip rule show luettelee ne arviointijärjestyksessä, ja ip route show table 100 näyttää, mitä valittu taulu todella sisältää.

Tässä on kaksi ansaa. Sääntö, joka osoittaa tyhjään tauluun, tuottaa haun, joka putoaa seuraavalle säännölle, joten sääntö näyttää tekevän ei mitään. Toinen on itse prioriteettinumero: säännöt luetaan nousevassa järjestyksessä, ja sisäänrakennetut arvot ovat 0 local, 32766 main ja 32767 default. Sääntö, jonka numero on alle 32767, tarkastellaan ennen kaiken kattavaa oletussääntöä. Sääntö, jonka numero on yli 32767, on sen takana ja saavutetaan vain, kun mikään aiempi taulu ei vastaa, minkä mainin tavallinen oletusreitti estää, joten käytännössä sitä ei koskaan saavuteta ja se tekee äänettömästi ei mitään näyttäessään asennetulta. Jos asiakas kirjoitti säännön ja reitin, tarkista molemmat ja tarkista ne uudelleen uudelleenyhdistämisen jälkeen, sillä uudelleenkirjoitettu profiili voi lisätä toisen säännön eri prioriteetilla.

4. Erottele reittitasapeli kahdennetusta osoitesuunnitelmasta

Joskus etuliite ei ole lainkaan ongelma. Kaksi sivustoa, jotka molemmat käyttävät 192.168.1.0/24, tarkoittavat, että sama osoite yksilöi kaksi eri isäntää, eikä mikään reitti voi erottaa niitä. Isäntäreitti toiseen kahdesta vastauksesta toimii vain, kunnes toinen sivusto vastaa samaan nimeen, ja silloin poikkeuksesta tulee äänettömästi vika.

Tuntomerkki on, että kohdeosoite on sama molemmilla poluilla ja vain aiottu omistaja eroaa. Se on osoitesuunnitelman päätös, ei reitityksen säätö: numeroi toinen puoli uudelleen, aseta toinen puoli kääntävän yhdyskäytävän taakse tai saavuta toinen sivusto välityspalvelimen kautta, joka ratkaisee omat nimensä. Oletusreitin laskeminen tai isäntäpoikkeusten pinoaminen vain siirtää törmäyksen muualle.

5. Varmista, että ratkaisija on samaa mieltä reitistä

Nimi, joka ratkeaa väärään yksityiseen osoitteeseen, tuottaa kaikki reitityskonfliktin oireet ja ei yhtään sen syytä. Vertaa vastausta, jonka isäntä saa, osoitteeseen, jota kohde todella käyttää, ja tarkista, mikä ratkaisija vastasi. Jos tunneli työntää ratkaisijan, asiakkaan pitäisi asentaa se tunnelia käyttäville virtauksille; jos ei, isäntä kysyy edelleen paikalliselta ratkaisijalta, joka voi vastata hakutoimialueesta tai välimuistiin tallennetusta tietueesta.

Kysy ratkaisijalta suoraan ja kirjaa palvelin, joka vastasi. Lyhyen TTL:n välimuistivastaus voi myös selittää, miksi ensimmäinen pyyntö uudelleenyhdistämisen jälkeen käyttäytyy eri tavoin kuin viides.

6. Yhdistä uudelleen, tutki sovellettu tila ja testaa sitten molemmat virtaukset

Korjauksen jälkeen yhdistä uudelleen ja tutki, mitä asiakas todella asensi, sen sijaan että luottaisit profiilieditoriin. Lue säännöt, taulut ja tuloksena oleva ip route get-vastaus uudelleen. Toinen asiakas voi asentaa oman reittinsä uudelleen yhdistäessään ja luoda konfliktin uudelleen, minkä vuoksi tilantarkistus on tehtävä viimeisen asiakkaan yhdistämisen jälkeen, ei ennen sitä.

Testaa kahta virtausta, älä yhtä: pyyntöä, joka ennen epäonnistui, ja resurssia, jonka pitäisi käyttää toista tunnelia. Kaiken yksityisen liikenteen siirtäminen yhdelle yhteydelle saa ensimmäisen testin läpäisemään mutta rikkoo toisen, ja vain paritettu testi havaitsee sen. Kirjaa jokainen poikkeus, jonka pidät, kohteen ja syyn kanssa, jotta seuraava henkilö voi erottaa tarkoituksellisen isäntäreitin jäljelle jääneestä.