In tillefoan ferbynt him sûnder beklach mei de VPN fan 'e router, en in laptop dy't in profyl fan deselde downloadside brûkt, rint op in time-out. Oan 'e sertifikaten feroare neat tusken dy twa besykjen, omdat de laptop nea it punt berikte dêr't sertifikaten saak dogge. De router publisearret aparte harkers foar TUN en TAP, en in wurkjend profyl moat dy kieze dy't by syn eigen apparaattype heart.

Bepale hokker fan trije mooglike fouten efterfolge wurde moat, is hjir it hiele wurk: de poarte, it apparaattype of de siferûnderhanneling fan it datakanaal.

Trije dingen dy't oerienkomme moatte

It apparaattype, de ynterface-rigel fan it profyl en de harkpoarte foarmje ien kar, net trije. In profyl dat dev tun ferklearret en op 'e TAP-harker rjochte is, kin de sesje net foltôgje, en it omkearde mislearret identyk. Foar dyn model en firmware, lês de poarte fan 'e router syn eigen VPN-side ynstee fan út in hantlieding, omdat de nûmers tusken builds ferskowe. Skriuw it model en de firmwareferzje njonken dat nûmer, sadat de folgjende persoan it ferifiearje kin.

Rapporten út it fjild neame in pear lykas 12973 foar TUN en 12974 foar TAP op ien firmware, en in oar nûmer op in oare. Lês dy as bewiis dat builds ferskille, net as konstantes om te kopiearjen. It profyl hat dan de ôfstânspaste hostnamme nedich: de dynamyske DNS-namme fan 'e router ynstee fan in WAN-adres dat feroarje sil.

Nei it rjochtmeitsjen fan 'e poarte en de ynterface-rigel sjocht it profyl derút as in normale kliïntkonfiguraasje mei ien remote-rigel en ien dev-rigel. As de twa net oerienkomme, leveret gjin hoemannichte werhelje in sesje.

Lês it logboek yn 'e folchoarder dêr't it yn printe wurdt

In OpenVPN-kliïnt rapportearret eveneminten yn 'e folchoarder dêr't se barre, dus de lêste rigel foar de stilte bepaalt de laach om te besjen. As de run einiget by TLS Error: TLS key negotiation failed, of gewoan op in earste antwurd wachtet en it opjout, hat sertifikaatfergeliking nea plakfûn. Dat wiist op berikberens, op 'e harker of op in poarte dêr't neat efter sit. Net ien fan dy wurdt reparearre troch it CA-bestân te ferfangen.

In run dy't VERIFY OK berikt en dan mislearret, sit hielendal earne oars, mei syn eigen oarsaken. It skieden fan dy twa útkomsten foardat bestannen oanrekke wurde, foarkomt de klassike omwei troch sertifikaatbondels dêr't nea om frege is. As de hânskut oprûn is mar de tunnel net omheech komt, sjoch dan nei de siferûnderhanneling ynstee fan berikberens.

Foegje de siferlist ta dy't in moderne kliïnt ferwachtet

Resinte OpenVPN-kliïnten wegerje âldere standertwearden dy't brûkersfirmware noch biedt, en it symptoom is in ûnderhannelingsflater fuort nei in suksesfolle hânskut. De oplossing is ien profylrigel dy't neamt wat de kliïnt akseptearje sil: set data-ciphers op AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 en AES-128-CBC yn dy folchoarder. Elk algoritme dat de router net ymplementearret, wurdt gewoan nea keazen, dus in langere list kostet neat oars as in bytsje langere ûnderhanneling.

Sifers opneame leart de router net ien dy't er net hat. As de ûnderhanneling noch mislearret, kontrolearje dan oft de routerside in eigen siferynstelling hat en oft dy ynstelling teminsten ien item befettet dat de kliïnt akseptearret. Twa listen sûnder mienskiplik lid leverje presys deselde flater as in ferkearde poarte, dêrom fertsjinje beide einen in eachopslach.

Ymportearje ien kear ynstee fan kopyen mei de hân te bewurkjen

It ymportearjen fan it rjochte bestân yn NetworkManager foarkomt in map fol mei wat oare profylen: nmcli connection import type openvpn file client.ovpn, bring it dan by namme omheech. Hâld it ymportearre profyl as de iennige kopy dy'tsto bewurkest, en smyt de duplikaten fuort dy't troch werhelle downloads opgarje.

Testje dan fan bûten it LAN. Ferbinen fan itselde netwurk bewiist hiel lyts, omdat it ferkear de tunnel miskien hielendal net trochgiet. Befêstigje dat in fersyk wier troch de router nei bûten giet, net allinnich dat de kliïnt in ferbûn steat toant.

Bepale wat te dwaan mei warskôgings

Brûkersfirmware slacht gewoanwei syn eigen sertifikaatautoriteit, en kliïnten beklagje har oer ferifikaasje op manieren dy't de firmware net ditmeitsje kin. Oardielje oft dat beklach fan belang is foar watsto beskermest ynstee fan elke warskôging as deadlik te behanneljen, en skeakelje ferifikaasje net wrâldwiid út om ien berjocht stil te meitsjen. In warskôging dy'tsto beoardiele hast is in dokumintearre risiko; in ferifikaasje-ynstelling dy'tsto útskeakele hast is in net-dokumintearre.

As de firmware gjin stipe manier biedt om in warskôging te rjochtmeitsjen dy't wol fan belang is, pleitet dy leechte derfoar om de VPN earne oars te hosten. Kieze tusken it profyl reparearje, de warskôging akseptearje en it einpunt ferpleatse is in beslissing oer hoefolle oftsto dat sertifikaat fertroust. Nim it bewust, en skriuw op hokker opsje oftsto keazen hast, ynstee fan troch dialogen te klikken oant it ikoan grien wurdt.

Relatearre artikelen