Cineva vă trimite un profil, îl importați, iar treizeci de secunde mai târziu un client apelează o destinație pe care nimeni nu a verificat-o. Citiți mai întâi fișierul într-un editor de text, pentru că tot ce contează încape într-o mână de directive: remote, proto, port, ca, cert, tls-crypt și verify-x509-name. Restul sunt valori implicite, și acolo locuiesc surprizele.

Enumerați fiecare punct final pe care fișierul îl poate folosi

Începeți cu punctele finale, pentru că un profil poate conține mai multe. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn tipărește fiecare candidat în ordinea fișierului, inclusiv pe cele imbricate în blocuri <connection> inline.

Când o directivă omite portul, clientul revine la valoarea implicită a ascultătorului, așa că doar remote vpn.example.com înseamnă portul 1194 cu orice proto care apare mai târziu în fișier. Mai multe linii remote simple sunt alternative: clientul le încearcă în ordine dacă remote-random nu le amestecă, și nu înlocuiește niciodată în tăcere gazda altui operator. Două linii remote pe domenii fără legătură este punctul în care vă opriți și întrebați care era cea dorită.

Observați și ortografia lui proto. tcp este acceptat ca sinonim pentru tcp-client din partea clientului, dar tcp-server într-un profil de client este o eroare de configurare care tinde să se blocheze în loc să eșueze curat.

Confirmați numele, apoi portul

dig +short vpn.example.com vă spune dacă numele există și ce adrese returnează, iar un punct final cu mai multe adrese sau aflat în spatele unui proxy poate returna mai multe în mod legitim. Rezolvarea numelui este o condiție prealabilă, nu o dovadă de proprietate; oricine poate îndrepta un nume către o adresă, iar o adresă poate răspunde pentru multe nume.

Apoi verificați ascultătorul pe portul găsit, în acord cu transportul. Pe TCP, openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com tipărește lanțul pe care îl prezintă serverul. Pe UDP aveți nevoie de DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 execută același handshake peste datagrame. Un handshake finalizat dovedește că ceva ascultă și deține un certificat, ceea ce este mai mult decât arată un ping și mai puțin decât cer propriile setări de încredere ale profilului.

Când handshake-ul eșuează și gazda răspunde la ping, portul este probabil greșit sau filtrat. Luați asta ca motiv să cereți portul corect, nu ca invitație de a mătura porturile vecine. nc -vzu raportează și succes pe unele stive fără ca nimic să asculte, așa că o simplă sondă UDP nu înseamnă nimic fără un handshake în spate.

Citiți pinii de încredere separat de adresă

Adresa decide unde merge clientul; blocul de încredere decide în cine crede când ajunge. verify-x509-name "vpn.example.com" name fixează numele comun al subiectului, iar remote-cert-tls server cere utilizarea extinsă a cheii pentru autentificarea serverului. Un profil oferit de un operator ar trebui să le conțină pe amândouă.

Căutați ca, un bloc <ca> inline și fie tls-crypt, fie tls-auth. Un profil care folosește tls-auth are nevoie de key-direction 1 pe client când partea de server folosește direcția 0, iar o nepotrivire face handshake-ul să eșueze cu o eroare TLS care se citește ca un defect de certificat. Un CA inline care nu aparține operatorului căruia tocmai i-ați rezolvat numele înseamnă că fișierul a fost asamblat din două surse, și acesta este cazul care merită refuzat categoric.

verify-x509-name acceptă modurile name, name-prefix sau subject, iar ultimul așteaptă un nume distinctiv complet în exact ordinea în care serverul îl tipărește. Alegeți un mod care se potrivește formei valorii, pentru că clientul respinge fiecare conexiune în loc să avertizeze despre o apropiere. Pentru un fișier pe care nu l-ați scris, name cu un nume de gazdă simplu este alegerea cea mai puțin surprinzătoare.

Verificați opțiunile care eșuează în tăcere

OpenVPN 2.6 negociază cifrurile prin data-ciphers, iar un profil care poartă doar o linie veche cipher AES-256-CBC poate finaliza canalul de control și apoi să se blocheze pe date. Citirea acelei valori vă spune dacă fișierul este mai vechi decât serverul la care vă alăturați; pagina de manual a versiunii 2.6 enumeră ordinea negocierii dacă trebuie să o citați operatorului.

auth-user-pass fără nume de fișier înseamnă că clientul va întreba, așa că un profil care pare autosuficient are totuși nevoie de acreditări. auth-user-pass credentials.txt înseamnă că așteaptă un fișier care probabil nu v-a fost trimis. nobind și resolv-retry infinite sunt obișnuite și inofensive, în timp ce explicit-exit-notify este doar pentru UDP și inutil pe TCP.

Nimic din toate acestea nu schimbă unde se conectează profilul, dar fiecare schimbă dacă se conectează deloc, și niciuna nu este vizibilă în dialogul de import al clientului.

Decideți, apoi notați ce ați decis

După această lectură există trei rezultate, și doar unul este importul. Când punctul final și pinii corespund instrucțiunilor primite pe un canal separat, importați-l. Când punctul final pare corect, dar pinii sau CA nu corespund, cereți un fișier corectat. Când fișierul amestecă puncte finale sau material CA din surse diferite, ștergeți-l și cereți o copie nouă.

Notați hash-ul pe care l-ați revizuit, ca următoarea persoană să știe dacă fișierul s-a schimbat: sha256sum profile.ovpn, lipit lângă punctul final în notițele dumneavoastră. Un profil este o aranjare întreagă, nu o listă de adrese, așa că nu îmbinați niciodată un remote funcțional în blocul de încredere al altcuiva păstrând acreditările acestuia.

Țineți cheile private și parolele departe de capturi de ecran și fire de chat în timp ce comparați notițe. Punctul final și opțiunile nesecrete sunt suficiente pentru o întrebare precisă, iar restul își are locul în fișier.

Dacă totuși îl importați și prima încercare eșuează, rulați clientul cu --verb 3 și citiți primele zece linii: adresa remote rezolvată, proto negociat și eroarea TLS apar în această ordine, ceea ce vă spune care dintre verificările de mai sus a fost sărită.

Articole similare