Nebula static_host_map: адрас, які маяк не можа даць
Карта спалучае оверлейны адрас з канчатковымі пунктамі, даступнымі ў рэальнай сетцы. Менавіта гэтае спалучэнне робіць магчымым першае рукапацісканне.
Кожны маяк можа расказаць хосту пра кожнага іншага партнёра, акрамя таго месца, дзе жыве сам маяк. Нешта павінна быць вядома да таго, як існуе оверлей, і Nebula змяшчае гэтае нешта ў адну невялікую карту. Карта спалучае оверлейную ідэнтычнасць з адрасам, які працуе ў звычайнай сетцы. Усё, што вывучаецца пазней, залежыць ад правільнасці гэтага спалучэння.
Два адрасы з дзвюма задачамі
Кожны хост Nebula валодае оверлейным адрасам, які застаецца нерухомым, пакуль прылада перамяшчаецца паміж сеткамі. Гэты адрас — ідэнтычнасць, якую выкарыстоўваюць сертыфікаты, правілы файрвола і сувязі з партнёрамі, і сам па сабе ён нікуды не маршрутызуе. Дасяжны канчатковы пункт — іншае: імя хоста або адрас у базавай сетцы плюс UDP-порт, і ён змяняецца кожны раз, калі машына мяняе месца. Статычная карта — гэта злучэнне паміж імі.
У карту ўваходзяць толькі хасты, якія трэба набіраць халоднымі, што звычайна азначае маякі і, магчыма, рэлей. Трымаць гэты спіс кароткім — мэта дызайну, бо кожны ручны запіс становіцца фактам, які нехта павінен падтрымліваць. Блытаніна двух тыпаў адрасоў — звычайная памылка канфігурацыі: публічны адрас, змешчаны ў спіс маякоў, не запускае выяўленне.
Ідэнтычнасць ідзе туды, дзе яе чакаюць. Дасяжнасць ідзе ў карту.
static_host_map:
"10.42.0.1": ["lighthouse-01.example.net:4242"]
lighthouse:
am_lighthouse: false
hosts:
- "10.42.0.1"
Анатомія запісу ў карце
Ключ — гэта оверлейны адрас, запісаны як радок у двукоссі, а значэнне — спіс канчатковых пунктаў, таму адна ідэнтычнасць можа мець некалькі пунктаў уваходу. Кожны канчатковы пункт мае хост і порт, і порт павінен адпавядаць таму, што іншы бок фактычна слухае. Тыповае значэнне Nebula — UDP 4242, і гэта адпраўная кропка, а не абяцанне пра ваша разгортванне.
Некалькі канчатковых пунктаў карысныя, калі маяк мае больш за адзін шлях унутр, напрыклад публічны адрас і прыватны адрас для хастаў у тым жа сегменце. Кліент спрабуе іх па парадку, таму стаўце самым надзейным першым. Для IPv6 бярыце адрас у дужкі перад даданнем порта; памылка тут дае памылку разбору, якая паказвае на няправільны радок.
Няправільны порт дае цішыню замест памылкі, бо UDP не мае рукапаціскання, каб адмовіць. Таму фармат запісу варта правяраць па даведцы Nebula па static_host_map а не па памяці. Даведка таксама апісвае спісы канчатковых пунктаў і паводзіны абнаўлення DNS.
Загрузка павінна працаваць да оверлея
DNS-імя ў карце павінна развязацца праз рэзалвер, які хост мае да з’яўлення любога тунэля, гэта значыць звычайны сістэмны рэзалвер. Праверце гэта з той жа машыны, пры загрузцы, са спыненым оверлеем. Імя, якое развязваецца толькі праз уласны DNS оверлея, не можа загрузіць оверлей. Тое ж выпрабаванне датычыцца маршруту: правіла файрвола, якое дазваляе оверлей, але не першы абмен UDP, блакуе пачатковы пакет.
Праверце порт інструментам UDP, а не здагадвайцеся, што ён адкрыты. Пераканайцеся, што любое перанакіраванне порта на шляху накіравана на правільны ўнутраны хост і што зваротны шлях існуе. Калі імя хоста развязваецца ў некалькі адрасоў, праверце кожны, бо кліент можа выбраць адрас, які вы ніколі не правяралі.
Статычныя запісы набіраюцца напрамую і ніколі не звяртаюцца да маяка. Таму збой тут выглядае як звычайны тайм-аўт без удзелу партнёра.
Што адбываецца пасля першага рукапаціскання
Як толькі хост дасягае маяка, ён даведваецца пра партнёраў і іх дасяжныя адрасы без дадатковых ручных запісаў. Хасты, якія перамясціліся з часу апошняга злучэння, становяцца выяўнымі праз гэты канал. Гэта ўзнагарода за тое, што ручная карта застаецца невялікай.
Хасты таксама могуць аб’яўляць уласныя дадатковыя дасяжныя адрасы, і менавіта так партнёр за вядомым публічным адрасам дапамагае іншым знайсці яго. Гэтыя аб’явы вывучаюцца, а не ўпісваюцца ў статычную карту.
Паводзіны абнаўлення важныя для канчатковых пунктаў, запісаных як DNS-імі, бо развязаны адрас можа змяніцца, пакуль працэс працягвае працаваць. Налады Nebula кіруюць тым, як адбываюцца гэтыя запыты, уключаючы тое, які рэзалвер выкарыстоўваецца, таму чытайце іх, а не здагадвайце сістэмнае значэнне. На хосце, чый рэзалвер змяняецца, калі ўзнікае тунэль, няправільная налада можа ператварыць працуючую загрузку ў імя, якое перастае развязвацца пасярод сесіі. Прымацаванне запыту да стабільнага рэзалвера часта і ёсць розніца паміж надзейным оверлеем і перарывістым.
Калі выяўленне працуе, а адзін партнёр — не
Калі маякі дасяжныя і большасць партнёраў злучаецца, загрузка не з’яўляецца праблемай. Астатняя пара альбо не можа знайсці карысны шлях адно да аднаго, альбо збіваецца вышэй за дасяжнасць. Даданне яшчэ аднага напісання адраса маяка не выправіць ні адзін з гэтых выпадкаў.
Праверце пару перад рэдагаваннем карты, на якую ўжо абапіраецца ўсё астатняе. Змена карты турбуе кожны хост, таму гэта апошняе, чаго варта кранаць, а не першае.
Пачніце з сертыфікатаў ад таго ж цэнтра, бо адхіленае рукапацісканне здалёк можа выглядаць як недасяжны партнёр. Затым праверце, ці можа пара ўсталяваць прамы шлях і ці наладжаны рэлей для сетак, якія адмаўляюць прамы трафік. Рэлей дадае хоп і залежнасць, але гэта падтрымліваецца, і выпраўленне шляху пары — іншая задача, чым выпраўленне выяўлення.