Verberg ’n VPN-roetekas jou verandering? Kontroleer drie dinge

Om die roetekas te leegmaak is die eerste instink wanneer ’n verandering nie in werking tree nie, en op moderne Linux is dit vermorsde moeite: die globale IPv4-roetekas is jare gelede verwyder, so ip route show cache druk niks en daar is niks om skoon te maak nie. Die toestand wat jou mislei, woon een laag hoër: in ’n socket, ’n NAT-kaart, ’n resolver of ’n netwerkbestuurder wat die ou profiel weer toegepas het. Drie vrae skei dié gevalle: kom die verkeerde pad uit ’n nuwe stroom of ’n ou verbinding, kas jou platform hoegenaamd roetes, en sit die toestand in die roetering of bo dit. Beantwoord hulle voordat jy ’n koppelvlak herstel.

Kontrole een: kom die ou pad uit ’n nuwe stroom?

’n Gevestigde verbinding behou die roete waarmee dit geskep is. Dit is waarom ’n SSH-sessie oor die tonnel ’n verandering aan die roetetabel oorleef terwyl ’n nuwe sessie dadelik die nuwe pad neem, en waarom ’die verandering het niks gedoen’ dikwels ’die ou socket hou dit steeds vas’ beteken. Toets met ’n nuwe proses, nie met die venster wat jy reeds oop het nie.

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

Die laaste opdrag druk die adres wat die nuwe verbinding werklik bereik het, wat die goedkoopste manier is om die werklike pad te sien sonder om ’n statusvenster te vertrou. Vergelyk dit met die bronadres wat die naamruimte of koppelvlak veronderstel was om te gebruik.

As ’n vars stroom die korrekte pad neem en die ou een nie herstel nie, hou op om na die roetering te kyk. Die roete was reg; die sessie was oud.

Kontrole twee: hou jou platform hoegenaamd ’n roetekas?

Op Linux is die antwoord nee, in die sin wat die meeste gidse bedoel. Daar is geen globale bestemmingskas om te laat val nie, en die per-socket-inskrywing wat ’n gekose roete hou, word saam met die socket vrygestel. Die kas-afdeling van die ip-route-handleiding beskryf historiese gedrag, nie iets wat jy op ’n huidige kern kan leegmaak nie.

Ander platforms verskil, en dit is waar die kopiëring van advies verkeerd loop. Windows hou ’n bestemmingskas wat jy met netsh interface ip delete destinationcache kan skoonmaak. BSD en macOS bied per-bestemming-opsoektogte deur route -n get, en hul kas verstryk volgens hul eie skedule. ’n Opdrag wat op een van hierdie werk, doen op Linux heeltemal niks, en daarom lyk dieselfde oplossing te misluk vir die helfte van die mense wat dit probeer.

’n NAT- of conntrack-tabel is nie ’n roetekas nie, al veroorsaak dit dieselfde simptoom. ’n Stroom wat voor jou verandering vertaal is, behou sy vertaling, en conntrack -L sal dit wys lank nadat die roeteringsbeleid aangepas het. Dit is verouderde toestand, maar die skoonmaak van roetes raak dit nie.

Kontrole drie: sit die toestand in die roetering, of bo dit?

Lees die huidige opsoektog voordat jy enigiets anders lees: ip route get vir die bestemming, dan dieselfde opdrag met from en die bronadres, dan ip rule show. As dié drie saamstem met wat jy bedoel het, is die roetering nie die laag om reg te maak nie, en die verouderde waarneming het van elders gekom.

Drie algemene verdagtes sit bo die roetering. ’n Netwerkbestuurder kan ’n roete uit ’n gestoorde profiel herinstalleer sekondes nadat jy dit uitgevee het, so jou verandering lyk of dit terugkeer; kyk na nmcli connection show --active en die eenheid se toestand voordat jy die tabel weer wysig. ’n Resolver-kas gee ’n ou adres terug, wat soos ’n roeteringsfout lyk totdat jy dieselfde naam met ’n kas-omseilende hulpmiddel navra. ’n Toepassing se verbindingspoel hou ’n werkende socket na die ou bestemming en vra nooit die kern vir ’n nuwe besluit nie.

Wat die drie antwoorde jou laat aflei

Sit die antwoorde bymekaar en die herstel spel dikwels homself. ’n Nuwe stroom wat die verkeerde pad op ’n platform sonder roetekas neem, beteken die beleid is werklik verkeerd, so lees die reëls en die tabel wat die tonnel geïnstalleer het. ’n Nuwe stroom wat die regte pad neem terwyl die ou sessie vassteek, beteken die toepassing of socket is die probleem. Korrekte roetes met ’n gebrekkige waarneming in albei gevalle beteken die toestand is bo die roetering.

Weerstaan die generiese herlaai. Om die netwerkstapel te herbegin of elke roete te verwyder op ’n masjien wie se verstekroete die tonnel is, kan juis die verbinding afsny wat jy gebruik om dit reg te maak, en dit vernietig die bewyse wat sou gesê het watter laag gefaal het.

As jy wel iets moet skoonmaak, maak die kleinste ding skoon wat by die diagnose pas: een proses se sockets, een conntrack-inskrywing, die resolver-kas. Herhaal dan dieselfde vars-stroom-toets en skryf neer wat verander het.

Hou die drie toestande apart in jou notas

Gestoorde konfigurasie, huidige opsoektog en waargenome stroom is drie verskillende feite, en om hulle tot ’die kas’ te verplat is wat die fout moeilik maak om te reproduseer. Skryf die profiel of eenheid wat die roete besit neer, die uitset van ip route get, en die bron en bestemming van die werklike verbinding.

Teken die platform en die kliëntweergawe daarby aan, want ’n oplossing wat ’n Windows-bestemmingskas skoonmaak, is nie ’n oplossing wat op ’n Linux-gasheer van toepassing is nie, en ’n prosedure wat tussen die twee gekopieer word, leer die verkeerde les. Wanneer jy die probleem aan iemand anders oorhandig, laat daardie drie reëls hulle die foutende toestand reproduseer in plaas van om te raai.