Windows-OpenVPN-profiel mislukt op Ubuntu: drie lagen

Start hetzelfde profiel vanuit een terminal en het bericht dat de meeste mensen kopiëren is een waarschuwing, niet de reden waarom de client stopte. Hier falen drie onafhankelijke lagen: een doorgestuurd richtlijn die de Linux-build niet implementeert, de rechten die nodig zijn om een tun-apparaat te maken, en de resolver-hulp die een verbinding omzet in werkende DNS. Werk ze op volgorde af, want elk kan de volgende verbergen.

Bewaar de download zoals hij aankwam en bewerk een kopie, zodat een nieuwe download je wijzigingen niet stil terugdraait.

Lees de waarschuwing voordat je haar de schuld geeft

block-outside-dns vergrendelt DNS op Windows via het Windows Filtering Platform, en de Linux-client heeft niets om het aan te koppelen. Wanneer de server het doorstuurt, drukt de client een regel over een onbekende optie af voor dat doorgestuurde item en gaat verder, omdat een doorgestuurde optie niet als fataal wordt behandeld. Dezelfde regel in je eigen bestand is iets anders: daar stopt de parser. Bepaal welke van de twee je hebt voordat je iets aanraakt, want slechts één ervan beëindigt de uitvoering.

Om de ruis te verwijderen, filter je die vóór het parsen: een pull-filter ignore-item voor die naam, of --ignore-unknown-option wanneer de regel in het lokale bestand staat. Beide brengen een regel die je al hebt gelezen tot zwijgen; geen van beide repareert een fout die je niet hebt gediagnosticeerd.

Rechten falen voor al het andere

Een tun-apparaat en de routes die erbij horen zijn bevoorrechte objecten, en een normaal account kan ze niet aanmaken. De optie --user legt die splitsing uit: de daemon geeft zijn rechten pas op nadat het bevoorrechte werk is gedaan. Start hem als root, of via een unit die hem zo start, en zoek daarna naar een rechtenfout voordat je naar certificaten kijkt. Het versoepelen van bestandsrechten op het profiel geeft het proces niet de rechten die het mist.

Een TLS-fout betekent dat de client deze laag voorbij is gekomen. Een klacht over apparaat of route betekent dat hij de laag erboven nooit heeft bereikt.

Wat de GUI doet en de terminal niet

Succesvol verbinden terwijl elke opzoeking nog steeds mislukt, is de derde laag. NetworkManager doet zijn eigen resolver-werk, waardoor een import vanaf de desktop DNS kan uitdelen, zelfs wanneer het up-script van het profiel nooit met succes heeft gedraaid. Het commando openvpn --config voert uit wat --up benoemt, en als die hulp ontbreekt, verschijnt de interface terwijl opzoekingen naar de vorige servers blijven gaan. Vergelijk de scripts van de twee paden voordat je iets installeert.

Gebruik de verpakte hulp voor je distributie; een script dat van een blogpost is gekopieerd, richt zich meestal op een andere resolver. De integratie die voor systemd-resolved wordt geleverd is niet het generieke script in vpnc-stijl, en elk verwacht zijn eigen argumenten en variabelen van de client. Door de gebruiker gedefinieerde up-scripts vereisen ook script-security 2 voordat de client ze überhaupt uitvoert.

Scheid de lagen bij de volgende run

Draai één keer met --verb 4 en lees de log in de volgorde waarin het gebeurde: apparaataanmaak, routes, TLS-handshake, dan de uitvoer van het up-script. De eerste fout in die reeks is degene die het waard is om te verhelpen; alles daarna is meestal een gevolg. Een tunnel die tot stand komt terwijl de resolver dat niet doet, zet je op de derde laag, waar het certificaat irrelevant is. Laat het gedownloade profiel ongemoeid terwijl je vergelijkt.

Zodra elke aanpassing van de operator weer een afgewezen regel oplevert, is het bestand op een ander platform gericht. Vraag een Linux-export aan in plaats van een permanente filterlijst te bouwen.

Noteer welke laag faalde en wat die veranderde, want anders stopt de volgende persoon die hetzelfde bestand krijgt ook bij de waarschuwing.