Предупреждение OpenVPN AF_INET: безобидный откат или сбой создания сокета?

Две строки журнала OpenVPN начинаются с одних и тех же слов, и только одна из них сообщает о проблеме. Could not determine IPv4/IPv6 protocol. Using AF_INET — это уведомление об откате: профиль оставил семейство адресов открытым, поэтому демон выбрал одно и продолжил. Ветка сбоя сообщает, что сокет не создан, и требует перезапуска. Всё после общего префикса разделяет их, поэтому читайте дальше, прежде чем что-либо менять.

Что сообщает уведомление об откате

OpenVPN принимает явное семейство через proto udp4 или proto udp6, а также принимает proto udp, когда семейство должно выводиться при запуске. Во втором случае демон просматривает локальные сведения о привязке и выбирает.

Когда этот вывод срабатывает, предупреждение указывает направление, и процесс продолжает создавать сокет. Сервер с proto udp на хосте с двойным стеком часто оказывается так на IPv4. Ничто на этом пути не является ошибкой, и ничто в нём не намекает на атаку, отсутствующий веб-сервер или отклонённую учётную запись. Строка полезна только потому, что последующие проверки следует сравнивать с семейством, которое она называет.

Относитесь к этому как к ответу на один вопрос, а не как к диагнозу. Она говорит, какое семейство выбрал этот процесс, и ничего о том, почему клиент не может подключиться.

Как выглядит ветка сбоя

Позже в том же коде сокета есть ветка, где сокета нет вовсе. Она записывает более короткое сообщение о семействе адресов и требует перезапуска, потому что продолжать нечем. Начальные слова совпадают с откатом; результат — нет.

Различайте их по тому, что следует дальше. Если демон продолжает работать и сообщает о своём слушателе, строка была информацией. Если он завершается или перезапускается в цикле, речь теперь о привязке.

Найденная grep строка тоже не идентифицирует ветку. Фраза встречается в ротируемых сводках, в перенесённых строках и в выдержках журнала, которые люди вставляют из вторых рук, поэтому читайте соседние строки и порядок отметок времени, а не единственное совпадение.

Проверяйте слушателя, а не предупреждение

Работающий сервер отвечает на вопрос о семействе напрямую, без выводов из текста журнала.

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

Сопоставьте семейство, адрес и порт с профилем. Строка 0.0.0.0:1194 — только IPv4, тогда как строка [::]:1194 на хосте с двойным стеком может принимать оба семейства в зависимости от параметра bindv6only. Если профиль говорит udp, а сокет — IPv4, клиенты, чей резолвер возвращает только запись AAAA, потерпят неудачу ещё до того, как туннель будет согласован.

Затем проверьте с клиента, похожего на ваших пользователей: тот же путь резолвера, тот же тип сети. Локальное подключение с сервера доказывает очень мало о трафике, который проходит через устройство NAT или правило брандмауэра, написанное для другого семейства.

Когда принудительное семейство уместно

Закрепление proto udp4 подходит для развёртывания только с IPv4: DNS-имя только с A, правила брандмауэра для одного адреса v4, клиенты за операторами, которые выдают только адреса v4. Это устраняет неоднозначность и делает следующий набор строк журнала предсказуемым.

Тот же аргумент действует наоборот для среды с приоритетом IPv6, а udp6 перед базой клиентов только с A — это созданный вами же сбой. Принудительно задавать семейство только ради того, чтобы заглушить безобидное предупреждение, — классическая версия этой ошибки, потому что вы изменили, кто может подключаться, в обмен на более спокойный журнал.

Выбирайте по конечным точкам и клиентам, которые должны до них добраться. Руководство OpenVPN 2.6 документирует формы транспорта, и сообщение является результатом этого выбора, а не его входом.

Держите запись узкой

Запишите точную строку с её отметкой времени, действующую настройку транспорта из работающего профиля, сокет в том виде, как его сообщает ядро, и следующий этап, который завершился сбоем. Эти четыре пункта решают почти любой вопрос, который поднимает сообщение, и ни один из них не требует догадок о посторонних службах. Они также переживают передачу работы, чего не делает снимок экрана с grep.

Предложения пакетов, которые приходят вместе с этим предупреждением, не связаны с делом, пока ошибка не назовёт отсутствующий исполняемый файл.

Если ifconfig действительно отсутствует, демон называет это по имени, когда скрипт вызывает его, и это заслуживает отдельного расследования. Строка AF_INET и отсутствующая утилита — разные сбои, и установка чего-либо, чтобы посмотреть, изменится ли предупреждение, — это путь, которым чистый хост становится захламлённым.