WireGuard 5G у філії: нехай філія сама телефонує до центру

Коли філія телефонує до центру, центру ніколи не потрібно виявляти змінну мобільну адресу. Налаштуйте, перевірте, а потім подивіться, чого це не вирішує.

Спрямувати філію на центр — це легка половина цього рішення, коли філія стоїть за змінною мобільною адресою, а центр має стабільне ім’я. Тоді центр вивчає філію з автентифікованого трафіку, а не із запису, який вам доводиться підтримувати актуальним. Договір простий: філія завжди ініціює.

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

Яка сторона тримає стабільну кінцеву точку

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

Коли філія надсилає автентифікований пакет, центр записує джерело, з якого той прийшов, і використовує це зіставлення для відповідей. Перенумерація мобільного каналу тоді не коштує нічого, крім наступного рукостискання, і кожен компонент, який вам більше не потрібен, — це той, що не може відмовити під час перемикання. Цю властивість варто перевіряти під час планованої зміни, а не під час інциденту. Зробіть це, поки хтось може дивитися на обидва кінці одночасно.

Дайте філії конфігурацію, яка переживає перенумерацію

Тримайте кінцеву точку та keepalive на боці філії, а запис партнера в центрі тримайте без жорстко заданої адреси. keepalive тримає перекладене зіставлення відкритим достатньо довго, щоб центр міг надіслати незапитаний трафік після періоду простою.

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

Двадцять п’ять секунд — це часто цитований приклад для підтримання зіставлення NAT живим, а не вимога для кожного партнера. Задавайте його за тим тайм-аутом зіставлення, який ви реально спостерігаєте, і пам’ятайте, що він створює трафік на каналі з лімітом даних, поки інтерфейс увімкнений.

У центрі дозволені префікси партнера філії мають покривати все, що філія надішле. Відсутній префікс поводиться як збій маршрутизації на далекому кінці і не дає жодного попередження з жодного боку, тому його варто переглянути перед першим реальним пакетом. Порівняйте дозволені префікси центру з адресами інтерфейсів філії до першого підключення.

Перевірте зіставлення та перемикання

Переконайтеся, що рукостискання завершується, що центр перелічує поточну кінцеву точку філії і що внутрішні адреси філії доступні через тунель. Це базова лінія, і її варто зафіксувати до того, як хтось торкнеться мобільного каналу. Двох рядків виводу достатньо. Тримайте їх у заявці разом із часовою позначкою.

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

Потім перевірте збій, для якого ця схема існує. Витягніть основний WAN і переконайтеся, що основний маршрут філії до центру тепер виходить через мобільний інтерфейс. Тунель не може полагодити розірваний фізичний шлях, тому зовнішній маршрут, який досі вказує на мертве висхідне з’єднання, дає тайм-аут рукостискання, що виглядає точно як проблема центру.

Якщо зовнішній шлях явно прив’язаний або маршрутизується політикою, перемикання має включати і його. Ця прогалина між схемою, що читається правильно, і тією, що переживає збій, зазвичай і є єдиною бракуючою ланкою.

Чого ця схема не вирішує

Тут ніщо не допускає вхідного підключення до філії. Якщо щось у головному офісі має набирати мобільний майданчик, напрямок тунелю для цієї вимоги неправильний, а динамічний DNS оновлює лише ім’я. Трансляція провайдера, вхідна політика та оновлення кінцевої точки клієнтом — усе це залишається на шляху, і змінений запис не може відкрити NAT операторського рівня.

Тримайте префікс філії окремо від кожного іншого майданчика і обмежте те, що пересилатиме її шлюз. Стабільна кінцева точка центру спрощує виявлення і нічого не робить для проєктування маршрутизації, планування адрес або питання, які маршрути застосунків переживуть перемикання.

Запишіть у runbook чотири речі: хто ініціює, які префікси дозволені, скільки триває keepalive і що відбувається, коли основний канал падає. Саме ці рядки справді потрібні майбутньому оператору о третій годині ночі.

Схожі статті