Jūs pievienojāt starpniekservera resursdatoru, ievadījāt tā Nebula adresi konfigurācijā, un abi partneri joprojām nesazinās. Tas notiek tāpēc, ka maršrutam caur starpniekserveri vajadzīgi trīs atsevišķi paziņojumi, kuriem jāsaskan, un tikai viens no tiem atrodas mašīnā, kuru jūs, iespējams, rediģējāt. Esmu to izsekojis divreiz: vienreiz pārsūtīšanas resursdatoram nekad netika piešķirta starpniekservera loma, un vienreiz iestatījumi bija ierakstīti nepareizajā savienojuma pusē. Tālākā secība pārbauda lomu, paziņojumu un atļauju tieši šādā kārtībā, un katram solim ir komanda, kas pasaka, vai turpināt.

Pirms konfigurācijas rediģēšanas kartējiet trīs lomas

Nebula katram resursdatoram piešķir uzdevumu, un uzdevumi netiek mantoti. Lighthouse atbild uz jautājumiem, piemēram, kur atrodas šis partneris, lai resursdatori varētu atrast viens otru. Starpniekserveris pārsūta datplūsmu starp diviem partneriem, kuriem nav strādājoša tieša maršruta. Parasts resursdators nedara ne vienu, ne otru. Trīs svarīgie iestatījumi atrodas trīs dažādās mašīnās, un tāpēc klienta konfigurācija, kas izskatās pilnīga, var likt abiem partneriem gaidīt.

# 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

Viens simptoms atdala abas kļūdu klases. Ja abi partneri uzskaita viens otru un žurnālā redzami rokasspiediena mēģinājumi, kas nekad nebeidzas, atklāšana darbojas, un datu ceļu bloķē NAT vai ugunsmūris. Ja partneris vispār neuzzina otra adresi, problēma ir lighthouse vai tā statiskajā resursdatoru kartē, un starpniekservera iestatījumi to nevar salabot.

Pirms kaut kā cita maiņas pārliecinieties, kādu konfigurāciju katrs resursdators faktiski ielādēja. Unit, kas lasa citu ceļu nekā jūsu rediģētais fails, ir biežs un neērts iemesls tam, ka „izmaiņa neko nedarīja”:

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

Versijas rindai ir nozīme jauktā parkā. Starpniekserveru apstrāde, punch uzvedība un pieņemtās konfigurācijas atslēgas nav identiskas starp laidieniem, tāpēc nepieņemiet, ka vecāka būvējums saprot sadaļu, kurai tas nav rakstīts. Saskaņojiet resursdatorus uz to pašu minor sēriju, pēc tam palaidiet nebula -test -config /etc/nebula/config.yml katrā resursdatorā un salīdziniet izvadi, pirms sākat atkļūdot transportu, kuru kods neievieš.

Ieslēdziet pārsūtīšanas lomu starpniekservera resursdatorā

Starpniekservera loma ir viena karodziņa pārsūtīšanas resursdatorā, un tā ir atsevišķa no tā, ka resursdators ir lighthouse. Resursdators ar ieslēgtu atklāšanu un izslēgtu pārsūtīšanu caur starpniekserveri joprojām ir tikai atklāšanas pakalpojums. Starpniekserverī:

relay:
  am_relay: true

Šis karodziņš deklarē nodomu; tas nerada sasniedzamību. Starpniekserverim jābūt sasniedzamam no abiem partneriem, kas praksē nozīmē publisku adresi, ienākošu UDP uz Nebula portu, atvērtu resursdatora ugunsmūrī un jebkurā mākoņa drošības grupā, un bez dubultā NAT priekšā. Pārbaudiet klausošo ligzdu un pēc tam vērojiet, vai ierodas partnera paketes:

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

Divi ierobežojumi vēlāk ietaupa laiku. Starpniekserverim nevar piekļūt caur citu starpniekserveri, tāpēc starpniekserveru nosaukumu ķēde konfigurācijā neaizstāj lietojamu ceļu uz pārsūtīšanas resursdatoru. Un starpniekserveris pārsūta paketes; tas nepiešķir atļauju, par to, vai pārsūtītā plūsma ir atļauta, joprojām lemj galamērķa paša ienākošās kārtulas. Loma un tās prasības ir aprakstītas starpniekservera konfigurācijas dokumentācijā.

Paziņojiet starpniekserveri no galamērķa, nevis no klienta

Tā ir inversija, kas aprij visvairāk stundu. Starpniekserveru saraksts pieder resursdatoram, kuru mēģināt sasniegt, jo tas citiem partneriem pasaka, kurus starpniekserverus drīkst izmantot šī resursdatora sasniegšanai. Tā ievietošana klientā, kas sāk savienojumu, neko nedod virzienam, kas klientam vajadzīgs:

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

