Kiel kontroli la servilon de OpenVPN-profilo antaŭ ol importi ĝin

Iu sendas al vi profilon, vi importas ĝin, kaj tridek sekundojn poste kliento vokas celon, kiun neniu kontrolis. Unue legu la dosieron en teksta redaktilo, ĉar ĉio grava loĝas en plenmano da direktivoj: remote, proto, port, ca, cert, tls-crypt kaj verify-x509-name. Ĉio alia estas defaŭltoj, kaj la surprizoj loĝas ĝuste tie.

Listigu ĉiun finpunkton, kiun la dosiero povas uzi

Komencu per la finpunktoj, ĉar unu profilo povas enhavi plurajn. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn presas ĉiun kandidaton laŭ la ordo de la dosiero, inkluzive tiujn nestitajn en enliniaj blokoj <connection>.

Kiam direktivo preterlasas pordon, la kliento reiras al la defaŭlto de la aŭskultanto, do sola remote vpn.example.com signifas pordon 1194 kun kiu ajn proto aperos poste en la dosiero. Pluraj simplaj linioj remote estas alternativoj: la kliento provas ilin laŭvice se remote-random ne miksas ilin, kaj ĝi neniam silente anstataŭigas la gastigan nomon de alia funkciiganto. Du linioj remote ĉe malsamaj domajnoj estas la punkto, kie vi haltas kaj demandas, kiun oni celis.

Rimarku ankaŭ la literumadon de proto. tcp estas akceptata kiel sinonimo de la klientflanka tcp-client, sed tcp-server en klienta profilo estas agorda eraro, kiu emas ŝtopiĝi anstataŭ malsukcesi pure.

Konfirmu la nomon, poste la pordon

dig +short vpn.example.com diras al vi, ĉu la nomo ekzistas kaj kiujn adresojn ĝi redonas, kaj finpunkto kun pluraj adresoj aŭ malantaŭ prokura servilo povas laŭleĝe redoni plurajn. Nomrezolucio estas antaŭkondiĉo, ne pruvo de posedo; iu ajn povas direkti nomon al adreso, kaj unu adreso povas respondi por multaj nomoj.

Poste kontrolu la aŭskultanton ĉe la pordo, kiun vi trovis, laŭ la transporta tavolo. Super TCP openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com presas la ĉenon, kiun la servilo prezentas. Super UDP vi bezonas DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 plenumas la saman manpremon trans datagramoj. Kompletigita manpremo pruvas, ke io aŭskultas kaj tenas atestilon, kio estas pli ol ping montras kaj malpli ol la propraj fido-agordoj de la profilo postulas.

Kiam la manpremo malsukcesas kaj la gastiganto respondas al ping, la pordo verŝajne malĝustas aŭ estas filtrita. Rigardu tion kiel kialon peti la ĝustan pordon, ne kiel inviton balai la najbarajn. nc -vzu ankaŭ raportas sukceson sur iuj stakoj sen io aŭskultanta, do nuda UDP-sondo signifas nenion sen manpremo malantaŭ ĝi.

Legu la fido-pinglojn aparte de la adreso

La adreso decidas, kien la kliento iras; la fido-bloko decidas, kiun ĝi kredas post alveno. verify-x509-name "vpn.example.com" name pinglas la komunan nomon de la subjekto, kaj remote-cert-tls server postulas la etenditan uzadon de ŝlosilo por servila aŭtentikigo. Profilo donita al vi de funkciiganto devus porti ambaŭ.

Serĉu ca, enlinian blokon <ca>, kaj aŭ tls-crypt aŭ tls-auth. Profilo uzanta tls-auth bezonas key-direction 1 ĉe la kliento, kiam la servila flanko uzas direkton 0, kaj malkongrueco fuŝas la manpremon per TLS-eraro, kiu legeblas kiel atestila difekto. Enlinia CA, kiu ne apartenas al la funkciiganto, kies nomon vi ĵus solvis, signifas, ke la dosiero estis kunmetita el du fontoj, kaj tio estas la kazo, kiun indas firme rifuzi.

verify-x509-name akceptas reĝimojn name, name-prefix aŭ subject, kaj la lasta atendas plenan distingan nomon en la ĝusta ordo, en kiu la servilo presas ĝin. Elektu reĝimon kongruan al la formo de la valoro, ĉar la kliento rifuzas ĉiun konekton anstataŭ averti pri preskaŭa maltrafo. Por dosiero, kiun vi ne verkis, name kun simpla gastiga nomo estas la malplej surpriza elekto.

Kontrolu la opciojn, kiuj malsukcesas silente

OpenVPN 2.6 intertraktas ĉifrojn per data-ciphers, kaj profilo portanta nur malnovan linion cipher AES-256-CBC povas fini la regan kanalon kaj poste halti ĉe datumoj. Legi tiun valoron diras al vi, ĉu la dosiero antaŭas la servilon, al kiu vi aliĝas; la manlibra paĝo de 2.6 listigas la intertraktan ordon, se vi bezonas citi ĝin al la funkciiganto.

auth-user-pass sen dosiernomo signifas, ke la kliento demandos, do profilo, kiu aspektas memsufiĉa, ankoraŭ bezonas akreditaĵojn. auth-user-pass credentials.txt signifas, ke ĝi atendas dosieron, kiun vi verŝajne ne ricevis. nobind kaj resolv-retry infinite estas ordinaraj kaj senkulpaj, dum explicit-exit-notify estas nur por UDP kaj senutila super TCP.

Neniu el ĉi tiuj ŝanĝas, kien la profilo konektiĝas, sed ĉiu ŝanĝas, ĉu ĝi entute konektiĝos, kaj neniu vidiĝas en la importa dialogo de la kliento.

Decidu, poste registru, kion vi decidis

Post ĉi tiu legado ekzistas tri eblaj finoj, kaj nur unu estas importo. Kiam la finpunkto kaj la pingloj kongruas kun instrukcioj ricevitaj per aparta kanalo, importu ĝin. Kiam la finpunkto aspektas ĝusta sed la pingloj aŭ la CA ne kongruas, petu korektitan dosieron. Kiam la dosiero miksas finpunktojn aŭ CA-materialon el malsamaj fontoj, forigu ĝin kaj petu freŝan kopion.

Registru la haketon, kiun vi reviziis, por ke la sekva persono povu scii, ĉu la dosiero ŝanĝiĝis: sha256sum profile.ovpn, algluita apud la finpunkto en viaj notoj. Profilo estas tuta aranĝo, ne listo de adresoj, do neniam enmetu funkciantan remote en la fido-blokon de iu alia konservante ties akreditaĵojn.

Tenadu la privatajn ŝlosilojn kaj pasvortojn ekster ekrankopioj kaj babilaj fadenoj, dum vi komparas notojn. La finpunkto kaj la nesekretaj opcioj sufiĉas por preciza demando, kaj la resto apartenas al la dosiero.

Se vi tamen importas ĝin kaj la unua provo malsukcesas, rulu la klienton kun --verb 3 kaj legu la unuajn dek liniojn: la solvita adreso remote, la intertraktita proto kaj la TLS-eraro aperas en tiu ordo, kio diras al vi, kiun el la supraj kontroloj vi preterlasis.