Si të verifikoni serverin e një profili OpenVPN përpara se ta importoni

Dikush ju dërgon një profil, ju e importoni dhe tridhjetë sekonda më vonë një klient po telefonon një destinacion që askush nuk e kontrolloi. Lexoni fillimisht skedarin në një redaktues teksti, sepse gjithçka që ka rëndësi zë një grusht direktivash: remote, proto, port, ca, cert, tls-crypt dhe verify-x509-name. Gjithçka tjetër janë vlera të parazgjedhura, dhe pikërisht aty banojnë surprizat.

Rendisni çdo pikë fundore që skedari mund të përdorë

Filloni nga pikat fundore, sepse një profil mund të mbajë disa. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn shtyp çdo kandidat sipas rendit të skedarit, përfshirë ata të futur në blloqet <connection> brenda rreshtit.

Kur një direktivë lë jashtë portën, klienti kthehet te vlera e parazgjedhur e dëgjuesit, kështu që vetëm remote vpn.example.com nënkupton portën 1194 me çdo proto që shfaqet më vonë në skedar. Disa rreshta të thjeshtë remote janë alternativa: klienti i provon me radhë, përveçse remote-random i përziejn, dhe nuk zëvendëson kurrë në heshtje hostin e një operatori tjetër. Dy rreshta remote në domene të palidhura është pika ku ndaleni dhe pyesni cili ishte i synuari.

Vini re edhe drejtshkrimin e proto. tcp pranohet si sinonim i tcp-client nga ana e klientit, por tcp-server në një profil klienti është gabim konfigurimi që priret të ngecë sesa të dështojë pastër.

Konfirmoni emrin, pastaj portën

dig +short vpn.example.com ju tregon nëse emri ekziston dhe cilat adresa kthen, dhe një pikë fundore me shumë adresa ose pas një përfaqësuesi mund të kthejë disa në mënyrë të ligjshme. Zgjidhja e emrit është parakusht, jo provë pronësie; kushdo mund të drejtojë një emër drejt një adrese, dhe një adresë mund t'u përgjigjet shumë emrave.

Pastaj kontrolloni dëgjuesin në portën që gjetët, në përputhje me transportin. Përmes TCP, openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com shtyp zinxhirin që paraqet serveri. Përmes UDP ju nevojitet DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 kryen të njëjtin shtrëngim duarsh përmes datagrameve. Një shtrëngim duarsh i përfunduar dëshmon se diçka po dëgjon dhe mban një certifikatë, që është më shumë se sa tregon një ping dhe më pak se sa kërkojnë vetë cilësimet e besimit të profilit.

Kur shtrëngimi i duarve dështon dhe hosti përgjigjet ndaj ping, porta është ndoshta e gabuar ose e filtruar. Merreni si arsye për të kërkuar portën e saktë, jo si ftesë për të fshirë ato pranë. nc -vzu gjithashtu raporton sukses në disa rafte pa asgjë që dëgjon, kështu që një provë UDP e zhveshur nuk do të thotë asgjë pa një shtrëngim duarsh pas saj.

Lexoni kunjat e besimit ndaras nga adresa

Adresa vendos ku shkon klienti; blloku i besimit vendos kujt i beson kur arrin. verify-x509-name "vpn.example.com" name fikson emrin e përbashkët të subjektit, dhe remote-cert-tls server kërkon përdorimin e zgjeruar të çelësit për vërtetimin e serverit. Një profil që ju jep një operator duhet t'i mbajë të dyja.

Kërkoni ca, një bllok <ca> brenda rreshtit dhe ose tls-crypt ose tls-auth. Një profil që përdor tls-auth ka nevojë për key-direction 1 në klient kur ana e serverit përdor drejtimin 0, dhe mospërputhja dështon shtrëngimin e duarve me një gabim TLS që lexohet si defekt certifikate. Një CA brenda rreshtit që nuk i përket operatorit, emrin e të cilit sapo zgjidhët, do të thotë se skedari u montua nga dy burime, dhe ky është rasti që meriton refuzim të plotë.

verify-x509-name pranon modalitetet name, name-prefix ose subject, dhe i fundit pret një emër të plotë dallues në të njëjtin rend që serveri e shtyp atë. Zgjidhni një modalitet që përputhet me formën e vlerës, sepse klienti refuzon çdo lidhje në vend që të paralajmërojë për një përputhje të afërt. Për një skedar që nuk e keni shkruar ju, name me një emër të thjeshtë hosti është zgjedhja më pak befasuese.

Kontrolloni opsionet që dështojnë në heshtje

OpenVPN 2.6 negocion shifrat përmes data-ciphers, dhe një profil që mban vetëm një rresht të vjetër cipher AES-256-CBC mund të përfundojë kanalin e kontrollit dhe pastaj të ngecë në të dhëna. Leximi i asaj vlere ju tregon nëse skedari është më i vjetër se serveri ku po bashkoheni; faqja e manualit e versionit 2.6 rendit rendin e negocimit nëse duhet t'ia citoni operatorit.

auth-user-pass pa emër skedari do të thotë që klienti do të pyesë, kështu që një profil që duket i vetëmjaftueshëm ka ende nevojë për kredenciale. auth-user-pass credentials.txt do të thotë që pret një skedar që ndoshta nuk ju është dërguar. nobind dhe resolv-retry infinite janë të zakonshme dhe të padëmshme, ndërsa explicit-exit-notify është vetëm për UDP dhe i kotë përmes TCP.

Asnjë nga këto nuk ndryshon ku lidhet profili, por secili ndryshon nëse lidhet fare, dhe asnjë nuk është i dukshëm në dialogun e importit të klientit.

Vendosni dhe pastaj shënoni çfarë vendosët

Pas këtij leximi ka tre rezultate, dhe vetëm një është import. Kur pika fundore dhe kunjat përputhen me udhëzimet e marra përmes një kanali të veçantë, importojeni. Kur pika fundore duket e saktë, por kunjat ose CA nuk përputhen, kërkoni një skedar të korrigjuar. Kur skedari përzien pika fundore ose material CA nga burime të ndryshme, fshijeni dhe kërkoni një kopje të re.

Shënoni hash-in që shqyrtuat, që personi tjetër të dijë nëse skedari ndryshoi: sha256sum profile.ovpn, i ngjitur pranë pikës fundore në shënimet tuaja. Një profil është një rregullim i plotë, jo një listë adresash, prandaj mos futni kurrë një remote që funksionon në bllokun e besimit të dikujt tjetër duke mbajtur kredencialet e tyre.

Mbajini çelësat privatë dhe fjalëkalimet larg pamjeve të ekranit dhe temave të bisedës ndërsa krahasoni shënimet. Pika fundore dhe opsionet jo të fshehta mjaftojnë për një pyetje të saktë, dhe pjesa tjetër i përket skedarit.

Nëse megjithatë e importoni dhe përpjekja e parë dështon, ekzekutoni klientin me --verb 3 dhe lexoni dhjetë rreshtat e parë: adresa remote e zgjidhur, proto i negociuar dhe gabimi TLS shfaqen në këtë rend, që ju tregon cilën nga kontrollet më sipër keni anashkaluar.