Windows OpenVPN-profil fejler på Ubuntu: tre lag

Start den samme profil fra en terminal, og den besked, som de fleste kopierer, er en advarsel, ikke årsagen til at klienten stoppede. Tre uafhængige lag fejler her: et indskudt direktiv, som Linux-bygget ikke implementerer, de rettigheder der kræves for at oprette en tun-enhed, og den resolver-hjælper der gør en forbindelse til fungerende DNS. Tag dem i rækkefølge, fordi hvert lag kan skjule det næste.

Behold downloadet, som det kom, og rediger en kopi, så et nyt download ikke stiltiende ruller dine ændringer tilbage.

Læs advarslen, før du giver den skylden

block-outside-dns låser DNS på Windows via Windows Filtering Platform, og Linux-klienten har intet at knytte det til. Når serveren skubber det, udskriver klienten en linje om ukendt tilvalg for den indskudte post og fortsætter, fordi et indskudt tilvalg ikke betragtes som fatalt. Den identiske linje i din egen fil er noget andet: der stopper parseren. Afgør, hvilken af de to du har, før du rører noget, fordi kun én af dem afslutter kørslen.

Fjern støjen ved at filtrere den før parsing: en pull-filter ignore-post for det navn, eller --ignore-unknown-option når linjen ligger i den lokale fil. Begge bringer en linje til tavshed, som du allerede har læst; ingen af dem reparerer en fejl, du ikke har diagnosticeret.

Rettigheder fejler før alt andet

En tun-enhed og de ruter, der følger med den, er privilegerede objekter, og en normal konto kan ikke oprette dem. Tilvalget --user forklarer opdelingen: daemonen giver kun afkald på sine privilegier, efter at det privilegerede arbejde er gjort. Start den som root, eller via en unit der starter den sådan, og se derefter efter en tilladelsesfejl, før du ser på certifikater. Lempelse af filrettighederne på profilen giver ikke processen de rettigheder, den mangler.

En TLS-fejl betyder, at klienten kom forbi dette lag. En klage over enhed eller rute betyder, at den aldrig nåede laget ovenover.

Hvad GUI'en gør, som terminalen ikke gør

At forbinde med succes, mens hvert opslag stadig fejler, er det tredje lag. NetworkManager udfører sit eget resolver-arbejde, og derfor kan en import fra skrivebordet uddele DNS, selv når profilets up-script aldrig har kørt med succes. Kommandoen openvpn --config udfører hvad --up angiver, og hvis den hjælper mangler, dukker grænsefladen op, mens opslag fortsat går til de tidligere servere. Sammenlign de to vejes scripts, før du installerer noget.

Brug den pakkede hjælper til din distribution; et script kopieret fra et blogindlæg rammer normalt en anden resolver. Den integration, der leveres til systemd-resolved, er ikke det generiske script i vpnc-stil, og hver især forventer sine egne argumenter og variabler fra klienten. Brugerdefinerede up-scripts kræver også script-security 2, før klienten overhovedet vil køre dem.

Skil lagene ad ved næste kørsel

Kør én gang med --verb 4 og læs loggen i den rækkefølge, det skete: enhedsoprettelse, ruter, TLS-håndtryk, derefter up-scriptets output. Den første fejl i den sekvens er den værd at rette; alt derefter er normalt en konsekvens. En tunnel, der etableres, mens resolveren ikke gør, placerer dig på tredje lag, hvor certifikatet er irrelevant. Lad det downloadede profil være urørt, mens du sammenligner.

Når hver operatørjustering giver endnu en afvist linje, er filen rettet mod en anden platform. Bed om en Linux-eksport i stedet for at bygge en permanent filterliste.

Noter hvilket lag der fejlede, og hvad der ændrede det, fordi den næste person, der får samme fil, ellers også stopper ved advarslen.