Две сотовые площадки без входящих портов: постройте работающий концентратор

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

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

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

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

Две команды отвечают на вопрос об адресации площадки, перед которой вы стоите. Запускайте их на маршрутизаторе площадки, а не на ноутбуке за ним:

ip -4 addr show scope global
ip -6 addr show scope global

Кто знакомит узлы и кто несёт пакеты

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

Прохождение имеет свой словарь, и слова описывают роли, а не гарантии. Спецификация ICE описывает кандидатов и проверки связности, STUN описывает один способ узнать о трансляции адресов, а TURN описывает ретранслируемый транспорт для приложений, которые его реализуют. Ни один из этих механизмов не появляется в обычном шлюзе, потому что вы направили его на адрес обнаружения. Проверяйте прохождение как возможность продукта и предполагайте ретранслятор, пока тест не покажет обратное.

Один маршрут на площадку, принадлежащий узлу

Концентратору нужен один туннель на площадку, отдельный префикс LAN за каждой и маршрут для каждого префикса, называющий его владельца. В примере концентратор — 10.61.0.1, площадка A — 10.61.0.11 с LAN 10.60.10.0/24, а площадка B — 10.61.0.12 с LAN 10.60.20.0/24. Каждый маршрут ниже указывает на узел, владеющий префиксом, а не на интерфейс туннеля:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

Пересылка должна быть включена, иначе пакеты останавливаются на концентраторе без ошибки, указывающей причину. Последняя команда отвечает на настоящий вопрос, потому что спрашивает, какой путь выберет пакет от LAN площадки A к LAN площадки B с источником, включённым в поиск. Считайте поиск, называющий интерфейс туннеля, доказательством, а поиск, падающий на маршрут по умолчанию, — отсутствующим маршрутом, а не загадкой. Затем намеренно ограничьте транзит, потому что концентратор, пересылающий между любыми узлами, превращает две площадки в плоскую сеть, и политика доступа, которую вы думали, что имеете, перестаёт действовать.

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

Поддерживайте каждое сопоставление живым через оператора

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

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

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

Докажите оба направления, затем докажите восстановление

Проверка направленная, поэтому ping от A к B доказывает половину проекта и ничего не говорит о обратном пути. Проверьте путь ответа тем же поиском с учётом источника на концентраторе, затем повторите тест с другой стороны. Свежие рукопожатия тоже относятся к доказательствам, потому что туннель, простоявший час, может проверять старое сопоставление:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

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