Дзве лакальныя сеткі на NetBird: які партнёр маршрутызуе і каму можна гаварыць
Падключэнне не маршрутызуе лакальную сетку. Выберыце адзін маршрутызуючы партнёр на пляцоўку, пакіньце маскараванне, абмяжуйце палітыку, затым навучыце кожны шлюз лакальнай сеткі наступнаму пераходу.
Працоўная станцыя ў заходняй лакальнай сетцы адкрывае браўзер, уводзіць адрас праграмы ва ўсходняй лакальнай сетцы і чакае, пакуль не скончыцца тайм-аўт. Кожны экран NetBird кажа, што партнёры злучаныя, і гэта праўда, але не па сутнасці: знаходжанне ў адной накладзенай сетцы не тое самае, што дзве лакальныя падсеткі ў адной сетцы. Праход ніжэй пачынаецца з гэтай працоўнай станцыі і заканчваецца запытам, ад якога праект адмаўляецца наўмысна, і на кожным кроку можна не здагадвацца, а прачытаць нешта з прылады. Чакайце, што не хапае маршруту або палітыкі, а не накладзенай сеткі.
Спачатку прачытайце збой з працоўнай станцыі
Перш чым адкрыць кансоль кіравання, вызначце, што працоўная станцыя сапраўды адпраўляе. Яе ўласная табліца маршрутызацыі вырашае, ці пойдзе пакет на шлюз пляцоўкі, на лакальны інтэрфейс або нікуды, і гэтае рашэнне бачнае без любога інструмента накладзенай сеткі. Машына без маршруту да далёкага прэфікса пацерпіць збой, як бы здарова выглядаў спіс партнёраў. Дыяпазон накладзенай сеткі і ўласны прэфікс пляцоўкі — розныя адрасныя прасторы, і падключэнне наладзіла толькі адну з іх.
Затым аддзяліце развязанне імёнаў ад дасяжнасці, бо браўзер паведамляе пра абедзве аднолькавым тайм-аўтам. Паўтарыце запыт па адрасе з машыны, дзе запушчаны кліент NetBird, а затым са звычайнай працоўнай станцыі, дзе яго няма. Калі падключаная машына дасягае поспеху, а звычайная не, разрыў у лакальнай маршрутызацыі; калі не дасягаюць абедзве, чытайце далей, перш чым змяняць маршрут.
Выберыце адзін маршрутызуючы партнёр на пляцоўку
Маршрутызуючы партнёр — гэта хост, які прадстаўляе сваю лакальную сетку ў накладзенай сетцы, таму выберыце машыну Linux са стабільнай дасяжнасцю да падсеткі, а не чыйсьці настольны камп'ютар. Падключыце яе звычайным парадкам і змясціце ў групу, названую па ролі, бо сеткавы рэсурс і палітыка будуць спасылацца на гэтую групу. Адзін прадстаўнік на пляцоўку застаецца зразумелым; натоўп добраахвотнікаў, якія аб'яўляюць той жа прэфікс, ператварае кожнае наступнае пытанне ў сеанс адладкі. Адрас партнёра ў лакальным сегменце важны не менш за яго ідэнтычнасць у накладзенай сетцы, бо гэты адрас становіцца наступным пераходам, які паведамляюць кожнай звычайнай прыладзе.
Запішыце план да дотыку да кансолі, бо імёны і прэфіксы — гэта тое, дзе такія праекты з'язджаюць: прэфікс, шлюз, адрас партнёра і група, на кожную пляцоўку. Захад — 10.52.0.0/24, яго абслугоўвае 10.52.0.5, а ўсход — 10.63.0.0/24, яго абслугоўвае 10.63.0.5; дзве групы — west-routers і east-routers, і ні адзін прэфікс не можа перакрывацца з другім, з дыяпазонам накладзенай сеткі або з іншай маршрутызаванай прызначэннем.
Стварыце рэсурс, пакіньце маскараванне ўключаным
У разгорнутай панэлі стварыце адзін сеткавы рэсурс на пляцоўку і далучыце да яго групу маршрутызуючага партнёра гэтай пляцоўкі. Рэсурс — гэта прэфікс, а група — гэта хост, які за яго адказвае, і абодва павінны існаваць, перш чым нешта аб'явяць. Пераканайцеся, што разгорнутая самастойна размешчаная версія наогул мае працоўны працэс «Сеткі», бо старэйшы інтэрфейс з падобным па назве аб'ектам маршруту — іншая функцыя.
Пакіньце маскараванне ўключаным. Кіраўніцтва NetBird па злучэнні пляцовак патрабуе яго для такой схемы, і выключэнне, каб кожны зыходны адрас заставаўся бачным, — гэта не той самы праект з адным пераходам менш; яно змяняе тое, што бачаць праверкі крыніцы і палітыкі накладзенай сеткі. Вынік варта сказаць проста: служба-атрымальнік запісвае крыніцай маршрутызуючы партнёр, а не асобную працоўную станцыю. Калі спіс дазволаў або аўдыт гэтай службы чакае адрасы працоўных станцый, то альбо змяняецца чаканне, альбо ідэнтычнасць трэба забяспечыць на мяжы пляцоўкі да пераўтварэння.
Дазваляйце ініцыятарам, а не прэфіксам
Маршрут робіць адрас дасяжным, а палітыка вырашае, каму можна ім карыстацца; гэта два асобныя аб'екты з асобнымі ўладальнікамі. Пішыце палітыку ад працоўнай нагрузкі назад: якая група ініцыюе, на які рэсурс накіраваная і якая служба TCP ёй патрэбная. Сетка, якая аб'яўляе абодва прэфіксы кожнаму падключанаму партнёру, стварыла дасяжнасць і нічога не вырашыла.
Затым прачытайце, што яшчэ ўжо дазволена, бо вузкае новае правіла не адмяняе шырокае старое, якое стаіць вышэй. Калі ўсход таксама павінен пачынаць злучэнні да захаду, запішыце гэты кірунак асобнай палітыкай; зваротны трафік для сеансу, адкрытага захадам, — іншае пытанне, чым дазвол новых сеансаў ва ўсходнім кірунку. Калі да праграмы ва ўсходзе павінны дасягаць толькі некаторыя працоўныя станцыі захаду, выберыце іх на мяжы пляцоўкі да пераўтварэння і пакіньце ўласную аўтэнтыфікацыю праграмы на месцы. Маршрутызуючы партнёр нясе трафік лакальнай сеткі як уся пляцоўка, а не як асобная ідэнтычнасць карыстальніка ў накладзенай сетцы, таму ўлік па карыстальніках павінен прыходзіць аднекуль іншага.
Навучыце кожны шлюз наступнаму пераходу, затым праверце адмову
Звычайныя прылады ніколі не бачаць накладзенай сеткі, таму іх уласны шлюз мае патрэбу ў статычным маршруце, які накіроўвае далёкі прэфікс на адрас партнёра ў лакальнай сетцы. Гэта крок, які прапускаюць, бо ўсё бачнае ўнутры NetBird ужо працуе, пакуль звычайныя працоўныя станцыі ўсё яшчэ атрымліваюць тайм-аўт. Шлюз захоўвае свой маршрут па змаўчанні як быў; гэты прэфікс — дадатак, а не замена.
Апісанні двух маршрутаў належаць канфігурацыі шлюза кожнай пляцоўкі, а не перакрыццю на хосце. Абодва — звычайныя статычныя маршруты, і ні адзін не кранае маршрут па змаўчанні:
west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5Праверце праграмай, якая сапраўды патрэбная праекту, са звычайнай працоўнай станцыі і запішыце тры рэчы: наступны пераход, выбраны на баку адпраўніка, палітыку, якая супала, і адрас крыніцы, які запісала служба. Праверце таксама адмову, бо праект, які ніколі нічога не адмаўляў, мае невядомыя краі, і толькі адмова даказвае, што працуе палітыка, а не маршрутызацыя. Калі ўсход таксама павінен ініцыяваць, пачніце новае злучэнне з таго боку, а не меркавайце, што другі кірунак пойдзе следам. Сплануйце таксама перазапуск, абнаўленне і замену маршрутызуючага партнёра, бо адзін хост стаў залежнасцю пляцоўкі.
| Test | A pass looks like | A failure points at |
|---|---|---|
| Ordinary workstation opens the east application | Next hop on west is the routing peer | Missing static route on the west gateway |
| A source outside policy is refused | No session in the service log | Policy too broad, or a route bypasses it |
| East starts a connection, if required | A fresh reverse session succeeds | No policy for the reverse direction |
Прыватныя імёны патрабуюць уласнага праекта развязальніка, бо дасяжнасць не стварае запісы DNS, а працоўны шлях IP са зламаным імем чытаецца як зламаны шлях. Калі маршрутызуючы партнёр працуе ўнутры хмарнай сеткі, перагледзьце таксама правілы перасылкі і міжсеткавага экрана правайдэра, бо падключэнне іх не адмяняе. Трымайце назіранні з тэсту побач з планам, бо наступнаму чалавеку, які будзе гэта адладжваць, спатрэбяцца супалая палітыка і запісаны адрас крыніцы, а не апісанне тапалогіі.