Nebula errelea konfiguratuta baina erabili gabe: hiru ezarpen egiaztatzeko

Errele-ostalari bat gehitu zenuen, haren Nebula helbidea konfigurazio batean sartu, eta bi pareek ez dute elkarrekin hitz egiten oraindik. Hori gertatzen da errele-bide batek bat etorri behar duten hiru adierazpen bereizi behar dituelako, eta horietako bakarra dago ziurrenik editatu zenuen makinan. Nik bi aldiz jarraitu dut hau: behin aurreratze-ostalariak inoiz errele-rola jaso ez zuenean, eta behin ezarpenak konexioaren alde okerrean idatzita zeudenean. Beheko sekuentziak rola, iragarpena eta baimena ordena horretan egiaztatzen ditu, eta urrats bakoitzak jarraitu behar duzun ala ez esaten dizun komando bat du.

Kartografiatu hiru rolak konfigurazio bat editatu aurretik

Nebulak ostalari bakoitzari lan bat ematen dio, eta lanak ez dira oinordetzen. Lighthouse batek non dago pare hau bezalako galderei erantzuten die, ostalariek elkar aurkitu ahal izan dezaten. Errele batek bi pareen arteko trafikoa aurreratzen du, zuzeneko bide erabilgarririk ez dutenean. Ostalari arrunt batek ez du bat ere egiten. Garrantzitsuak diren hiru ezarpenak hiru makina ezberdinetan daude, eta horregatik itxura osoa duen bezero-konfigurazio batek bi pareak itxaroten utz ditzake.

# 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

Sintoma bakar batek bereizten ditu bi hutsegite-motak. Bi pareek elkar zerrendatzen badute eta erregistroak inoiz amaitzen ez diren handshake saiakerak erakusten baditu, aurkikuntza funtzionatzen ari da eta datu-bidea NAT edo suebaki batek blokeatzen du. Pare batek bestearen helbidea inoiz ez badaki, arazoa lighthousean edo haren ostalari-mapa estatikoan dago, eta errele-ezarpenek ezin dute hori konpondu.

Egiaztatu zein konfigurazio kargatu duen benetan ostalari bakoitzak beste ezer aldatu aurretik. Editatu duzun fitxategia ez den beste bide bat irakurtzen duen unit bat arrazoi ohikoa eta lotsagarria da «aldaketak ezer egin ez zuela» gertatzeko:

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

Bertsio-lerroak garrantzia du flota misto batean. Erreleen tratamendua, punch-portaera eta onartutako konfigurazio-gakoak ez dira berdinak bertsioen artean, beraz ez ezazu pentsa eraikuntza zahar batek ulertzen duenik horretarako idatzi ez zen atal bat. Jarri ostalariak minor-serie berean, exekutatu gero nebula -test -config /etc/nebula/config.yml ostalari bakoitzean eta alderatu irteera kodea inplementatzen ez duen garraio bat araztu aurretik.

Gaitu aurreratze-rola errele-ostalarian

Errele-rola bandera bakarra da aurreratze-ostalarian, eta lighthouse izatearen independentea da. Aurkikuntza gaituta eta errele-aurreratzea desgaituta dituen ostalari bat aurkikuntza-zerbitzu hutsa da oraindik. Errelean:

relay:
  am_relay: true

Bandera horrek asmo bat adierazten du; ez du iristekotasunik sortzen. Errele bat bi pareetatik irisgarria izan behar da, eta horrek praktikan helbide publiko bat esan nahi du, Nebula atakaren UDP sarrera ostalariaren suebakian eta hodeiko edozein segurtasun-taldetan irekita, eta ez NAT bikoitzik aurretik. Egiaztatu entzuten ari den socket-a eta gero begiratu parearen paketeak iristen diren:

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

Bi mugek denbora aurrezten dute geroago. Errele bat ezin da beste errele baten bidez iritsi, beraz konfigurazio bateko errele-izenen kate batek ez du ordezkatzen aurreratze-ostalariari bide erabilgarri bat ematea. Eta errele batek paketeak aurreratzen ditu; ez du baimenik ematen, helmugaren sarrera-arauak dira oraindik aurreratutako fluxua onartzen den erabakitzen dutenak. Rola eta haren baldintzak errele-konfigurazioari buruzko dokumentazioan daude.

Iragarri errelea helmugatik, ez bezerotik

Hau da ordu gehien jaten dituen inbertsioa. Errele-zerrenda iritsi nahi duzun ostalariari dagokio, besteei esaten dielako zein errele erabil daitezkeen ostalari horretara iristeko. Konexioa hasten duen bezeroan jartzeak ez du ezer egiten bezeroak behar duen norabiderako:

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

