Nebula-relay geconfigureerd maar ongebruikt: drie instellingen om te controleren

Je hebt een relayhost toegevoegd, het Nebula-adres ervan in een configuratie gezet, en de twee peers praten nog steeds niet met elkaar. Dat komt doordat een relaypad drie afzonderlijke uitspraken nodig heeft die met elkaar overeenkomen, en slechts één daarvan staat op de machine die je waarschijnlijk hebt bewerkt. Ik heb dit twee keer nagelopen: één keer waarbij de doorsturende host nooit de relayrol had gekregen, en één keer waarbij de instellingen aan de verkeerde kant van de verbinding stonden. De reeks hieronder controleert de rol, de aankondiging en de toestemming in die volgorde, en elke stap heeft een commando dat je vertelt of je verder moet.

Breng de drie rollen in kaart voordat je een configuratie bewerkt

Nebula geeft elke host een taak, en die taken worden niet geërfd. Een lighthouse beantwoordt vragen als waar is deze peer, zodat hosts elkaar kunnen vinden. Een relay stuurt verkeer door tussen twee peers die geen werkend direct pad hebben. Een gewone host doet geen van beide. De drie instellingen die ertoe doen, staan op drie verschillende machines, en daarom kan een clientconfiguratie die compleet lijkt beide peers laten wachten.

# 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

Eén symptoom scheidt de twee faalklassen. Als beide peers elkaar vermelden en het logboek handshakepogingen toont die nooit voltooien, werkt de ontdekking en wordt het datapad geblokkeerd door NAT of door een firewall. Als een peer het adres van de ander helemaal niet leert kennen, zit het probleem bij de lighthouse of bij de statische hostmap ervan, en relayinstellingen kunnen dat niet repareren.

Controleer welke configuratie elke host werkelijk heeft geladen voordat je iets anders aanpast. Een unit die een ander pad leest dan het bestand dat je hebt bewerkt, is een veelvoorkomende en gênante oorzaak van „de wijziging deed niets”:

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

De versieregel is van belang in een gemengde vloot. Relayafhandeling, punchgedrag en geaccepteerde configuratiesleutels zijn niet identiek over releases heen, ga er dus niet van uit dat een oudere build een sectie begrijpt waarvoor hij niet is geschreven. Zet de hosts op dezelfde minorreeks, voer daarna nebula -test -config /etc/nebula/config.yml op elke host uit en vergelijk de uitvoer voordat je een transport debugt dat de code niet implementeert.

Schakel de doorstuurrol in op de relayhost

De relayrol is één vlag op de doorsturende host, en staat los van het zijn van een lighthouse. Een host met ontdekking aan en relaydoorsturing uit blijft alleen een ontdekkingsdienst. Op de relay:

relay:
  am_relay: true

Die vlag verklaart een bedoeling; hij maakt niets bereikbaar. Een relay moet vanaf beide peers bereikbaar zijn, wat in de praktijk een openbaar adres betekent, inkomende UDP op de Nebula-poort open in de hostfirewall en in elke cloudbeveiligingsgroep, en geen dubbele NAT ervoor. Controleer de luisterende socket en kijk daarna of de pakketten van de peer aankomen:

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

Twee grenzen besparen later tijd. Een relay is niet via een andere relay bereikbaar, dus een keten van relaynamen in een configuratie vervangt geen bruikbaar pad naar de doorsturende host. En een relay stuurt pakketten door; hij verleent geen toestemming, de inkomende regels van de bestemming bepalen nog steeds of de doorgestuurde stroom is toegestaan. De rol en de eisen ervan staan in de documentatie over relayconfiguratie.

Kondig de relay aan vanaf de bestemming, niet vanaf de client

Dit is de omkering die de meeste uren kost. De relaylijst hoort bij de host die je probeert te bereiken, want hij vertelt andere peers welke relays gebruikt mogen worden om die host te bereiken. Hem op de client zetten die de verbinding start, doet niets voor de richting die de client nodig heeft:

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

