Шта заправо садржи .ovpn датотека и шта не може
.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-а које старији клијент одбија је проблем верзије који треба решити са оператером. Укључивање непознатих привилегија да би се увоз изнудио мења упозорење за ширу површину напада.
Сачувајте оригиналну датотеку за поређење, наведите тачну неподржану директиву у захтеву и затражите профил направљен за клијента који заиста покрећете.
Након сваке замене проверите који унос профила апликација користи, јер увоз нове датотеке не преписује увек стару.