Телефон се свързва с VPN на рутера без оплакване, а лаптоп с профил от същата страница за изтегляне изтича. Нищо в сертификатите не се е променило между тези два опита, защото лаптопът така и не стигна до момента, в който сертификатите имат значение. Рутерът публикува отделни слушатели за TUN и TAP и работещият профил трябва да избере този, който принадлежи на неговия собствен тип устройство.

Да решиш кой от три възможни дефекта да преследваш е цялата работа тук: портът, типът устройство или договарянето на шифъра на канала за данни.

Три неща, които трябва да съвпадат

Типът устройство, редът на интерфейса в профила и портът на слушателя образуват един избор, а не три. Профил, който обявява dev tun и е насочен към слушателя TAP, не може да завърши сесията, а обратното се проваля по идентичен начин. За вашия модел и фърмуер четете порта от собствената VPN страница на рутера, а не от ръководство, защото числата се менят между версиите. Запишете модела и версията на фърмуера до това число, за да може следващият човек да го провери.

Доклади от терен споменават двойка като 12973 за TUN и 12974 за TAP на един фърмуер и различно число на друг. Четете ги като доказателство, че версиите се различават, а не като константи за копиране. След това профилът се нуждае от подходящо за разстоянието име на хост: динамичното DNS име на рутера, а не WAN адрес, който ще се промени.

След коригиране на порта и реда на интерфейса профилът изглежда като нормална клиентска конфигурация с един ред remote и един ред dev. Ако двете не съвпадат, никакво повторение не създава сесия.

Четете журнала в реда, в който се отпечатва

Клиент на OpenVPN съобщава събитията в реда, в който се случват, така че последният ред преди тишината определя слоя за проверка. Когато пускането завърши на TLS Error: TLS key negotiation failed или просто изчака първи отговор и се откаже, сравнение на сертификати никога не е ставало. Това сочи към достъпност, към слушателя или към порт, зад който няма нищо. Никое от тях не се поправя чрез смяна на CA файла.

Пускане, което стига до VERIFY OK и след това се проваля, стои съвсем другаде, със свои причини. Разграничаването на тези два изхода преди да пипате файлове предотвратява класическата обиколка през пакети със сертификати, които никога не са били питани. След като ръкостискането завърши, но тунелът не се вдигне, гледайте договарянето на шифъра вместо достъпността.

Добавете списъка с шифри, който съвременният клиент очаква

Скорошните клиенти на OpenVPN отказват стари стойности по подразбиране, които фърмуерът на потребителските устройства още предлага, а симптомът е провал в договарянето веднага след успешно ръкостискане. Поправката е един ред в профила, който назовава какво ще приеме клиентът: задайте data-ciphers на AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 и AES-128-CBC в този ред. Всеки алгоритъм, който рутерът не реализира, просто никога не се избира, така че по-дълъг списък не струва нищо освен малко по-дълго договаряне.

Изброяването на шифри не учи рутера на такъв, който няма. Ако договарянето продължава да се проваля, проверете дали страницата на рутера има собствена настройка за шифър и дали тя включва поне един запис, който клиентът приема. Два списъка без общ член дават точно същия провал като грешен порт, затова и двата края заслужават поглед.

Импортирайте веднъж вместо ръчно редактиране на копия

Импортирането на коригирания файл в NetworkManager избягва папка, пълна с леко различни профили: nmcli connection import type openvpn file client.ovpn, след което го вдигнете по име. Пазете импортирания профил като единственото копие, което редактирате, и изтривайте дубликатите, които се натрупват от повторни изтегляния.

След това тествайте извън LAN. Свързването от същата мрежа доказва много малко, защото трафикът може изобщо да не минава през тунела. Потвърдете, че заявка наистина излиза през рутера, а не само че клиентът показва свързано състояние.

Решете какво да правите с предупрежденията

Фърмуерът на потребителските устройства обикновено създава собствен сертифициращ орган и клиентите се оплакват от проверката по начини, които фърмуерът не може да потисне. Преценете дали това оплакване има значение за това, което защитавате, вместо да третирате всяко предупреждение като фатално, и не изключвайте проверката глобално, за да заглушите едно съобщение. Предупреждение, което сте преценили, е документиран риск; настройка за проверка, която сте изключили, е недокументирана.

Когато фърмуерът не предоставя поддържан начин да коригирате предупреждение, което наистина има значение, тази празнина говори в полза на това да хоствате VPN другаде. Изборът между поправяне на профила, приемане на предупреждението и преместване на крайната точка е решение за това колко вярвате на този сертификат. Вземете го съзнателно и запишете коя опция сте избрали, вместо да щракате през диалози, докато иконата стане зелена.

Подобни статии