Tunneli pysyy, reitti katosi: kahden VPN-vian erottaminen

Yksi isäntä tulee tavoittamattomaksi, vaikka tunneliliitäntä ilmoittaa edelleen olevansa muodostettu, eivätkä havainnot ole ristiriidassa. Jokin poisti reitin, jota liikenne käytti: naapuri veti etuliitteensä takaisin, seurattu staattinen reitti poistettiin tai toinen reitti tuli ensisijaiseksi. Suojausassosiaatio voi pysyä täysin terveenä kaikissa kolmessa. Tapahtumien erottaminen tarkoittaa kysymistä, mikä kerros muuttui ensin, sen sijaan että kysyttäisiin epäonnistuiko VPN.

Kolme vaihetta, jotka näyttävät yhdeltä tapahtumalta

Reitityspäätöksessä on kolme vaihetta. Etuliite vastaanotetaan, valitaan parhaaksi ja asennetaan edelleenlähetystaulukkoon. Jokainen vaihe voi epäonnistua itsestään, ja vika näyttää sovelluksen puolelta samalta. Etuliitettä, joka opittiin mutta hävisi valinnan, ei voi erottaa siitä, joka ei koskaan saapunut, kun ainoa todiste, jota katsot, on edelleenlähetystaulukko.

Siksi ensimmäinen kysymys on, mikä vaihe rikkoutui, ei mikä protokolla on syyllinen. Vastaus ratkaisee, kenelle tapaus kuuluu ja mitä työkalua seuraava tarkistus käyttää.

Lue ensin asennettu reitti

Kysy ytimeltä, minne liikenne epäonnistuvaan kohteeseen todella menee. ip route get tulostaa seuraavan hypyn, liitännän ja lähdeosoitteen, jota ydin käyttäisi, ja se vastaa yhdestä kohteesta eikä koko taulukosta. Jos vastaus nimeää tunnelin, edelleenlähetystaulukko uskoo edelleen reitin olevan olemassa ja ongelma on sen yläpuolella.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Vastaus »unreachable» tarkoittaa, ettei asennettua reittiä ole lainkaan, mikä viittaa takaisinvetoon tai puuttuvaan asennukseen. Vastaus, joka nimeää fyysisen liitännän, tarkoittaa, että liikenne poistui tunnelista ilman että kukaan päätti niin, ja seuraava tarkistus on etusija, joka voitti. Vastaus, joka nimeää tunnelin pakettien yhä kadotessa, viittaa kauemmas reitille, suodatukseen tai vastakkaiselle puolelle.

Katso sitten protokollan omaa näkymää

Reititysdaemon pitää enemmän kuin yhtä taulukkoa, ja kiinnostava vertailu on niiden välillä. BGP:ssä naapurisession tila, vastaanotettu ilmoitus ja asennettu reitti ovat kolme erillistä todistetta. Etuliite voi istua vastaanotetussa taulukossa eikä koskaan saavuttaa ydintä, koska lyhyemmän hallinnollisen etäisyyden reitti voittaa. Tarkista kaikki kolme ennen kuin päättelet, että toinen puoli lopetti ilmoittamisen.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

Yhteenveto kertoo, onko istunto muodostettu, etuliitekohtainen näkymä kertoo, hyväksyttiinkö etuliite, ja ytimen haku kertoo, asennettiinko se. Niiden lukeminen tässä järjestyksessä estää istunnon värähtelyn sekoittamisen takaisinvetoon ja takaisinvedon sekoittamisen käytännön hylkäykseen.

Kun kellot ovat eri mieltä

Aseta tunneliloki, reititysloki ja sovelluksen ensimmäinen vika yhdelle aikajanalle niiden todellisia aikavyöhykkeitä käyttäen. Jos naapurin menetys tulee ensin, tunneli veti reitin alas mukanaan. Jos takaisinveto tulee ensin, reititys muuttui ja tunneli reagoi vasta sen jälkeen. Ne ovat eri tapauksia eri omistajilla, ja järjestys on koko löydös.

Yhden minuutin kellonheitto riittää kääntämään tämän johtopäätöksen, joten vahvista aikavyöhyke ja siirtymä ennen kuin luotat järjestykseen. Laitteet, jotka kirjaavat paikallista aikaa ilman siirtymää, ovat tavallinen itsevarman mutta väärän aikajanan lähde.

Palautuminen ilman silmukkaa

Takaisinvedon jälkeen kaksi reittiä voi olla kelvollisia: se, jonka protokolla valitsee, ja se, jonka kiinnität käsin. Vain ensimmäinen on päätös, jonka verkko tekee edelleen puolestasi, minkä vuoksi käsin tehty reitti on hätäratkaisu eikä palautumissuunnitelma. Vaihtoehtoinen ilmoitus ei myöskään säilytä palomuurin tai NATin tilaa jo muodostetulle istunnolle, joten uudet virrat voivat toimia, kun alkuperäinen pysyy rikki. Vahvista, mikä varayhteys pitäisi aktivoida ja hyväksyykö etäsivusto paluureitin sen kautta.

Älä asenna pysyvää staattista ohitusta ennen kuin ymmärrät, miksi takaisinveto tapahtui. Tämä oikotie voi kiinnittää liikenteen epäonnistuneelle reitille tai ohittaa hiljaa tarkoituksellisen reitityskäytännön, ja se hautaa alkuperäisen syyn uuden kokoonpanon alle. Testaa sovellus uudelleen, kun reitti on palautettu, ja vahvista, että valitulla etuliitteellä on toimiva datapolku eikä vain merkintä taulukossa.