Ĉu VPN-a vojkacheo kaŝas vian ŝanĝon? Kontrolu tri aferojn

Malplenigi la vojkacheon estas la unua instinkto kiam ŝanĝo ne ekvalidas, kaj sur moderna Linux ĝi estas vana klopodo: la tutmonda IPv4-vojkacheo estis forigita antaŭ jaroj, do ip route show cache presas nenion kaj estas nenio por viŝi. La stato, kiu trompas vin, loĝas unu tavolon pli alte: en soketo, NAT-mapado, solvilo aŭ retadministrilo, kiu reaplikis la malnovan profilon. Tri demandoj apartigas tiujn kazojn: ĉu la malĝusta vojo venas de nova fluo aŭ de malnova konekto, ĉu via platformo entute kaŝmemorigas vojojn, kaj ĉu la stato estas en la vojigo aŭ super ĝi. Respondu ilin antaŭ ol vi restarigos interfacon.

Kontrolo unu: ĉu la malnova vojo venas de nova fluo?

Fiksita konekto konservas la vojon kun kiu ĝi estis kreita. Tial SSH-sesio tra la tunelo postvivas ŝanĝon de la vojiga tabelo, dum nova sesio tuj prenas la novan vojon, kaj tial «la ŝanĝo faris nenion» ofte signifas «la malnova soketo ankoraŭ tenas ĝin». Testu per nova procezo, ne per la fenestro, kiun vi jam malfermis.

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

La lasta komando presas la adreson, kiun la nova konekto efektive atingis, kio estas la plej malmultekosta maniero vidi la realan vojon sen fidi statan fenestron. Komparu ĝin kun la fontadreso, kiun la nomspaco aŭ la interfaco devintus uzi.

Se freŝa fluo prenas la ĝustan vojon kaj la malnova ne resaniĝas, ĉesu rigardi la vojigon. La vojo estis ĝusta; la sesio estis malnova.

Kontrolo du: ĉu via platformo entute tenas vojkacheon?

Sur Linux la respondo estas ne, laŭ la senco, kiun plej multaj gvidiloj celas. Ne ekzistas tutmonda celkacheo por forĵeti, kaj la enskribo po-soketa, kiu tenas elektitan vojon, estas liberigita kune kun la soketo. La kachea sekcio de la manlibro pri ip-route priskribas historian konduton, ne ion, kion vi povas malplenigi sur nuna kerno.

Aliaj platformoj malsamas, kaj ĝuste tie la kopiado de konsiloj fuŝiĝas. Windows tenas celkacheon, kiun vi povas viŝi per netsh interface ip delete destinationcache. BSD kaj macOS montras serĉojn po-celan per route -n get, kaj iliaj kacheoj eksvalidiĝas laŭ sia propra horaro. Komando, kiu funkcias sur unu el ĉi tiuj, faras absolute nenion sur Linux, tial la sama riparo ŝajnas malsukcesi por duono de la homoj, kiuj provas ĝin.

NAT- aŭ conntrack-tabelo ne estas vojkacheo, kvankam ĝi produktas la saman simptomon. Fluo tradukita antaŭ via ŝanĝo konservas sian tradukon, kaj conntrack -L montros ĝin longe post kiam la vojiga politiko moviĝis plu. Tio estas kaduka stato, sed viŝado de vojoj ne tuŝos ĝin.

Kontrolo tri: ĉu la stato estas en la vojigo aŭ super ĝi?

Legu la nunan serĉon antaŭ ol legi ion ajn alian: ip route get por la celo, poste la sama komando kun from kaj la fontadreso, poste ip rule show. Se tiuj tri kongruas kun tio, kion vi intencis, la vojigo ne estas la tavolo por ripari, kaj la kaduka observo venis de aliloke.

Tri kutimaj suspektatoj sidas super la vojigo. Retadministrilo povas reinstali vojon el konservita profilo sekundojn post kiam vi forviŝis ĝin, do via ŝanĝo ŝajnas reveni; kontrolu nmcli connection show --active kaj la staton de la unuo antaŭ ol denove redakti la tabelon. Solvila kacheo redonas malnovan adreson, kio aspektas kiel vojiga malsukceso ĝis vi demandos la saman nomon per ilo, kiu preteriras la kacheon. Konekta baseno de aplikaĵo tenas funkciantan soketon al la malnova celo kaj neniam petas la kernon pri nova decido.

Kion la tri respondoj lasas vin konkludi

Kunmetu la respondojn kaj la riparo kutime sin eldiras. Freŝa fluo prenanta la malĝustan vojon sur platformo sen vojkacheo signifas, ke la politiko estas vere malĝusta, do legu la regulojn kaj la tabelon, kiun la tunelo instaligis. Freŝa fluo prenanta la ĝustan vojon dum la malnova sesio haltas signifas, ke la problemo estas la aplikaĵo aŭ la soketo. Ĝustaj vojoj kun rompita observo en ambaŭ kazoj signifas, ke la stato estas super la vojigo.

Rezistu la ĝeneralan refreŝigon. Restartigi la retan stakon aŭ forviŝi ĉiun vojon sur maŝino, kies defaŭlta vojo estas la tunelo, povas tranĉi ĝuste la konekton, kiun vi uzas por ripari ĝin, kaj ĝi detruas la pruvojn, kiuj dirus al vi, kiu tavolo malsukcesis.

Se vi tamen devas viŝi ion, viŝu la plej malgrandan aferon, kiu kongruas kun la diagnozo: la soketojn de unu procezo, unu conntrack-enskribon, la solvilan kacheon. Poste ripetu la saman freŝa-fluo-teston kaj notu, kio ŝanĝiĝis.

Tenu la tri statojn aparte en viaj notoj

Konservita agordo, nuna serĉo kaj observita fluo estas tri malsamaj faktoj, kaj kunpremi ilin en «la kacheon» estas tio, kio faras la difekton malfacile reproduktebla. Notu la profilon aŭ unuon, kiu posedas la vojon, la eligon de ip route get kaj la fonton kaj celon de la reala konekto.

Notu apude la platformon kaj la klientversion, ĉar riparo, kiu viŝas Windows-celkacheon, ne estas riparo aplikebla al Linux-gastiganto, kaj proceduro kopiita inter la du instruas la malĝustan lecionon. Kiam vi transdonos la problemon al iu alia, tiuj tri linioj ebligos al li reprodukti la malsukcesan staton anstataŭ diveni.