VPN сървър на Raspberry Pi: започнете от приложението на телефона, а не от рецептата

Повечето сборки на VPN на Raspberry Pi започват с рецептата за сървъра и завършват с телефон, който не може да се свърже. Редът е обърнат. Клиентът на телефона реализира конкретен протокол с конкретен обмен за удостоверяване и сървърът трябва да съответства на този обмен, а не обратното. Ако първо изберете приложението, цял следобед отстраняване на грешки се превръща в кратък списък за проверка.

Редът, който спестява преправянето

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

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

След като приложението е фиксирано, изборът на сървър се стеснява и останалата част от сборката има цел.

Какво всъщност реализира приложението на телефона

Публикуван списък с клиенти описва приложение, а не услуга. Приложението OpenVPN Connect за Android очаква сървър OpenVPN; то не предоставя сървърната страна. То също не става клиент на IPsec или L2TP, когато профилът изглежда подобен.

Това разграничение е най-важно, когато следвате по-стар наръчник. Рецепти, написани за протокол, който текущото приложение е изоставило, все още ще се инсталират чисто на Pi и все още ще се провалят на телефона, което изглежда като грешка в конфигурацията, а не като несъответствие на протокола.

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

Четиристранното споразумение

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

Надграждане на приложението, смяна на пакета на сървъра или нов сертификатен орган развалят споразумението и от телефона провалът изглежда еднакво всеки път. Именно записаните четири елемента ви позволяват да установите коя част се е преместила.

Идентификационните данни имат отделни задачи

Решете дали профилът използва клиентски сертификати, потребителско име и парола или поддържана комбинация, и накарайте двете страни да се съгласят. Самоличността на сървъра и материалът на доверения CA също трябва да съответстват на това, което клиентът ще приеме.

Публичният сертификат на CA и неговият частен ключ за подпис са различни обекти. В профила на телефона принадлежи само публичната част. Ако поставите ключа за подпис на телефона, вие давате възможност да се създават самоличности, което е обратното на предназначението на CA. Отнасяйте се към този файл като към най-чувствителния обект в цялата сборка.

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

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

Достижимостта е отделен договор

Телефонът трябва да достигне външната крайна точка на сървъра през реалната схема нагоре по веригата. Транслацията на домашния рутер, филтрирането и NAT на оператора стоят между двете. Динамичното DNS име дава на крайната точка само стабилно име; то не създава входящ път.

След това определете какво може да достигне клиентът след свързване: частни префикси или пълен изход към интернет, техните пътища за препращане и отговор, поведението на DNS и дали IPv6 е в обхвата. Успешният вход не доказва нищо от това.

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