VPN sê verbind, maar die standaardroete is dood

Die kliënt sê dit is verbind, die taakbalk-ikoon lyk normaal, en niks laai nie. Dit het begin net nadat jy van Wi-Fi na ’n kabel geskuif het, of net nadat ’n verspreidingsopgradering klaar was. Wat gebreek het, is nie die profiel nie, maar die toestand wat vir die vorige basisverbinding gebou is. Die kern het steeds ’n standaardroete wat na ’n tonneltoestel wys wat niemand besit nie, of die resolver lys steeds bedieners op ’n skakel wat verdwyn het. Albei foute lyk soos ’n dooie netwerk en albei kan ter plaatse herstel word.

Die verouderde stukke was al verkeerd voordat jy dit raakgesien het. Om ’n kabel uit te trek het dit net sigbaar gemaak.

Vra die kern waarheen ’n pakkie sou gaan

Roetelyste is moeilik om te lees omdat hulle alles opsom wat die stelsel ken, insluitend inskrywings wat nie meer geld nie. ’n Roetesoektog antwoord die enigste vraag wat werd is om te vra: watter toestel dra hierdie bepaalde pakkie op die oomblik. As die antwoord ’n tonneltoestel noem, sal die kern dit gebruik selfs al is geen kliëntproses lewendig daaragter nie, en die pakkie val in ’n koppelvlak wat niks onderhou nie. As die antwoord die Ethernet-adapter noem terwyl die kliënt daarop aandring dat dit op is, bestaan die tonnel maar het die keuse verloor, wat die gewone uitkoms is wanneer ’n mens van draadloos na bedraad oorskakel.

Voer die soektog twee keer uit, een keer vir ’n openbare adres en een keer vir ’n interne een, want ’n verdeelde-tonnel-beleid kan die een eerlik aanstuur en die ander laat val.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

Die resolver hou ook die dooie skakel

Op ’n systemd-resolved-gasheer behoort DNS-bedieners aan skakels eerder as aan een globale lys. ’n VPN-skakel wat afgegaan het, kan ’n ruk lank met sy bedieners geregistreer bly, en elke soektog wag dan op ’n adres wat nooit sal antwoord nie. Daardie vertraging voel soos ’n dooie netwerk, en dit laat mense na roetes kyk terwyl die roete reg is.

resolvectl status
resolvectl query intranet.example.com

Lees die blokke per skakel en bepaal watter skakel die betrokke domein besit. ’n Tonnel wat op is maar nie die eienaar van die interne domein is nie, stuur interne name na die openbare resolver, en die simptoom is nie van ’n roetefout te onderskei nie.

Herstel die registrasie eerder as /etc/resolv.conf. Op huidige Ubuntu- en Fedora-installasies is daardie pad ’n simboolskakel na die resolver se looptydtoestand, so ’n wysiging word óf geïgnoreer óf by die volgende netwerkgebeurtenis oorgeskryf.

’n VPN begin nooit vanself nie

NetworkManager bring ’n VPN bo-op ’n basisverbinding op, en dit leer by watter een om te volg uit connection.secondaries op daardie basis. Die verwysing vir verbindingsinstellings sê uitdruklik dat outoverbinding nie vir VPN-profiele geïmplementeer is nie. Dit is die hele meganisme agter hierdie klas fout: verander die basis, en die VPN moet met die hand weer gepaar of heraktiveer word.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Wanneer die aktiewe lys die basis sonder die VPN wys, is die tonnel glad nie aktief nie en is die roete nooit geïnstalleer nie eerder as dat dit verouderd gelaat is. Wanneer aktivering kla dat daar geen bronverbinding bestaan nie, het die basis waarmee dit gepaar was verdwyn, so maak eers die basis of die paring reg en hou op om die VPN weer te probeer.

’n Opgradering kan instellings sonder ’n boodskap laat val

Om ’n verspreiding op te gradeer vervang die kliënt en dikwels sy NetworkManager-inprop, terwyl die gestoorde profiel die eiendomsname hou waarmee dit geskryf is. Enigiets wat die nuwe inprop nie meer herken nie, word in stilte oorgeslaan. Die profiel aktiveer steeds en die toestel verskyn steeds, maar die roete wat vroeër saam met dit gekom het, kom nooit nie.

Handgeskrewe hake skuif ook. ’n Skrip wat ’n roete op ’n voorspelbare oomblik in die ou volgorde geïnstalleer het, kan nou hardloop voordat die koppelvlak bestaan, of nadat die kliënt al ’n tydverstryking opgedoen het.

Vergelyk die lewende profiel met die inprop wat jy werklik het eerder as met die gedrag wat jy onthou. As ’n sleutel uit die dokumentasie verdwyn het, skuif die werk na ’n dispatser-skrip of ’n ondersteunde vervanging eerder as om die ou eiendom te herstel.

Drie toestande, drie verskillende herstellings

Bepaal in watter toestand jy is voordat jy aan iets raak, want ’n herlaai vernietig die bewyse en die fout keer terug by die volgende netwerkverandering.

Sluit af met een soektog vir ’n openbare adres, een vir ’n interne adres en een naamnavraag. As die adresse werk en die naam nie, is die oorblywende fout domeinbestek in die resolver, en was die roetelys nooit die probleem nie.