Profilul OpenVPN din Windows eșuează pe Ubuntu: trei straturi

Porniți același profil din terminal și mesajul pe care majoritatea îl copiază este un avertisment, nu motivul pentru care clientul s-a oprit. Aici eșuează trei straturi independente: o directivă trimisă pe care compilarea Linux nu o implementează, drepturile necesare pentru a crea un dispozitiv tun și ajutorul de rezolvare care transformă o conexiune într-un DNS funcțional. Parcurgeți-le în ordine, pentru că fiecare îl poate ascunde pe următorul.

Păstrați descărcarea așa cum a sosit și editați o copie, ca o descărcare nouă să nu vă anuleze modificările în tăcere.

Citiți avertismentul înainte de a-l învinui

block-outside-dns blochează DNS în Windows prin Platforma de filtrare Windows, iar clientul Linux nu are la ce să o asocieze. Când serverul o trimite, clientul tipărește o linie despre opțiune necunoscută pentru acea intrare trimisă și continuă, pentru că o opțiune trimisă nu este considerată fatală. Dar aceeași linie din propriul fișier este altceva: acolo parserul se oprește. Decideți pe care dintre cele două o aveți înainte de a atinge ceva, pentru că doar una dintre ele încheie execuția.

Pentru a elimina zgomotul, filtrați-l înainte de analiză: o intrare pull-filter ignore pentru acel nume sau --ignore-unknown-option când linia se află în fișierul local. Ambele reduc la tăcere o linie pe care ați citit-o deja; niciuna nu repară o defecțiune pe care nu ați diagnosticat-o.

Privilegiile eșuează înaintea oricui altceva

Un dispozitiv tun și rutele care îl însoțesc sunt obiecte privilegiate, iar un cont normal nu le poate crea. Opțiunea --user explică această separare: demonul renunță la privilegii doar după ce munca privilegiată este terminată. Porniți-l ca root sau printr-o unit care îl pornește astfel, apoi căutați o eroare de permisiune înainte de a vă uita la certificate. Slăbirea permisiunilor fișierului profilului nu îi dă procesului drepturile care îi lipsesc.

O eroare TLS înseamnă că clientul a trecut de acest strat. O reclamație despre dispozitiv sau rută înseamnă că nu a ajuns niciodată la stratul de deasupra.

Ce face GUI-ul și terminalul nu

Conectarea cu succes în timp ce fiecare interogare încă eșuează este al treilea strat. NetworkManager își face propria muncă de rezolvare, de aceea o importare de pe desktop poate distribui DNS chiar și atunci când scriptul up al profilului nu a rulat niciodată cu succes. Comanda openvpn --config execută ceea ce numește --up, iar dacă acel ajutor lipsește, interfața apare în timp ce interogările continuă să meargă către serverele anterioare. Comparați scripturile celor două căi înainte de a instala ceva.

Folosiți ajutorul împachetat pentru distribuția dumneavoastră; un script copiat dintr-o postare de blog vizează de obicei alt rezolvator. Integrarea livrată pentru systemd-resolved nu este scriptul generic în stil vpnc, iar fiecare așteaptă propriile argumente și variabile de la client. Scripturile up definite de utilizator necesită și ele script-security 2 înainte ca clientul să le execute.

Separați straturile la următoarea rulare

Rulați o dată cu --verb 4 și citiți jurnalul în ordinea în care s-a întâmplat: crearea dispozitivului, rute, strângerea de mână TLS, apoi ieșirea scriptului up. Prima eșuare din acea secvență este cea care merită reparată; tot ce urmează este de obicei o consecință. Un tunel care se stabilește în timp ce rezolvatorul nu o face vă plasează pe al treilea strat, unde certificatul este irelevant. Lăsați profilul descărcat neatins în timp ce comparați.

Odată ce fiecare ajustare a operatorului produce încă o linie respinsă, fișierul este orientat către altă platformă. Cereți o exportare pentru Linux în loc să construiți o listă de filtre permanentă.

Notați care strat a eșuat și ce l-a schimbat, pentru că următoarea persoană care primește același fișier se va opri și ea la avertisment.