Windows OpenVPN-profil misslyckas på Ubuntu: tre lager

Starta samma profil från en terminal och meddelandet som de flesta kopierar är en varning, inte orsaken till att klienten stannade. Här misslyckas tre oberoende lager: ett påskjutet direktiv som Linux-bygget inte implementerar, de rättigheter som krävs för att skapa en tun-enhet och resolver-hjälparen som gör en anslutning till fungerande DNS. Arbeta igenom dem i ordning, eftersom varje lager kan dölja nästa.

Behåll nedladdningen som den kom och redigera en kopia, så att en ny nedladdning inte tyst rullar tillbaka dina ändringar.

Läs varningen innan du skyller på den

block-outside-dns låser DNS på Windows via Windows Filtering Platform, och Linux-klienten har inget att koppla det till. När servern skjuter ut det skriver klienten en rad om okänt alternativ för den påskjutna posten och fortsätter, eftersom ett påskjutet alternativ inte behandlas som fatalt. Samma rad i din egen fil är något annat: där stannar parsern. Avgör vilken av de två du har innan du rör något, eftersom bara en av dem avslutar körningen.

För att ta bort bruset, filtrera det före parsning: en pull-filter ignore-post för det namnet, eller --ignore-unknown-option när raden finns i den lokala filen. Båda tystar en rad du redan har läst; ingen av dem reparerar ett fel du inte har diagnostiserat.

Rättigheter misslyckas före allt annat

En tun-enhet och rutterna som följer med den är privilegierade objekt, och ett vanligt konto kan inte skapa dem. Alternativet --user förklarar uppdelningen: daemonen avstår från sina privilegier först efter att det privilegierade arbetet är gjort. Starta den som root, eller via en unit som startar den så, och leta sedan efter ett behörighetsfel innan du tittar på certifikat. Att lätta på filrättigheterna på profilen ger inte processen de rättigheter den saknar.

Ett TLS-fel betyder att klienten kom förbi det här lagret. Ett klagomål på enhet eller rutt betyder att den aldrig nådde lagret ovanför.

Vad GUI gör som terminalen inte gör

Att ansluta framgångsrikt medan varje uppslag fortfarande misslyckas är det tredje lagret. NetworkManager gör sitt eget resolver-arbete, vilket är varför en import från skrivbordet kan dela ut DNS även när profilens up-skript aldrig har kört framgångsrikt. Kommandot openvpn --config kör det --up namnger, och om den hjälparen saknas dyker gränssnittet upp medan uppslagen fortsätter till de tidigare servrarna. Jämför skripten för de två vägarna innan du installerar något.

Använd den paketerade hjälparen för din distribution; ett skript kopierat från ett blogginlägg riktar sig oftast mot en annan resolver. Integrationen som levereras för systemd-resolved är inte det generiska skriptet i vpnc-stil, och var och en förväntar sig sina egna argument och variabler från klienten. Användardefinierade up-skript kräver också script-security 2 innan klienten alls kör dem.

Separera lagren vid nästa körning

Kör en gång med --verb 4 och läs loggen i den ordning det hände: enhetsskapande, rutter, TLS-handskakning, sedan up-skriptets utdata. Det första felet i den sekvensen är det som är värt att åtgärda; allt efter det är oftast en konsekvens. En tunnel som upprättas medan resolvern inte gör det placerar dig på tredje lagret, där certifikatet är irrelevant. Låt den nedladdade profilen vara orörd medan du jämför.

När varje operatörsjustering ger ännu en avvisad rad är filen riktad mot en annan plattform. Begär en Linux-export i stället för att bygga en permanent filterlista.

Notera vilket lager som misslyckades och vad som ändrade det, för annars stannar nästa person som får samma fil också vid varningen.