Pareek zerrenda hori beren helbideekin batera bidaltzen dute lighthousean izena ematen dutenean, beraz iragarpena aurkikuntzaren bidez hedatzen da eta ez truke zuzen baten bidez. Helmugak lighthouse bat lortzen ez badu, haren errele-zerrenda ez da inoiz zabaltzen eta ondo konfiguratutako errele bat alferrik geratzen da. Hutsegite horrek errele hautsia bezalako itxura du eta ez da hori.

Eman helmugari abio-bide bat pauso berean. Ostalari-mapa estatikoak Nebula helbide bat mutur publiko batekin lotzen du, lehen handshakeak nora joan izan dezan, eta errelerako sarrera bat behar du helmugak zuzenean iristen ez dituen ostalarietatik aurreratutako trafikoa onartu behar badu:

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

Utzi konektatzen den pareari errelea erabiltzen

Hasierako aldeak bere baimena behar du. relay.use_relays aktibatuta dago lehenespenez, beraz bilatzea merezi duen kasua false esplizitu bat da, askotan errele-funtzioa existitu aurretik idatzitako txantiloi batetik kopiatua edo zuzeneko bideak behartzeko aurreko saiakera batek utzia:

relay:
  use_relays: true

Alde honetako baimena ez da ate bakarra. Helmugaren sarrera-arauak aurreratutako paketeari aplikatzen zaizkio oraindik, eta alderatzen diren iturria tunelaren barneko identitatea da, ez errelearen beraren helbidea. Aurreratutako handshakea amaitzen denean eta aplikazioak huts egiten jarraitzen badu, irakurri helmugaren erregistroa erregistratu zuen iturria ikusteko, arau bat berridatzi aurretik.

NAT zeharkatzeko ezarpenek guzti honekin elkarreragiten dute. punchy.punch tresnak bi pareari zuzeneko bide bat irekitzen laguntzen die, eta lortzen denean ez dago errele-trafikorik ikusteko; arrakasta da hori, ez falta den errele bat. Tarteka funtzionatzen duen pare batek punchak batzuetan asmatzen duela esan ohi du, beraz probatu pare hori hainbat aldiz saiakera batetik ondorio bat atera beharrean.

Egiaztatu huts egin zuen parearekin eta gero berrikargatu

Probatu benetan huts egin zuten bi ostalariak, behar duten aplikazioarekin. Zure lanpostuko ping arrakastatsu batek errelearen zerbitzuraino ez du ezer frogatzen beste bi pareen arteko aurreratzeari buruz, eta prozedura oso honetako faltsu positibo ohikoena da.

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

Berrikargatu berrabiarazi beharrean, eta egiaztatu exekuzioan dagoen prozesuak editatu zenuen fitxategia hartu duela. Berrabiarazte batek tunel guztiak botatzen ditu eta hurrengo proba irakurtzen zailagoa egiten du, SIGHUP batek prozesua mantendu eta konfigurazioa berriro irakurtzen duen bitartean:

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

systemctl reload bakarrik funtzionatzen du unit lokalak ExecReload definitzen duenean, eta proiektuak dakarren unitak ez du hori egiten, beraz systemctl kill -s HUP da instalazio estandar batean lortzen den urratsa. Berrikargatu ondoren, irakurri journala prozesuak ireki zuen konfigurazio-biderako, badakizulako fitxategi berria irakurri zela eta ez zenuen uste kargatuta zegoen hura.

Errele-ezarpenek eta NAT punchak biek bideari eragiten diote; batek ere ez identitateari. Pareak oraindik handshakeak huts egiten badu am_relay, relays eta use_relays exekuzioan dagoen konfigurazioan egiaztatuta daudenean, egiaztatu bi ostalariek konfiguratuta dauden izenetarako igorritako ziurtagiriak aurkezten dituztela eta CA bera dela bi aldeetan. Eutsi ziurtagiri- eta suebaki-konfigurazioari aldatu gabe, garraio-ezarpen bat aldiz aldatzen duzun bitartean, ziurtagiri-aldaketa batek eta errele-aldaketa batek proba berean ez dizutelako ezer esaten bi horietako zeinek mugitu zuen handshakea. Izen- edo CA-desadostasun batek inoiz aurkitu ez zen errele batek bezala huts egiten du, eta horregatik dagokio kontrako egiaztapen hori pauso berari.

Gero egiaztatu adierazpen bakoitza dagokion fitxategian dagoela:

• am_relay: true aurreratze-ostalarian, eta ostalari hori bi aldeetatik UDP bidez irisgarria.
• relays: ostalari horren Nebula helbidearekin helmugan.
• use_relays: true konexioa hasten duen parean.
• Helmugako sarrera-arauak, bide-aldaketaren ondoren benetako iturria onartzen jarraitzen dutenak.