Добавьте VPN площадки рядом с роутером провайдера, не обрывая звонки

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

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

Запишите роли, которые уже работают

Зафиксируйте шлюз по умолчанию, DHCP-сервер, резолвер и устройство, на котором держится голосовая регистрация провайдера. В этом примере роутер провайдера — 10.50.0.1, новый шлюз будет на 10.50.0.2, а удалённая площадка — 10.60.0.0/24. Ничто в этом плане не меняет первые три роли, и именно в этом смысл. Затем убедитесь, что второе устройство действительно может завершить нужный туннель: проверьте протокол, ожидаемую пропускную способность и получает ли оно обновления прошивки или пакетов. Устройство с логотипом VPN и без пути обновления — обуза, а не дополнение.

Если вы не можете сказать, кому принадлежит голосовая услуга, остановитесь. Замена роутера с регистрацией без плана отката превращает проект VPN в отказ телефонии.

Дайте новому шлюзу один адрес и одну задачу

Зарезервируйте его LAN-адрес вне пула DHCP, чтобы он не сдвинулся после перезагрузки, и не давайте ему собственный маршрут по умолчанию, если не хотите сделать его интернет-путём. Его задача — держать туннель и отвечать за удалённые префиксы. На хостах LAN, которым нужна удалённая площадка, докажите, каким путём они идут сейчас и какой нужен после изменения; те же две команды до и после — самая дешёвая проверка.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

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

Выберите, кому принадлежит маршрут удалённого префикса

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

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

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

Сделайте запись постоянной через владельца конфигурации хоста, а не через скрипт входа. Маршрут, который существует только после чьего-то входа, откажет при первой перезагрузке машины по посторонней причине.

Обеспечьте достижимую входящую точку

Шлюзу нужен адрес, до которого удалённая площадка может добраться. За роутером провайдера это означает проброс порта или запись DMZ, и оба зависят от того, действительно ли провайдер доставляет трафик. Локальный проброс не обходит NAT операторского уровня на стороне провайдера. Если провайдер не даёт достижимой точки, переверните направление: пусть обе площадки инициируют соединение к узлу, который вы контролируете. Это допустимый проект, но он добавляет третью зависимость для проброса, доверия и доступности, и динамический DNS её не заменяет.

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

Примите приватную услугу и голосовую линию вместе

Проверьте предполагаемую работу с хоста LAN, с приватным DNS и собственными учётными данными приложения. Маршрутизируемый туннель не делает удалённый просмотр похожим на локальный сегмент Ethernet, поэтому обнаружение и разрешение имён требуют своих мер.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

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

Похожие статьи