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 на партнерот што ја започнува врската.
  • Влезните правила на дестинацијата сѐ уште го дозволуваат вистинскиот извор откако патеката ќе се смени.

Поврзани статии