Ontbrekende VPN-route in NetworkManager: profielbeleid of een script?

U maakt verbinding, de tunnelinterface verschijnt, en één prefix die u nodig hebt staat simpelweg niet in de tabel. De volgende stap is meestal een zoektocht naar een script dat hem toevoegt. Die zoektocht leidt naar antwoorden die een OpenVPN-helper in een profiel plakken, en de helft van die antwoorden maakt de situatie erger in plaats van beter, omdat een ontbrekende route drie mogelijke eigenaren heeft en slechts één daarvan een ontbrekend script is.

Bepaal welke eigenaar verantwoordelijk is voordat u iets schrijft.

Drie eigenaren, één ontbrekende prefix

De prefix kan ontbreken omdat niemand hem leverde, omdat het profiel hem weigerde, of omdat hij ergens is geïnstalleerd waar u niet kijkt. Dat zijn verschillende fouten en ze hebben verschillende oplossingen.

De eerste is het gemakkelijkst te controleren: heeft de server of de plug-in de route ooit aangeboden? Een backend die de prefix nooit ontving kan hem niet installeren, en een hulpscript kan geen bereikbaarheid verzinnen die de peer nooit beschreef. De tweede is profielbeleid, dat routes kan onderdrukken die de verbinding anders zou nemen. De derde is een tabel of regel, die de route kan vasthouden op een plek waar de standaardopzoeking nooit kijkt.

Een vierde eigenaar bent u, later: een script dat de route toevoegt bij het verbinden maar hem niet verwijdert bij het verbreken. Dat levert een prefix op die de tunnel overleeft, naar een dode interface wijst en de volgende persoon die de machine debugt in verwarring brengt.

Lees het profiel voordat u iets toevoegt

Begin met de eigenschappen van de opgeslagen verbinding zelf. Lees ze zonder geheimen te dumpen, en gebruik de UUID als de profielnaam dubbelzinnig is.

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type vertelt u welke backend de verbinding bezit, en dat is belangrijk omdat plug-indata backendspecifiek zijn. Een sleutel die de ene plug-in accepteert is geen ondersteunde instructie voor de andere, dus een fragment dat uit de documentatie van een andere client is gekopieerd is geen bewijs voor iets.

ipv4.ignore-auto-routes en ipv4.never-default beantwoorden verschillende vragen. De eerste kan routes weigeren die de verbinding anders automatisch zou nemen, en de tweede bepaalt of het profiel de standaardroute mag worden. Een profiel dat automatische routes negeert en op niets anders vertrouwt, verbindt schoon en installeert bijna niets.

ip -4 rule show
ip -4 route show table all

Die twee opdrachten beslechten de derde mogelijkheid. Zoek uw prefix in elke tabel, niet alleen in main, en controleer of een beleidsregel de relevante opzoeking ergens anders heen stuurt. Staat de prefix in een andere tabel en raadpleegt niets hem, dan hebt u geen ontbrekende route; u hebt een opzoeking die hem nooit bereikt.

Wat een script niet kan repareren

Een hulpscript toevoegen geeft vpn.data van NetworkManager een programma om uit te voeren. Dat is een echt mechanisme, en het is het verkeerde voor de meeste van deze gevallen, omdat het script de controle krijgt nadat het beleid van het profiel al heeft besloten wat er wordt geaccepteerd.

script-security van OpenVPN is de andere terugkerende verwarring. Het is een OpenVPN-instelling die bepaalt welke scripts de client mag uitvoeren en wat hij in hun omgeving mag plaatsen; niveau 3 staat toe dat inloggegevens via de omgeving worden doorgegeven, wat een beslissing over geheimbeheer is en geen routeringscorrectie. Het in een profiel plakken waarvan de backend geen OpenVPN is, of het verhogen wanneer geen enkel script het nodig heeft, voegt blootstelling toe zonder een route toe te voegen.

Dan is er de herstartreflex. Het herstarten van de NetworkManager-service breekt elke beheerde verbinding af en bouwt die opnieuw op, inclusief de verbinding waarover u bent verbonden als u op afstand werkt. Het is een verstorende actie, geen onschuldige diagnose, en op een server kan het het verschil zijn tussen een sessie die overleeft en een die dat niet doet.

De beslissing, in volgorde

Stel drie vragen achter elkaar. Heeft de peer de prefix geleverd, wat de log van de backend of zijn eigen statusuitvoer zal laten zien? Zo ja, is het profiel geconfigureerd om routes te accepteren en te installeren, of onderdrukt het ze? Als de route ergens bestaat, is het opzoekpad dan correct voor het verkeer dat u test?

Alleen wanneer het eerste antwoord ja is, het tweede ja en het derde correct, wordt een aanvullend script verdedigbaar, en zelfs dan moet u vragen of de backend de route native ondersteunt. De VPN-instellingenreferentie documenteert service-type en het plug-inspecifieke datavoordenboek, en daar moet u beginnen voordat u aanneemt dat een sleutel bestaat.

Na een goedgekeurde correctie verbindt u opnieuw en test u de bestemming op adres en daarna op naam, en verbreekt u daarna de verbinding en verbindt u opnieuw om te bevestigen dat de toestand herhaalbaar is. Eén eigenaar, één tabel en een route die met de tunnel verdwijnt is het resultaat dat de moeite waard is.