Reittivälimuistin tyhjentäminen on ensimmäinen vaisto, kun muutos ei tule voimaan, ja nykyaikaisessa Linuxissa se on turhaa työtä: yleinen IPv4-reittivälimuisti poistettiin vuosia sitten, joten ip route show cache ei tulosta mitään eikä tyhjennettävää ole. Sinua huijaava tila elää yhden kerroksen ylempänä: socketissa, NAT-mäppäyksessä, resolverissa tai verkkohallinnassa, joka sovelsi vanhan profiilin uudelleen. Kolme kysymystä erottaa nämä tapaukset: tuleeko väärä polku uudesta virtauksesta vai vanhasta yhteydestä, välimuistaako alustasi reittejä ylipäätään, ja onko tila reitityksessä vai sen yläpuolella. Vastaa niihin ennen kuin nollaat rajapinnan.

Tarkistus yksi: tuleeko vanha polku uudesta virtauksesta?

Muodostettu yhteys säilyttää reitin, jolla se luotiin. Siksi SSH-istunto tunnelin yli selviää reititystaulun muutoksesta, kun taas uusi istunto ottaa heti uuden polun, ja siksi «muutos ei tehnyt mitään» tarkoittaa usein «vanha socket pitää sitä yhä». Testaa uudella prosessilla, älä ikkunalla, joka sinulla on jo auki.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

Viimeinen komento tulostaa osoitteen, johon uusi yhteys todella pääsi, ja se on halvin tapa nähdä todellinen polku luottamatta tilaikkunaan. Vertaa sitä lähdeosoitteeseen, jota nimiavaruuden tai rajapinnan oli tarkoitus käyttää.

Jos tuore virtaus kulkee oikeaa polkua eikä vanha palaudu, lopeta reitityksen katsominen. Reitti oli oikea; istunto oli vanha.

Tarkistus kaksi: pitääkö alustasi ylipäätään reittivälimuistia?

Linuxissa vastaus on ei, siinä merkityksessä, jota useimmat oppaat tarkoittavat. Yleistä kohdevälimuistia ei ole hylättäväksi, ja valitun reitin pitävä socket-kohtainen merkintä vapautetaan socketin mukana. ip-route-käsikirjan välimuistiosio kuvaa historiallista käyttäytymistä, ei mitään, mitä voit tyhjentää nykyisessä ytimessä.

Muut alustat eroavat, ja juuri tässä neuvojen kopioiminen menee pieleen. Windows pitää kohdevälimuistia, jonka voit tyhjentää komennolla netsh interface ip delete destinationcache. BSD ja macOS näyttävät kohdekohtaiset haut komennolla route -n get, ja niiden välimuistit vanhenevat oman aikataulunsa mukaan. Komento, joka toimii jollakin näistä, ei tee Linuxissa yhtään mitään, minkä vuoksi sama korjaus näyttää epäonnistuvan puolella niistä, jotka kokeilevat sitä.

NAT- tai conntrack-taulukko ei ole reittivälimuisti, vaikka se tuottaa saman oireen. Ennen muutostasi käännetty virtaus säilyttää käännöksensä, ja conntrack -L näyttää sen kauan sen jälkeen, kun reitityskäytäntö on jatkanut matkaa. Se on vanhentunut tila, mutta reittien tyhjentäminen ei koske siihen.

Tarkistus kolme: onko tila reitityksessä vai sen yläpuolella?

Lue nykyinen haku ennen kuin luet mitään muuta: ip route get kohteelle, sitten sama komento from ja lähdeosoitteen kanssa, sitten ip rule show. Jos nämä kolme täsmäävät aikomuksesi kanssa, reititys ei ole korjattava kerros, ja vanhentunut havainto tuli muualta.

Kolme tavallista epäiltyä istuu reitityksen yläpuolella. Verkkohallinta voi asentaa reitin tallennetusta profiilista sekunteja sen poistamisen jälkeen, joten muutoksesi näyttää palaavan; tarkista nmcli connection show --active ja yksikön tila ennen taulukon muokkaamista uudelleen. Resolverin välimuisti palauttaa vanhan osoitteen, mikä näyttää reititysvialta, kunnes kysyt samaa nimeä välimuistin ohittavalla työkalulla. Sovelluksen yhteysallas pitää toimivan socketin vanhaan kohteeseen eikä koskaan kysy ytimeltä uutta päätöstä.

Mitä kolme vastausta antavat sinun päätellä

Laita vastaukset yhteen, ja korjaus yleensä ilmoittaa itsensä. Tuore virtaus, joka kulkee väärää polkua alustalla, jossa ei ole reittivälimuistia, tarkoittaa, että käytäntö on todella väärä, joten lue säännöt ja taulukko, jonka tunneli asensi. Tuore virtaus, joka kulkee oikeaa polkua samalla kun vanha istunto jumittuu, tarkoittaa, että ongelma on sovelluksessa tai socketissa. Oikeat reitit ja rikkinäinen havainto molemmissa tapauksissa tarkoittavat, että tila on reitityksen yläpuolella.

Vastusta yleistä virkistystä. Verkkopinosan uudelleenkäynnistäminen tai kaikkien reittien poistaminen koneelta, jonka oletusreitti on tunneli, voi katkaista juuri sen yhteyden, jota käytät sen korjaamiseen, ja se tuhoaa todisteet siitä, mikä kerros petti.

Jos sinun on pakko tyhjentää jotain, tyhjennä pienin diagnoosiin sopiva asia: yhden prosessin socketit, yksi conntrack-merkintä, resolverin välimuisti. Toista sitten sama tuoreen virtauksen testi ja kirjoita ylös, mikä muuttui.

Pidä kolme tilaa erillään muistiinpanoissasi

Tallennettu kokoonpano, nykyinen haku ja havaittu virtaus ovat kolme eri tosiasiaa, ja niiden litistäminen «välimuistiksi» on se, mikä tekee viasta vaikeasti toistettavan. Kirjoita muistiin reitin omistava profiili tai yksikkö, ip route get-komennon tuloste sekä todellisen yhteyden lähde ja kohde.

Kirjoita viereen alusta ja asiakasversio, koska korjaus, joka tyhjentää Windowsin kohdevälimuistin, ei ole Linux-isäntään soveltuva korjaus, ja näiden kahden välillä kopioitu menettely opettaa väärän oppitunnin. Kun annat ongelman jollekulle toiselle, ne kolme riviä antavat hänen toistaa vikatilan arvaamisen sijaan.

Aiheeseen liittyvät artikkelit