ZeroTier да лакальнай сеткі: правілы маршрутызацыі UFW, а не дазвол порта

Доступ да прынтара ў офіснай лакальнай сетцы праз удзельніка ZeroTier гучыць як адно правіла, а насамрэч гэта тры рашэнні ў трох розных месцах. Overlay павінен ведаць, дзе знаходзіцца лакальная сетка, хост Linux павінен быць гатовы перасылаць пакеты, а лакальная сетка павінна ведаць, як адправіць адказ назад. Уваходнае правіла, якое адкрывае порт на шлюзе, не закранае нічога з гэтага. Гэта няправільны інструмент на правільным хосце.

Тры задачы, тры ўладальнікі

Кіраваны маршрут належыць канфігурацыі сеткі ZeroTier. Ён паведамляе ўдзельнікам, што прэфікс дасягальны праз пэўны адрас удзельніка.

Перасылка належыць ядру Linux і таму, хто валодае палітыкай яго фэйрвола. Яно вырашае, ці пакет, які прыйшоў на overlay, зноў выйдзе праз фізічны інтэрфейс. Хост, які не перасылае, моўчкі скіне пакет пасля яго прыёму. Адпраўнік бачыць тайм-аўт, і ў журнале службы нічога не з’яўляецца.

Зваротны шлях належыць лакальнай сетцы. Яе хасты і яе маршрутызатар павінны ведаць, што прэфікс overlay дасягальны праз LAN-адрас вашага шлюза, або нешта павінна трансляваць трафік, каб гэтае пытанне наогул не ўзнікала.

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

Накіруйце кіраваны маршрут на ўдзельніка

Дадайце маршрут для патрэбнага прэфікса лакальнай сеткі праз адрас overlay шлюза, а не праз яго LAN-адрас. Адрас overlay — гэта той, да якога могуць дабрацца іншыя ўдзельнікі; LAN-адрас мае сэнс толькі на дроце.

Удзельнікі павінны прымаць кіраваныя маршруты, каб схема працавала, а іх уласныя лакальныя сеткі не павінны ўжо выкарыстоўваць прэфікс, які вы абвяшчаеце. Прыдалены ноўтбук, які дома знаходзіцца ў 192.168.60.0/24, таксама не можа маршрутызаваць 192.168.60.0/24 праз overlay.

Трымайце абвешчаны прэфікс настолькі вузкім, наколькі дазваляе задача. Абвяшчэнне большага агрэгата, каб паўплываць на перавагу, можа таксама заявіць адрасную прастору, якой вы не валодаеце, і ўзніклая канфліктнасць з’явіцца на прыладах, якія падключаны да абедзвюх сетак. Гэта таксама можа прымусіць удзельніка аддаць перавагу шляху, які нікуды не вядзе. Трымайце маршрут сумленным, а рэшту няхай робіць палітыка.

Запішыце прэфікс і адрас удзельніка ў тую ж нататку, што і правілы фэйрвола, бо найчасцейшая памылка — маршрут, накіраваны на няправільнага ўдзельніка.

Уключыце транзіт у ядры

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

Калі палітыкай валодае UFW, яе правілы маршрутызацыі выражаюць перасылку для пары «крыніца, прызначэнне і інтэрфейс». Яны асобныя ад уваходных правілаў, якія адкрываюць службу на самім шлюзе:

sysctl net.ipv4.ip_forward
sudo ufw route allow in on zt3f2a1c9d out on eth0 proto tcp to 192.168.60.20 port 443
sudo ufw status verbose

Імя інтэрфейса — гэта фактычная прылада overlay на тым хосце, якую можна прачытаць з ip link; яно не з’яўляецца фіксаваным радком ва ўсіх усталёўках. Калі хост перасылае па змаўчанні, а UFW не ў шляху, правіла маршрутызацыі будзе праігнараванае, і важныя налады ядра.

Выберыце, як вяртаюцца адказы

Пры захаванні крыніцы служба лакальнай сеткі бачыць сапраўдны адрас overlay і адказвае на яго. Гэта патрабуе маршруту на хосце лакальнай сеткі або на яго маршрутызатары, які накіроўвае прэфікс overlay на ваш шлюз, а гэта змена па-за межамі Linux-скрыні.

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

Абмяжуйце пераклад крыніцай overlay і канкрэтным прызначэннем у лакальнай сетцы. Пераклад усяго, што пакідае інтэрфейс лакальнай сеткі, — гэта шырокая версія, якая потым здзіўляе кожнага, хто чытае правілы, і да таго ж хавае трафік, які павінен быў быць заблакаваны.

Ні адзін з варыянтаў не дае несанкцыянаванага доступу з лакальнай сеткі да адвольных удзельнікаў overlay. Калі гэта патрэбна, гэта асобнае правіла з уласным разглядам.

Тэстуйце з сапраўднага ўдзельніка

Падключыцеся з іншага ўдзельніка, а не са шлюза, і запытайце адну дазволеную службу. Затым паспрабуйце службу, якая павінна заставацца закрытай, і паўтарыце абодва тэсты пасля перападключэння і пасля перазагрузкі шлюза.

Удзельнік, які паведамляе пра стан ONLINE, або паспяховы пінг да адраса overlay шлюза не пацвярджае ні маршрут, ні правіла перасылкі, ні зваротны шлях:

zerotier-cli listnetworks
ip -4 route get 192.168.60.20
sudo ufw status numbered

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