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 — конкретный пример клиентского приложения, которое ожидает соответствующую службу.