OpenVPN-fout: onbekende opsie tls-remote of keysize

Dit begin gewoonlik met ’n profiel wat jare lank gewerk het, oopgemaak op ’n nuwer kliënt, en dit misluk voordat die tonnel eers begin. Die terminaal druk iets soos Options error: Unrecognized option ... in client.ovpn:130: tls-remote, met ’n weergawe in hakies aan die einde. Lees dit as ’n klag van die ontleder: die lêer bevat ’n opdrag wat hierdie kliënt nie meer ken nie.

Daardie enkele boodskap verduidelik waarom sleutels hergenereer, die wagwoord hertik of die bediener nagaan niks doen nie. Die fout gebeur terwyl die kliënt sy eie konfigurasie lees, voordat dit ’n sok oopmaak. Die nuttige werk is om die verwerpte opdrag te identifiseer en dit met die huidige ekwivalent te vervang.

Lees die foutende reël voordat jy iets verander

Begin die kliënt self eerder as om dit uit ’n systeemkassie-ikoon te loods, sodat die boodskap sigbaar is en die profielpad ondubbelsinnig is. Maak die lêer by die gemelde reël oop en kyk na die teken wat die kliënt genoem het. Die reëlnommer is die profielreël, nie ’n weergawe nie, wat mense laat struikel omdat dieselfde nommer in die hakies as ’n vrystellingsidentifiseerder verskyn.

Ou profielgenerators het nie een slegte opdrag uitgestuur nie; hulle het verskeie uitgestuur. Herstel die eerste fout, begin die kliënt weer en verwag dat die volgende een sal verskyn. Daardie volgorde is normaal en nie ’n teken dat die wysigings dinge erger gemaak het nie.

Wat met keysize en tls-remote gebeur het

keysize het ’n chiffer-sleutellengte aangevra in die era toe die profiel die chiffer eksplisiet gekies het. OpenVPN 2.4 het dit verouder verklaar, en latere kliënte het dit uit die opsietabel verwyder, so die ontleder verwerp nou die reël in plaas daarvan om dit te ignoreer. Moderne onderhandeling lei die sleutellengte van die gekose chiffer af, en daarom is daar niks oor vir die opdrag om te beheer nie.

tls-remote is in 2.4 verwyder. Dit het die bediener-sertifikaat teen ’n verwagte naam vergelyk, en die vervanging daarvan is verify-x509-name, wat strenger is oor hoe die naam gepas word. Die ou opdrag is weg, so ’n profiel wat dit bevat sal nooit op ’n huidige kliënt ontleed nie.

Herstel een opdrag per poging. As die profiel ook ’n chiffer spesifiseer wat die kliënt nie bied nie, lewer dit later ’n ander fout, en om albei veranderinge in een wysiging te meng maak dit onmoontlik om te sê watter een die handdruk gebreek het. Herkoppel ná elke wysiging en hou die foutteks. Daardie gewoonte laat ook ’n werkende terugval as ’n wysiging dinge erger maak.

Herskryf die bediener-identiteitskontrole

Die vervanging neem die verwagte naam en ’n vergelykingsmodus. verify-x509-name vpn.example.edu name vereis dat die sertifikaat-onderwerp presies aan daardie waarde gelyk is. Ander modusse pas ’n voorvoegsel of ’n volledige onderwerpstring, en om die verkeerde modus te kies verander ’n werkende profiel in ’n skoon verifikasiefout.

As die ou tls-remote-argument die bediener se volledige algemene naam was, is ’n presiese name-vergelyking gewoonlik reg. As dit ’n gedeeltelike waarde was, gebruik die voorvoegselmodus eerder as om die verwagte naam te verkort, want ’n korter presiese passing sal nie verifieer nie. Wanneer die oorspronklike waarde nie neergeskryf is nie, vra diegene wat die bediener bedryf vir die onderwerp wat hulle publiseer.

Moet nie die kontrole stil maak om die fout te laat verdwyn nie. Om bediener-identiteitsverifiëring te verwyder verander ’n herstelbare profielprobleem in ’n ongeverifieerde tonnel, wat presies die risiko is wat die opdrag moes voorkom.

Reggestelde profiel, plaaslike wysiging of ouer kliënt

Wanneer iemand anders die bediener besit, is die skoonste pad ’n huidige profiel van hulle. Jou kopie kom van ’n ouer generator, en hulle uitvoer gebruik reeds die huidige opdragte. Een aflaai verwyder die hele kategorie foute en hou toekomstige wysigings op een plek.

Wanneer jy albei kante besit, wysig ’n kopie en hou die oorspronklike. Verander een opdrag, stoor, koppel en teken die kliëntweergawe aan wat jy getoets het. Hou ’n kort nota by elke wysiging, want ’n profiel wat oor verskeie sessies gewysig is, is moeilik om uit die geheue te oudit. Opdragreël-lopies teen die gewysigde lêer maak daardie lus vinnig omdat die fout reguit na die terminaal gaan.

Om na ’n pre-2.4-kliënt vas te pen of terug te rol laat die boodskap ook verdwyn, en met ’n toestel wat nooit opgedateer sal word nie, mag dit die enigste werkbare noodoplossing wees. Behandel dit as tydelik: ’n ou kliënt op ’n huidige lessenaar beteken gewoonlik ’n ou biblioteek en ’n onondersteunde konfigurasie, wat ’n probleem is wat uitgestel eerder as opgelos word.

Nadat die tonnel opkom, lees die hele profiel nog een keer. Profiele wat een verwyderde opdrag gedra het, dra dikwels nog een, en die tweede kom eers te voorskyn nadat die eerste weg is.