Mae hen broffil .ovpn yn methu ar Ubuntu 24.04: pa linellau i'w dileu

Mae'r proffil yn lawrlwytho, yn mewnforio ac yna'n stopio ar linell 12 o'r ffeil gyda neges Unrecognized option sy'n enwi keysize. Nid oes dim wedi newid am y cyfrif, ac mae'r gweinydd yn dal i dderbyn cleientiaid eraill. Yr hyn sydd wedi newid yw'r cleient ei hun: mae Ubuntu 24.04 yn gosod OpenVPN 2.6, tra cafodd yr allbwn ei ysgrifennu ar gyfer 2.4. Cyfres fer o ddileadau yw'r atgyweiriad, ac mae'r drefn yn bwysig oherwydd bod pob opsiwn hen yn torri'r dadansoddiad cyn i'r nesaf gael ei darllen o gwbl.

Darllenwch y llinell gwall cyn cyffwrdd â'r ffeil

Mae OpenVPN yn enwi'r ffeil a'r linell lle stopiodd y dadansoddiad, felly dim ond un broblem y gallwch ei thrwsio fesul cychwyn. Cychwynnwch y proffil o derfynell yn hytrach nag o aplyned penbwrdd, oherwydd mae'r aplyned fel arfer yn llyncu stderr a'r rhif llinell yw'r unig gyfeiriad dibynadwy a gewch: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Trwsiwch y linell honno, rhedeg eto, a disgwyliwch i'r methiant nesaf enwi opsiwn gwahanol.

Mae gwall dadansoddi bob amser yn ymddangos cyn unrhyw gyfnewid TLS, felly mae neges sy'n sôn am dystysgrif eisoes wedi clirio'r cam cystrawen. Mae'r gwahaniaeth hwnnw'n eich rhwystro rhag golygu ffeil nad yw'n methu ond ar ddilysu. Darllenwch air cyntaf y neges, nid ei chanol.

Tair dosbarth methiant, tair atgyweiriad wahanol

Mae hen allbynnau'n methu mewn tair ffordd wahanadwy, a'r rheswm y mae pobl yn ailosod pecynnau na chawsant eu torri erioed yw eu bod yn eu huno'n un broblem. Mae geiriad y neges yn dweud wrthych ym mha ddosbarth yr ydych cyn i chi agor y ffeil.

• Mae gwallau dadansoddi'n enwi ffeil a llinell, ac yn stopio cyn bod unrhyw draffig yn bodoli.
• Mae gwallau negodi'n cysylltu, ac yna'n adrodd na allai'r ddau ben gytuno ar seiffr a rennir neu ar sianel ddata dderbyniol.
• Mae gwallau dilysu'n mynd bellaf ac yn enwi tystysgrif, defnyddiwr neu gymwyster a wrthodwyd.

Dim ond y dosbarth cyntaf y mae golygu proffil yn ei drwsio. Mae negodi angen penderfyniad ar ddau ben y twnnel, ac nid yw cymwyster a wrthodwyd yn broblem cystrawen o gwbl. Os yw eich neges yn sôn am seiffr a rennir neu sianel ddata, ni fydd y dileadau isod yn newid dim.

Dilëwch yr opsiynau a dynnodd 2.6, yn y drefn hon

Mae pob un o'r llinellau hyn yn stopio'r dadansoddiad ar ei ben ei hun, felly mae'r cleient yn eu hadrodd un ar y tro. Ewch i lawr y rhestr a rhedeg eto ar ôl pob dilead.

Dilëwch keysize yn gyntaf, oherwydd nad oes ganddo gyfystyron modern ac mae ei bresenoldeb fel arfer yn nodi seiffr y mae'r cleient presennol yn ei wrthod beth bynnag. Yna dilëwch ncp-disable, a oedd yn rheoli negodi seiffrau, a gafodd ei ddiystyru yn 2.5 ac sydd bellach yn absennol yn 2.6. Amnewidiwch ns-cert-type server â remote-cert-tls server, sy'n datgan yr un bwriad trwy wiriad a gefnogir. Mae hanes newidiadau 2.6 yn rhestru'r tyniadau sy'n weddill wrth eu hamnewidiadau, felly mae gan bopeth y mae'r dadansoddydd yn ei wrthod o hyd ateb wedi'i gofnodi.