Peers melden die lijst samen met hun adressen wanneer ze zich bij de lighthouse melden, dus de aankondiging verspreidt zich via de ontdekking en niet via een directe uitwisseling. Als de bestemming geen lighthouse bereikt, verspreidt haar relaylijst zich nooit en blijft een correct geconfigureerde relay werkloos. Die fout lijkt precies op een kapotte relay en is het niet.

Geef de bestemming in dezelfde ronde een bootstrap-pad. De statische hostmap koppelt een Nebula-adres aan een openbaar eindpunt zodat de eerste handshake ergens heen kan, en hij heeft een vermelding voor de relay nodig als de bestemming doorgestuurd verkeer moet accepteren van hosts die ze niet rechtstreeks bereikt:

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

Laat de verbindende peer de relay gebruiken

De initiërende kant heeft eigen toestemming nodig. relay.use_relays staat standaard aan, dus het geval dat de moeite van het zoeken waard is, is een expliciete false, vaak overgenomen uit een sjabloon dat is geschreven voordat de relayfunctie bestond of achtergelaten door een eerdere poging om directe paden af te dwingen:

relay:
  use_relays: true

Toestemming aan deze kant is niet de enige poort. De inkomende regels van de bestemming gelden nog steeds voor het doorgestuurde pakket, en de bron waarmee ze worden vergeleken is de identiteit binnen de tunnel en niet het adres van de relay zelf. Wanneer de doorgestuurde handshake voltooit en de toepassing nog steeds faalt, lees dan het logboek van de bestemming voor de bron die ze heeft vastgelegd voordat je een regel herschrijft.

NAT-traversalinstellingen werken hier allemaal mee samen. punchy.punch helpt twee peers een direct pad te openen, en als dat lukt is er geen relayverkeer te zien; dat is succes, geen ontbrekende relay. Een paar dat met tussenpozen werkt, betekent meestal dat het puncen soms lukt, test dat paar dus meerdere keren in plaats van uit één poging een conclusie te trekken.

Controleer met het paar dat faalde en herlaad daarna

Test de twee hosts die werkelijk faalden, met de toepassing die ze nodig hebben. Een geslaagde ping vanaf je werkstation naar de dienst van de relay zelf bewijst niets over doorsturing tussen twee andere peers, en het is de meest voorkomende valse positieve in deze hele procedure.

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

Herlaad in plaats van opnieuw te starten, en bevestig dat het draaiende proces het bestand heeft opgepikt dat je hebt bewerkt. Een herstart breekt elke tunnel af en maakt de volgende test moeilijker leesbaar, terwijl een SIGHUP het proces behoudt en de configuratie opnieuw laat inlezen:

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

systemctl reload werkt alleen als de lokale unit ExecReload definieert, en de unit die met het project wordt meegeleverd doet dat niet, dus systemctl kill -s HUP is de stap die op een standaardinstallatie lukt. Lees na het herladen het journaal voor het configuratiepad dat het proces heeft geopend, zodat je weet dat het nieuwe bestand is gelezen en niet het bestand waarvan je aannam dat het geladen was.

Relayinstellingen en NAT-puncen werken beide op het pad; geen van beide werkt op de identiteit. Als het paar zijn handshake nog steeds niet haalt terwijl am_relay, relays en use_relays in de draaiende configuratie zijn bevestigd, controleer dan of beide hosts certificaten tonen die zijn uitgegeven voor de namen waarmee ze zijn geconfigureerd en of de CA aan beide kanten dezelfde is. Houd de certificaat- en firewallconfiguratie vast terwijl je één transportinstelling per keer wijzigt, want een certificaatwijziging en een relaywijziging in dezelfde test vertellen je niets over welke van de twee de handshake heeft verplaatst. Een naam- of CA-verschil faalt op dezelfde plek als een relay die nooit is gevonden, en daarom hoort deze tegencontrole in dezelfde ronde.

Bevestig daarna dat elke uitspraak in het bestand staat waar hij thuishoort:

• am_relay: true op de doorsturende host, en die host vanaf beide kanten via UDP bereikbaar.
• relays: met het Nebula-adres van die host op de bestemming.
• use_relays: true op de peer die de verbinding start.
• Inkomende regels op de bestemming die de echte bron na de padwijziging nog steeds toestaan.