Nebula: рэлей наладжаны, але не выкарыстоўваецца — тры параметры, якія варта праверыць

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

Складзіце карту трох роляў, перш чым рэдагаваць канфігурацыю

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

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

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

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

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

Радок версіі мае значэнне ў змяшаным парку. Апрацоўка рэлея, паводзіны прабівання і прымальныя ключы канфігурацыі не аднолькавыя паміж выпускамі, таму не мяркуйце, што старэйшая зборка разумее раздзел, для якога яна не пісалася. Выраўнавайце хасты на адной малодшай серыі, затым запусціце nebula -test -config /etc/nebula/config.yml на кожным хосце і параўнайце вывад, перш чым адладжваць транспарт, якога код не рэалізуе.

Уключыце ролю перасылкі на хосце-рэлеі

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

relay:
  am_relay: true

Гэты сцяг абвяшчае намер; ён не стварае дасяжнасць. Рэлей павінен быць дасяжным з абодвух бакоў, што на практыцы азначае публічны адрас, уваходны UDP на порце Nebula, адкрыты ў фаерволе хоста і ў любой хмарнай групе бяспекі, і адсутнасць падвойнага NAT перад ім. Праверце слухаючы сокет, затым назірайце за прыходам пакетаў партнёра:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

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

Абвяшчайце рэлей з боку прызначэння, а не кліента

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

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

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

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

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Дазвольце партнёру, які падключаецца, выкарыстоўваць рэлей

Ініцыятыўнаму боку патрэбны ўласны дазвол. relay.use_relays уключаны па змаўчанні, таму выпадак, які варта шукаць, — гэта яўнае false, часта скапіяванае з шаблона, напісанага да з’яўлення функцыі рэлея, або пакінутае ад ранейшай спробы сілай прымусіць прамыя шляхі:

relay:
  use_relays: true

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

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

Праверце на пары, якая падала, затым перазагрузіце

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

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

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

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload працуе, толькі калі лакальны юніт вызначае ExecReload, а юніт, які пастаўляецца з праектам, гэтага не робіць, таму systemctl kill -s HUP — гэта крок, які ўдаецца на стандартнай устаноўцы. Пасля перазагрузкі прачытайце журнал для шляху канфігурацыі, які адкрыў працэс, каб ведаць, што прачытаны новы файл, а не той, які вы меркавалі.

Налады рэлея і прабіванне NAT дзейнічаюць на шлях; ні адно з іх не дзейнічае на ідэнтычнасць. Калі пара ўсё яшчэ падае на рукапоціску пасля таго, як am_relay, relays і use_relays пацверджаны ў працоўнай канфігурацыі, праверце, што абодва хасты прад’яўляюць сертыфікаты, выдадзеныя для імёнаў, з якімі яны наладжаны, і што CA аднолькавы з абодвух бакоў. Трымайце сертыфікат і канфігурацыю фаервола нязменнымі, змяняючы па адным параметры транспарту, бо правака сертыфіката і правака рэлея, якія трапілі ў адзін тэст, не кажуць, што менавіта зрушыла рукапоціск. Няадпаведнасць імя або CA падае ў тым жа месцы, што і рэлей, які ніколі не быў знойдзены, таму гэтая сустрэчная праверка належыць таму ж праходу.

Затым пераканайцеся, што кожнае сцверджанне знаходзіцца ў файле, да якога яно належыць:

• am_relay: true на хосце перасылкі, і гэты хост дасяжны па UDP з абодвух бакоў.
• relays: з указаннем адрасу Nebula гэтага хоста на прызначэнні.
• use_relays: true на партнёры, які пачынае злучэнне.
• Правілы ўваходу на прызначэнні ўсё яшчэ дазваляюць сапраўдную крыніцу пасля змены шляху.