Partneri šo sarakstu paziņo kopā ar savām adresēm, kad piesakās lighthouse, tāpēc paziņojums izplatās ar atklāšanu, nevis ar tiešu apmaiņu. Ja galamērķis nesasniedz nevienu lighthouse, tā starpniekserveru saraksts nekad neizplatās, un pareizi konfigurēts starpniekserveris paliek dīkā. Šī kļūme izskatās tieši kā salūzis starpniekserveris un tāda nav.

Dodiet galamērķim sāknēšanas ceļu tajā pašā piegājienā. Statiskā resursdatoru karte saista Nebula adresi ar publisku galapunktu, lai pirmajam rokasspiedienam būtu kur iet, un tai vajadzīgs ieraksts starpniekserverim, ja galamērķim jāpieņem pārsūtītā datplūsma no resursdatoriem, kurus tas nesasniedz tieši:

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

Ļaujiet pievienojošajam partnerim izmantot starpniekserveri

Iniciējošajai pusei vajadzīga sava atļauja. relay.use_relays pēc noklusējuma ir ieslēgts, tāpēc gadījums, ko ir vērts meklēt, ir skaidri norādīts false, bieži kopēts no veidnes, kas rakstīta pirms starpniekservera funkcijas pastāvēšanas, vai atstāts no agrāka mēģinājuma uzspiest tiešus ceļus:

relay:
  use_relays: true

Atļauja šajā pusē nav vienīgie vārti. Galamērķa ienākošās kārtulas joprojām attiecas uz pārsūtīto paketi, un avots, ar ko tās salīdzina, ir identitāte tuneļa iekšienē, nevis paša starpniekservera adrese. Kad pārsūtītais rokasspiediens beidzas un lietojumprogramma joprojām neizdodas, izlasiet galamērķa žurnālā, kāds avots tika fiksēts, pirms pārrakstāt kārtulu.

NAT šķērsošanas iestatījumi darbojas kopā ar visu šo. punchy.punch palīdz diviem partneriem atvērt tiešu ceļu, un, kad tas izdodas, nav pārsūtītās datplūsmas, ko novērot; tas ir panākums, nevis trūkstošs starpniekserveris. Pāris, kas darbojas ar pārtraukumiem, parasti nozīmē, ka punch izdodas tikai dažreiz, tāpēc testējiet šo pāri vairākas reizes, nevis izdariet secinājumu no viena mēģinājuma.

Pārbaudiet ar pāri, kas neizdevās, un pēc tam ielādējiet no jauna

Testējiet tos divus resursdatorus, kas patiešām neizdevās, ar lietojumprogrammu, kas tiem vajadzīga. Veiksmīgs ping no jūsu darbstacijas uz paša starpniekservera pakalpojumu neko nepierāda par pārsūtīšanu starp diviem citiem partneriem, un tas ir visbiežāk sastopamais viltus pozitīvais visā šajā procedūrā.

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

Ielādējiet no jauna, nevis restartējiet, un apstipriniet, ka darbojošais process pārņēma jūsu rediģēto failu. Restartēšana norauj katru tuneli un padara nākamo testu grūtāk lasāmu, savukārt SIGHUP saglabā procesu un liek tam nolasīt konfigurāciju no jauna:

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

systemctl reload darbojas tikai tad, ja vietējais unit definē ExecReload, un ar projektu piegādātais unit to nedara, tāpēc systemctl kill -s HUP ir solis, kas izdodas standarta instalācijā. Pēc atkārtotas ielādes izlasiet žurnālā konfigurācijas ceļu, ko process atvēra, lai zinātu, ka tika nolasīts jaunais fails, nevis tas, ko uzskatījāt par ielādētu.

Starpniekservera iestatījumi un NAT punch abi iedarbojas uz ceļu; neviens neiedarbojas uz identitāti. Ja pāris joprojām neizdodas rokasspiedienā, kad am_relay, relays un use_relays ir apstiprināti darbojošajā konfigurācijā, pārbaudiet, vai abi resursdatori uzrāda sertifikātus, kas izsniegti uz vārdiem, ar kuriem tie konfigurēti, un vai CA ir tā pati abās pusēs. Turiet sertifikātu un ugunsmūra konfigurāciju nemainīgu, kamēr maināt vienu transporta iestatījumu vienlaikus, jo sertifikāta maiņa un starpniekservera maiņa vienā testā nepasaka neko par to, kura no tām pārvietoja rokasspiedienu. Vārda vai CA neatbilstība neizdodas tajā pašā vietā kā starpniekserveris, kas nekad netika atrasts, un tāpēc šī pretpārbaude pieder pie tā paša piegājiena.

Pēc tam apstipriniet, ka katrs paziņojums ir failā, kuram tas pieder:

  • am_relay: true pārsūtīšanas resursdatorā, un šis resursdators sasniedzams ar UDP no abām pusēm.
  • relays: ar šī resursdatora Nebula adresi galamērķī.
  • use_relays: true partnerī, kas sāk savienojumu.
  • Ienākošās kārtulas galamērķī, kas arī pēc ceļa maiņas atļauj īsto avotu.

Saistītie raksti