Какой адрес указывать в DNS для сервера, подключённого через VPN?
У размещённого сервера есть три адреса, и они не взаимозаменяемы. Выберите значение, которое нужно каждой службе, а затем подтвердите его снаружи машины.
У размещённого сервера с установленным VPN в итоге оказывается три адреса, и только один из них принадлежит каждому месту, которое вы собираетесь настроить. Копирование номера из панели провайдера в DNS, в слушатель или в список разрешений — это путь, на котором работающий туннель превращается в службу, до которой никто не может добраться. Это руководство упорядочивает работу так, чтобы каждый адрес выбирался для заявленной цели. Оно также перечисляет команды, которые подтверждают то, что вы действительно опубликовали.
Составьте карту трёх адресов, прежде чем что-либо публиковать
Называйте их по функции. Адрес underlay — это то, что машина использует для доступа к конечной точке VPN через интернет, и он часто приватный за NAT провайдера. Адрес туннеля живёт внутри VPN и выдаётся сервером или клиентом в зависимости от продукта. Публичный выход — это адрес, который удалённый сайт записывает после трансляции, и ему не нужно существовать ни на одном интерфейсе, который вы можете опросить.
Панель, показывающая один публичный адрес для машины, очень мало говорит о двух других ролях. Доступность underlay — это требование, а не покупка: ноутбук за домашним маршрутизатором может добраться до размещённой конечной точки VPN, не владея публичным адресом IPv4. Чего вы не можете, так это выдумать входящий путь, написав имя, которое разрешается в адрес, который никто не перенаправляет.
Выбирайте адрес по службе, а не по ярлыку
Запишите, что сервер должен делать, прежде чем выбирать номер. Исходящим вызовам API нужен стабильный выход, когда противоположная сторона ведёт список разрешений. Приватному доступу нужен адрес туннеля, на который клиенты могут маршрутизировать, и привязанный к нему слушатель. Публичному хостингу нужно входящее сопоставление, которое провайдер действительно предлагает, и один лишь адрес выхода его не даёт.
Одна машина может обслуживать все три цели и при этом использовать три разных адреса. Ломается предположение, что одно значение покрывает их все:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
Входящая строка — та, о которой спорят люди. Запись, указывающая на адрес выхода, не создаёт слушателя, открытия брандмауэра или сопоставления порта, и ожидание этого не меняет. Когда провайдер продаёт выделенный адрес вместе с входящим правилом, этот пакет и есть возможность, которую вы купили; сам адрес не является правом.
Команды, которые показывают, какой адрес какой
Читайте машину, а не панель. Имена интерфейсов различаются между системами, поэтому сопоставляйте адреса с устройствами, а не доверяйте ярлыку.
Первая строка перечисляет каждый адрес IPv4 и его устройство, а вторая спрашивает у ядра, какое устройство оно использовало бы для известного внешнего назначения:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'Если поиск маршрута отвечает устройством туннеля для публичного трафика, ваш полный туннель действует. Проверка слушателя не менее важна, потому что процесс, привязанный только к 127.0.0.1, никогда не ответит на адресе туннеля, какое бы имя вы ни опубликовали.
Опубликуйте его, затем проверьте снаружи
Опубликуйте только то значение, которое нужно службе: запись A или AAAA для хостинга, запись в списке разрешений для исходящих вызовов, профиль клиента для приватного доступа. Затем проверьте с той позиции, которая важна, и это никогда не машина, которую вы только что правили.
Две проверки охватывают большую часть, и обе достаточно дешевы, чтобы держать их в скрипте:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthОтвет DNS, доказывающий, что ваша запись существует, не доказывает, что запрос доходит, а один успешный запрос доказывает лишь то, что один путь работает из одной сети. Повторите проверку через мобильное соединение, когда задействован список разрешений, потому что наблюдаемый выход может зависеть от семейства адресов и выбранного маршрута. Отметьте, какое семейство вы проверили; работающий путь IPv4 ничего не говорит об IPv6.
Если служба входящая, адреса выхода недостаточно
Входящему доступу нужны четыре согласованные вещи: имя или адрес, до которого клиент может добраться, маршрут, доставляющий пакет машине, слушатель, который его принимает, и политика, которая его не отбрасывает. VPN меняет второй элемент и иногда первый, а для третьего и четвёртого не делает ничего. Когда туннель является путём доставки, клиенты подключаются к адресу туннеля, а не к выходу.
Запишите, от какого адреса зависит каждая служба, и пересматривайте эту запись каждый раз, когда провайдер меняет свою модель маршрутизации. Сервер, который отвечает приватно и терпит неудачу публично, обычно не сломан; он отвечает под неправильной личностью, и исправление — это решение о сопоставлении, а не изменение брандмауэра.