Што насамрэч змяшчае файл .ovpn і чаго ён не можа

Большасць людзей мяркуе, што файл .ovpn наладжвае VPN. Гэта не так: ён наладжвае адзін кліент, і ўсё, што ён запытвае, ужо мусіць існаваць на іншым баку. Змена радка ў файле можа змяніць тое, што спрабуе ваша машына, але ніколі тое, што прапануе сервер. Гэтая розніца тлумачыць большую частку блытаніны вакол профіляў, якія не імпартуюцца або не падключаюцца.

Чытайце файл як спіс запытаў, адрасаваных вашаму кліенту, і большасць яго радкоў стане відавочнай.

Файл апісвае ваш кліент, а не сервер

Профіль аб’ядноўвае remote канцавы пункт, транспарт, тып інтэрфейсу, матэрыял ідэнтычнасці і любыя паводзіны на баку кліента, якіх патрабуе аператар. Кожны радок выконваецца кліентам пры запуску. Ні адзін з іх не дасягае сервера як змена канфігурацыі, і ні адзін не можа стварыць слухач, які ўжо не працуе. Профіль, які паказвае TCP 443 супраць сервера, што слухае толькі UDP 1194 зрываецца на першым пакеце.

Менавіта таму адзін і той жа файл паводзіць сябе па-рознаму на двух кліентах: файл просіць, а кліент вырашае, якую частку запыту ён можа выканаць.

Радкі транспарту мусяць адпавядаць слухачу, які ўжо існуе

proto і remote радкі мусяць узгадняцца з тым, што сервер фактычна прывязвае. UDP — звычайны выбар, бо страчаная дэйтаграма не спыняе тунель, тады як TCP можа вытрываць абмежаваныя сеткі коштам блакавання чаргі ўнутры тунеля. Пераключэнне профілю з UDP на TCP не прымусіць сервер прымаць TCP; яно толькі прымусіць кліент слаць на порт, які ніхто не чытае.

Порт 443 папулярны, бо праходзіць праз сеткі, якія амаль нічога іншага не дазваляюць, і застаецца OpenVPN сесіяй, а не HTTPS-запытам. Калі аператар публікуе некалькі remote радкоў, кліент спрабуе іх па чарзе, што ёсць спісам пераключэння пры збоі, а не рашэннем аб балансаванні нагрузкі. Трымайце камбінацыі, якія паставіў аператар, замест таго каб змешваць хост з аднаго запісу з портам з іншага.

Убудаваныя ключы змяняюць тое, як вы абыходзіцеся з файлам

Сертыфікаты і ключы могуць знаходзіцца ўбудаванымі паміж тэгамі <ca>, <cert> і <key>, або на іх могуць спасылацца як на асобныя файлы. Убудаваны матэрыял робіць профіль самадастатковым і адначасова робіць яго сакрэтам, бо прыватны ключ кліента падарожнічае ўнутры яго. Сертыфікат CA — публічны матэрыял даверу, і ім бяспечна дзяліцца; прыватны ключ — не, нават калі ён выглядае як нечытэльны блок тэксту.

Парольная фраза, якая абараняе ключ, — асобны сакрэт ад пароля ўліковага запісу, і іх блытаніна дае памылку аўтэнтыфікацыі, якая выглядае як няправільныя даныя ўваходу.

Маршруты і DNS могуць зусім не паходзіць з файла

Маршрутызацыю можа праштурхоўваць сервер, задаваць профіль праз redirect-gateway, або яна можа застацца на ўласных прадвызначэннях кліента. Таму спампаваны файл не вызначае цалкам, куды пойдзе трафік пасля ўздыму тунеля. Калі ўнутраныя імёны развязаюцца, а публічныя сайты не, палітыка раздзеленага тунеля робіць тое, для чаго створана, а не церпіць няўдачу.

DNS ідзе па той жа схеме: праштурхоўваны dhcp-option DNS можа ўжывацца кліентам, ігнаравацца або перакрывацца лакальным кіраўніком рэзалвера. Праверце стан рэзалвера пасля падключэння, а не чытайце профіль яшчэ раз.

Неподтрымліваемыя опцыі — гэта пытанне версіі кліента

Папярэджанні пры імпарце звычайна азначаюць, што кліент не рэалізуе дырэктыву, а не што файл пашкоджаны. Настольныя кліенты могуць запускаць скрыпты і плагіны ў межах дакументаваных абмежаванняў, тады як мабільныя кліенты прымаюць вузкі набор і могуць маўкліва адкідваць радкі, якіх не разумеюць. Налада шыфра або TLS, якую адмаўляе старэйшы кліент, — гэта праблема версіі, якую трэба вырашаць з аператарам. Уключэнне невядомых прывілеяў, каб праштурхнуць імпарт, абменьвае папярэджанне на шырэйшую паверхню атакі.

Захавайце арыгінальны файл для параўнання, адзначце дакладную неподтрымліваемую дырэктыву ў запыце і папрасіце профіль, пабудаваны для кліента, які вы фактычна выкарыстоўваеце.

Пасля любой замены пацвердзіце, які запіс профілю выкарыстоўвае праграма, бо імпарт новага файла не заўсёды перазапісвае стары.