Два мабільныя сайты без уваходных портаў: пабудаваць хаб, які працуе

Два сайты на сотавых каналах сутыкаюцца з адной і той жа праблемай у абодвух напрамках: ні адзін не можа прыняць незапытанае 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, калі яна ёсць, і паводзіны, калі хаб недаступны. Хаб цяпер частка вашай мадэлі даступнасці, таму запішыце гэта, замест таго каб выяўляць падчас збою.