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 на партньора, който започва връзката.
• Входящите правила на дестинацията все още позволяват истинския източник след промяната на пътя.