OpenVPN работает дома, но не в одной сети: UDP или TCP?

Тот же профиль подключается из дома и останавливается в сети отеля, кампуса или филиала. Учётные данные не изменились, поэтому интересная переменная — путь: что происходит с пакетами до того, как OpenVPN их прочитает. Сравнить четыре возможные причины в том порядке, в каком их можно проверить, лучше, чем гадать о сертификатах. Каждая оставляет свой след, и именно след их разделяет.

Какой этап отказал — это и определяет, какое сравнение важно

Журнал клиента уже фиксирует, как далеко вы продвинулись. Строка о том, что согласование ключа TLS не произошло в пределах тайм-аута, означает, что первый пакет ушёл и ничего пригодного не вернулось, а это указывает на путь. Отказ сертификата выглядит совсем иначе: приходит ответ, а затем конкретная ошибка проверки называет причину. Запишите последнюю строку перед циклом повторных попыток, потому что именно это значение вы сравниваете между сетями.

Снимайте трафик во время повторной попытки, а не после. На клиенте tcpdump -ni any udp port 1194 показывает, возвращается ли вообще какой-либо ответ. Повторите на WAN-интерфейсе сервера, который вы контролируете, — это покажет, доходят ли эти пакеты до дальнего конца.

Односторонний трафик — самый полезный результат, доступный здесь, потому что он превращает периодическую жалобу в направление расследования. Сохраните файлы захвата, потому что следующий отчёт о той же проблеме проще закрыть доказательствами, чем описанием.

Фильтрация UDP против закрытого порта

Многие сети доступа считают постоянный UDP подозрительным, и некоторые ISP с ними согласны. Закрытый порт создаёт ту же тишину со стороны клиента. Разница — в избирательности: фильтр обычно придирчив к тому, какие назначения или порты отбрасывает, а закрытый порт отвергает всё, что направлено на этот порт.

Профиль TCP на порту 443 — обычный обходной путь, потому что он похож на обычный поток HTTPS и проходит через большинство captive-порталов и исходящих фильтров. Должны выполняться два условия. Сервер должен слушать с proto tcp-server, клиент должен совпадать с proto tcp-client, а оператор должен опубликовать эту альтернативную точку. Переписать рабочий UDP-профиль под TCP 443 бесполезно, если на другом конце никто не слушает.

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

Старые протоколы проигрывают по этой оси. PPTP требует TCP 1723 плюс GRE, а GRE — это IP-протокол 47, а не порт, поэтому обычное перенаправление порта его не выражает.

Когда пакеты теряет коммутатор

Управляемый коммутатор может намеренно отбрасывать туннель. Некоторые модели HPE и Aruba предлагают элемент управления защитой от UDP-flood, иногда с меткой Prevent UDP Blat Attack, в разделе расширенной безопасности. Как только этот элемент активен, сервер за коммутатором ни на что не отвечает, и каждый клиент завершается по тайм-ауту одинаково. Отключить его и сохранить текущую конфигурацию — вот весь ремонт, но только после того, как вы убедитесь, что коммутатор действительно находится на пути.

Контрдоказательства — это то, что отличает потерю на коммутаторе от блокировки провайдера. Прочитайте счётчики интерфейса и журнал защиты от flood, прежде чем открывать заявку у ISP. Потребительские роутеры с защитой от DoS или flood отказывают так же, как и любой промежуточный узел с коротким тайм-аутом простоя UDP. Рукопожатие, которое никогда не завершается, указывает на потерю, а туннель, умирающий через несколько минут тишины, указывает на тайм-аут.

Запишите каждое устройство между клиентом и сервером, прежде чем менять профиль. Исправление, применённое не на том уровне, выглядит верным до следующей сети. Этот список также подскажет следующему инженеру, куда смотреть, не повторяя всё расследование.

Перекрытие адресов, похожее на сбой DNS

Сеть доступа, пронумерованная внутри 10.0.0.0/8, может перекрываться с пулом туннеля, и резолвер обычно живёт внутри этого пула. Когда ноутбук получает адрес вроде 10.184.178.50 с маской /8 по Wi-Fi, каждое назначение 10.x по определению является локальным. Пакеты к 10.4.0.1 тогда уходят в LAN, туннель остаётся поднятым, а разрешение имён не работает.

ip addr показывает перекрытие с первого взгляда, а ip route get 10.4.0.1 показывает, куда пакет был бы доставлен на самом деле. Поскольку видимый симптом — сбой резолвера, это часто переживает несколько раундов изменения DNS.

Перенумеруйте пул или держите эту сеть доступа вне области. Никакая настройка на стороне клиента не спасает от перекрытия.

Выбор между резервным TCP и исправлением пути

Выбирайте резервный TCP, когда вы не контролируете путь и пользователям нужно работать сегодня, и принимайте его издержки: TCP внутри TCP плохо ведёт себя на каналах с потерями, а резерв требует слушателя, которым управляете вы. Выбирайте исправление пути, когда блокировка находится на вашей инфраструктуре, потому что правило брандмауэра дешевле второго слушателя. В любом случае проходите уровни по порядку: канал, внешний транспорт, согласование, внутренняя маршрутизация. Этап, который отказал в той сети, — единственный важный факт.

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