Како да го проверите серверот на OpenVPN профил пред да го увезете

Некој ви праќа профил, вие го увезувате и по триесет секунди клиент ѕвони на дестинација што никој не ја проверил. Прво прочитајте ја датотеката во текстуален уредувач, бидејќи сѐ важно се собира во шака директиви: remote, proto, port, ca, cert, tls-crypt и verify-x509-name. Сѐ друго се стандардни вредности и токму таму живеат изненадувањата.

Наведете ја секоја крајна точка што датотеката може да ја користи

Почнете од крајните точки, бидејќи еден профил може да содржи неколку. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn печати секој кандидат по редоследот на датотеката, вклучително и оние вгнездени во вградените <connection> блокови.

Кога директивата го испушта портот, клиентот се враќа на стандардната вредност на слушателот, па само remote vpn.example.com значи порт 1194 со кој и да proto се појави подоцна во датотеката. Неколку едноставни линии remote се алтернативи: клиентот ги пробува по ред, освен ако remote-random не ги измеша, и никогаш тивко не заменува домаќин на друг оператор. Две линии remote на неповрзани домени е точката каде што запирате и прашувате која била наменета.

Обрнете внимание и на правописот на proto. tcp се прифаќа како синоним за tcp-client на страната на клиентот, но tcp-server во клиентски профил е конфигурациска грешка што има тенденција да виси, наместо чисто да не успее.

Прво потврдете го името, потоа портот

dig +short vpn.example.com ви кажува дали името постои и кои адреси ги враќа, а крајна точка со повеќе адреси или зад посредник може законски да врати неколку. Решавањето на името е предуслов, а не доказ за сопственост; секој може да насочи име кон адреса, а една адреса може да одговара за многу имиња.

Потоа проверете го слушателот на портот што го најдовте, согласно со транспортниот слој. Преку TCP, openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com ја печати синџирот што го презентира серверот. Преку UDP ви треба DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 го изведува истиот ракување преку датаграми. Завршено ракување докажува дека нешто слуша и држи сертификат, што е повеќе отколку што покажува ping и помалку отколку што бараат сопствените поставки за доверба на профилот.

Кога ракувањето не успее, а домаќинот одговара на ping, портот најверојатно е погрешен или филтриран. Сфатете го тоа како причина да го побарате точниот порт, а не како покана да ги исчистите соседните. nc -vzu исто така пријавува успех на некои стекови кога ништо не слуша, па голо UDP испитување не значи ништо без ракување зад него.

Игличките за доверба читајте ги одделно од адресата

Адресата одлучува каде оди клиентот; блокот за доверба одлучува кому му верува кога ќе пристигне. verify-x509-name "vpn.example.com" name го закачува општото име на субјектот, а remote-cert-tls server бара проширена употреба на клучот за автентикација на серверот. Профилот што ви го дава оператор треба да ги носи двете.

Барајте ca, вграден <ca> блок и или tls-crypt, или tls-auth. Профилот со tls-auth бара key-direction 1 на клиентот кога страната на серверот користи насока 0, а несовпаѓањето го урива ракувањето со TLS грешка што се чита како дефект на сертификатот. Вграден CA што не му припаѓа на операторот чие име штотуку го решивте значи дека датотеката е составена од два извора, и токму тој случај вреди да се одбие решително.

verify-x509-name прифаќа режими name, name-prefix или subject, а последниот очекува целосно различно име во точниот редослед во кој серверот го печати. Изберете режим што одговара на формата на вредноста, бидејќи клиентот го одбива секое поврзување наместо да предупреди за блиско промашување. За датотека што не сте ја напишале, name со едноставно име на домаќин е најмалку изненадувачки избор.

Проверете ги опциите што тивко не успеваат

OpenVPN 2.6 ги договара шифрите преку data-ciphers, а профилот што носи само стара линија cipher AES-256-CBC може да го заврши контролниот канал и потоа да застане на податоците. Читањето на таа вредност ви кажува дали датотеката е постара од серверот на кој се приклучувате; страницата од прирачникот за 2.6 го наведува редоследот на договарање ако треба да го цитирате на операторот.

auth-user-pass без име на датотека значи дека клиентот ќе праша, па профил што изгледа самодоволен сѐ уште бара акредитиви. auth-user-pass credentials.txt значи дека очекува датотека што веројатно не ви била пратена. nobind и resolv-retry infinite се вообичаени и безопасни, додека explicit-exit-notify е само за UDP и бесмислен преку TCP.

Ништо од ова не менува каде се поврзува профилот, но секое менува дали воопшто ќе се поврзе, и ништо од тоа не е видливо во дијалогот за увоз на клиентот.

Одлучете, потоа запишете што одлучивте

По ова читање има три исходи и само еден е увоз. Кога крајната точка и игличките се совпаѓаат со упатствата добиени преку одделен канал, увезете го. Кога крајната точка изгледа точна, но игличките или CA не се совпаѓаат, побарајте поправена датотека. Кога датотеката меша крајни точки или CA материјал од различни извори, избришете ја и побарајте свежа копија.

Запишете го хешот што го прегледавте, за следниот човек да знае дали датотеката се променила: sha256sum profile.ovpn, залепен до крајната точка во вашите белешки. Профилот е целосен распоред, не список на адреси, па никогаш не вметнувајте работен remote во туѓ блок за доверба задржувајќи ги нивните акредитиви.

Држете ги приватните клучеви и лозинките надвор од слики од екран и чет-нишки додека ги споредувате белешките. Крајната точка и недоверливите опции се доволни за прецизно прашање, а остатокот му припаѓа на датотеката.

Ако сепак го увезете и првиот обид не успее, стартувајте го клиентот со --verb 3 и прочитајте ги првите десет линии: решената remote адреса, договорениот proto и TLS грешката се појавуваат по тој редослед, што ви кажува која од проверките погоре сте ја прескокнале.