Cadwch gopi o'r proffil gwreiddiol cyn y golygiad cyntaf. Mae darparwyr yn ailddyhidlo allbynnau, a diff yn erbyn y ffeil heb ei chyffwrdd yw'r ffordd gyflymaf o wahanu eich newidiadau chi oddi wrth eu rhai hwy. Os yw dilead yn gadael i'r cleient gychwyn ond mae'r twnnel yn dal i fethu, rydych wedi symud i'r dosbarth negodi ac nid y llinellau sy'n weddill yw'r achos. Rhowch fersiwn y cleient yn enw'r ffeil fel bod y person nesaf yn gwybod pa ryddhad y mae'r golygiadau'n cyfeirio ato.

Cadwch BF-CBC i weithio fel cwymp a gwmpesir yn unig

Mae rhai darparwyr yn dal i derfynu ar BF-CBC, ac ni fydd OpenVPN 2.6 yn negodi ag ef heb gymorth oherwydd bod gan y seiffr floc 64-did. Yr atgyweiriad cul yw rhestr cwympo ynghyd â darparwr etifeddol OpenSSL, nid israddio'r cleient cyfan.

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

Mae'r llinell gyntaf yn llwytho'r darparwr etifeddol fel y gall OpenSSL greu'r seiffr hwnnw o hyd, mae'r ail yn cadw negodi modern ar gyfer cymheiriaid sy'n ei gefnogi, ac mae'r drydedd ond yn berthnasol pan na fydd y gweinydd yn cynnig unrhyw beth gwell. Gwanhad bwriadol o'r twnnel yw hyn, felly cofnodwch pam y mae'n bodoli wrth ymyl y ffeil. Gofynnwch i'r darparwr am allbwn wedi'i ailddyhidlo ar yr un pryd, oherwydd pont yn hytrach na chyrchfan yw'r cwymp.

Peidiwch â chyrraedd am --compat-mode fel ateb cyffredinol. Mae'n newid sawl ymddygiad ar unwaith, gan gynnwys rhagosodiadau negodi ac ailnegodi, felly ni fyddwch byth yn dysgu pa newid oedd o bwys. Byddwch yn well gyda'r tair llinell benodol uchod, oherwydd mae pob un yn datgan ei heffaith ei hun.

Gwiriwch gyda'r proffil y mae'r cleient yn ei lwytho mewn gwirionedd

Mae cysylltiadau a fewnforiwyd yn cael eu copïo i gyfeiriadur system yn aml, felly efallai na fydd golygu'r ffeil yn eich ffolder llwytho i lawr yn newid dim o gwbl. Dewch o hyd i'r copi sy'n rhedeg: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Yna cychwynnwch y twnnel a darllenwch y llinell log sy'n adrodd pa seiffr sianel ddata a ddewiswyd mewn gwirionedd. Mae cysylltiad sy'n cwblhau'r cyfnewid ar y cwymp yn dweud wrthych na chynigiodd y gweinydd unrhyw beth modern.

Profwch o rwydwaith nad yw'r un y mae'r darparwr yn ei ddisgwyl, fel nad yw porthladd caeth neu rwydwaith gwestai wedi'i hidlo yn cuddio fel nam proffil. Cofnodwch fersiwn y cleient ochr yn ochr ag unrhyw gais am gefnogaeth.

Unwaith y bydd y twnnel i fyny, anfonwch un cais y mae'n rhaid iddo groesi a un na ddylai, ac yna cadarnhewch fod ateb y datryswr wedi newid fel y gwnaethoch ei ddisgwyl. Os yw'r proffil bellach yn dadansoddi ond mae'r cysylltiad yn dal i fethu, rydych wedi gadael y broblem gystrawen ar ôl a bydd testun y gwall yn enwi'r dosbarth newydd. Cadwch y ffeil wedi'i golygu mewn rheolaeth fersiwn wrth ymyl nodyn sy'n enwi'r ryddhad OpenVPN y mae'n cyfeirio ato.