Windows-OpenVPN-profiel misluk op Ubuntu: drie vlakke

Begin dieselfde profiel in ’n terminaal en die boodskap wat die meeste mense kopieer, is ’n waarskuwing, nie die rede waarom die kliënt gestop het nie. Drie onafhanklike vlakke misluk hier: ’n ingespuite opdrag wat die Linux-bou nie implementeer nie, die regte wat nodig is om ’n tun-toestel te skep, en die resolver-hulp wat ’n verbinding in werkende DNS omskep. Werk hulle in volgorde af, want elkeen kan die volgende verberg.

Hou die aflaai soos dit aangekom het en wysig ’n kopie, sodat ’n vars aflaai nie jou veranderinge stilweg terugdraai nie.

Lees die waarskuwing voordat jy dit blameer

block-outside-dns sluit DNS op Windows via die Windows Filtering Platform toe, en die Linux-kliënt het niks om dit aan te koppel nie. Wanneer die bediener dit stuur, druk die kliënt ’n onbekende-opsie-reël vir daardie ingespuite inskrywing en gaan voort, want ’n ingespuite opsie word nie as fataal beskou nie. Dieselfde reël in jou eie lêer is ’n ander saak: daar stop die ontleder. Besluit watter van die twee jy het voordat jy enigiets aanraak, want net een van hulle beëindig die lopie.

Om die geraas te verwyder, filter dit voordat jy ontleed: ’n pull-filter ignore-inskrywing vir daardie naam, of --ignore-unknown-option wanneer die reël in die plaaslike lêer woon. Albei maak ’n reël stil wat jy al gelees het; nie een herstel ’n fout wat jy nie gediagnoseer het nie.

Voorregte misluk voordat enigiets anders kan

’n tun-toestel en die roetes wat dit vergesel, is bevoorregte objekte, en ’n normale rekening kan hulle nie skep nie. Die --user-opsie verduidelik die verdeling: die daemon gee eers sy voorregte op nadat die bevoorregte werk gedoen is. Begin dit as root, of deur ’n eenheid wat dit so begin, en soek dan na ’n toestemmingsfout voordat jy na sertifikate kyk. Om lêertoestemmings op die profiel te verslap, gee nie aan die proses die regte wat dit kort nie.

’n TLS-fout beteken die kliënt het verby hierdie vlak gekom. ’n Klagte oor ’n toestel of roete beteken dit het nooit die vlak hierbo bereik nie.

Wat die GUI doen wat die terminaal nie doen nie

Om suksesvol te verbind terwyl elke opsoek steeds misluk, is die derde vlak. NetworkManager doen sy eie resolver-werk, en daarom kan ’n lessenaarinvoer DNS uitdeel selfs wanneer die profiel se up-skrip nooit suksesvol geloop het nie. ’n Opdragreël openvpn --config voer uit wat --up noem, en as daardie hulp ontbreek, verskyn die koppelvlak terwyl opsoeke na die vorige bedieners bly gaan. Vergelyk die twee paaie se skrifte voordat jy enigiets installeer.

Gebruik die verpakte hulp vir jou verspreiding; ’n skrip wat uit ’n blogpos gekopieer is, is gewoonlik op ’n ander resolver gerig. Die integrasie wat vir systemd-resolved verskeep word, is nie die generiese skrip in vpnc-styl nie, en elkeen verwag sy eie argumente en veranderlikes van die kliënt. Gebruiker-gedefinieerde up-skrifte vereis ook script-security 2 voordat die kliënt hulle hoegenaamd sal uitvoer.

Skei die vlakke op die volgende lopie

Begin een keer met --verb 4 en lees die log in die volgorde waarin dit gebeur het: toestel-skepping, roetes, TLS-handdruk, dan up-skrip-uitset. Die eerste fout in daardie reeks is die een wat die moeite werd is om reg te maak; alles daarna is gewoonlik ’n gevolg. ’n Tonnel wat tot stand kom terwyl die resolver dit nie doen nie, plaas jou op vlak drie, waar die sertifikaat irrelevant is. Laat die afgelaaide profiel onaangeraak terwyl jy vergelyk.

Sodra elke operateur-aanpassing nog ’n verwerpte reël lewer, is die lêer op ’n ander platform gerig. Vra ’n Linux-uitvoer eerder as om ’n permanente filterlys te bou.

Let op watter vlak misluk het en wat dit verander het, want die volgende persoon aan wie dieselfde lêer gegee word, sal andersins ook by die waarskuwing stop.