Два стільникові майданчики без вхідних портів: збудуйте робочий концентратор

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

Два майданчики на стільникових каналах стикаються з тією самою проблемою в обидва боки: жоден не може прийняти незапитане з'єднання 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, коли вона є, і поведінку, коли концентратор недоступний. Концентратор тепер частина вашої моделі доступності, тож запишіть це, а не виявляйте під час збою.

Схожі статті