Как да проверите сървъра на профил 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 грешката се появяват в този ред, което показва коя от проверките по-горе сте пропуснали.