Rekursiivinen reititys: kun tunneli nappaa omat pakettinsa

Tunneli nousee, loki näyttää valmiin kättelyn, ja sekuntia myöhemmin sama istunto kuolee ja yhdistyy uudelleen silmukassa. Tuolla kuviolla on tietty syy: reitti palvelimelle osoittaa nyt tunnelin sisään, joten tunnelia kantavat paketit lähetetään tunnelin läpi. Todennuksessa ei muuttunut mikään, minkä vuoksi tunnistetietojen syöttäminen uudelleen ei muuta mitään. Vertaa ulompaa polkua ennen reittimuutosta ja sen jälkeen, niin rekursio tulee näkyviin.

Tarkista ensin ulompi polku

Pelissä on kaksi pakettia, ei yksi. Sisempi paketti kuuluu sovellukselle ja sen pitäisi olla salattu, kun taas ulompi paketti on osoitettu palvelimelle ja sen on päästävä sinne polkua, joka ei riipu tunnelista.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Kysy ytimeltä reittiä palvelimen osoitteeseen, kun tunneli on ylhäällä, ja uudelleen sen jälkeen kun oletusreitti on muuttunut. Seuraava hyppy, joka laskeutuu tunnelilaitteelle, on itse rekursio, ja se näkyy ilman mitään pakettikaappausta. Liitäntäsidonta, merkit tai verkon nimiavaruus voivat tehdä tavallisesta hausta puutteellisen, joten käytä sitä kontekstia, jota asiakas itse käyttää. Kun vastaus näyttää oikealta mutta istunto pyörii yhä silmukassa, lue reitityskäytännön säännöt, älä vain päätaulukkoa.

Miksi istunto kestää hetken

Kättely valmistuu ennen kuin uusi reitti asennetaan, joten ensimmäiset sekunnit näyttävät terveiltä. Heti kun asiakas lisää oletusreitin, seuraava ulompi paketti seuraa sitä liitäntään, jonka kautta sen ulomman paketin on kuljettava. Palvelin ei näe mitään, asiakas lähettää uudelleen, ja yritys joko vanhenee tai tappaa istunnon ja aloittaa alusta.

Tuo järjestys selittää, miksi tunneli voi toimia kannettavassa ja epäonnistua reitittimessä, ja miksi vika alkaa usein liikenteen alkaessa eikä yhteyden muodostuksessa. Se selittää myös silmukan: jokainen uudelleenkäynnistys palauttaa istunnon ennen kuin reitti tekee sen mahdottomaksi.

Selvitä, kuka omistaa päätepisteen poikkeuksen

Tuetut asiakkaat järjestävät oman poikkeuksensa: isäntäreitti palvelimelle alkuperäisen yhdyskäytävän kautta tai merkki, joka pitää ulomman pistokkeen tunnelin ulkopuolella. Kysymys on, poistikko jokin muu sen vai ohittiko se sen.

Reittipohjaisessa IPsecissä tutki käytäntövalitsimet, jotka päättävät, mitkä paketit tulevat tunneliin, ja varmista, että vastapuolen osoite on jätetty niiden ulkopuolelle. WireGuardissa liitännän palomuurimerkki ja sen käytäntösäännöt pitävät kuljetuspaketit tunnelin ulkopuolella, joten käsin lisätty oletusreitti voi rikkoa järjestelyn. Toinen VPN-profiili tai oletusreitin uudelleenkirjoittava hallintaskripti on tavallinen syyllinen. Yksi kerrallaan lisätyt laajat ohitussäännöt ovat tavanomainen tulos, ja ne muuttavat reititysvirheen taulukoksi, jota kukaan ei voi ylläpitää.

Tarkista uudelleen verkkovaihdon jälkeen

Isäntäreitti Wi-Fi-yhdyskäytävän kautta on oikein, kunnes kone siirtyy toiseen verkkoon. Silloin sama oire palaa ilman mitään kokoonpanomuutosta.

Kirjaa päätepisteen osoite, reitti ennen yhteyttä ja sen jälkeen sekä liitäntä, jota kumpikin käytti. Nuo kolme tosiasiaa erottavat yleensä asiakkaan virheen ohituksesta, ja ne säilyvät sen henkilön jälkeen, joka ne keräsi.

Yhdistä uudelleen uudessa verkossa ja toista luenta. Jos poikkeus puuttuu taas, korjaus kuuluu profiiliin, joka sen omistaa, ei kertaluonteiseen komentoon, joka kirjoitettiin katkoksen aikana.