Nebula static_host_map: het adres dat een vuurtoren niet kan geven

Elke vuurtoren kan een host over elke andere peer vertellen, behalve waar de vuurtoren zelf staat. Iets moet bekend zijn voordat de overlay bestaat, en Nebula stopt dat iets in één kleine kaart. De kaart koppelt een overlay-identiteit aan een adres dat op het gewone netwerk werkt. Alles wat later wordt geleerd, hangt af van die koppeling die klopt.

Twee adressen met twee taken

Elke Nebula-host heeft een overlay-adres dat vast blijft terwijl het apparaat tussen netwerken beweegt. Dat adres is de identiteit die certificaten, firewallregels en peer-relaties gebruiken, en op zichzelf routeert het nergens heen. Het bereikbare eindpunt is iets anders: een hostnaam of adres op het onderliggende netwerk plus een UDP-poort, en het verandert wanneer de machine van locatie verandert. De statische kaart is de verbinding tussen beide.

Alleen hosts die koud moeten worden gebeld horen in de kaart, wat meestal de vuurtorens en misschien één relay betekent. Die lijst kort houden is een ontwerpdoel, want elke handmatige vermelding wordt een feit dat iemand moet onderhouden. De twee adresstypen verwarren is de gebruikelijke configuratiefout: een openbaar adres in de vuurtorenlijst laat de ontdekking niet beginnen.

Identiteit gaat waar identiteit wordt verwacht. Bereikbaarheid gaat in de kaart.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomie van een kaartvermelding

De sleutel is het overlay-adres als tekenreeks tussen aanhalingstekens, en de waarde is een lijst eindpunten, zodat één identiteit meerdere ingangen kan hebben. Elk eindpunt draagt een host en een poort, en de poort moet overeenkomen met waar de andere kant echt naar luistert. Nebula's standaard is UDP 4242, wat een startpunt is en geen belofte over je uitrol.

Meerdere eindpunten zijn nuttig wanneer een vuurtoren meer dan één weg naar binnen heeft, zoals een openbaar adres en een privéadres voor hosts in hetzelfde segment. De client probeert ze op volgorde, dus zet de betrouwbaarste vooraan. Voor IPv6 zet je het adres tussen vierkante haken voordat de poort wordt toegevoegd; dat fout doen geeft een parserfout die naar de verkeerde regel wijst.

Een verkeerde poort geeft stilte in plaats van een fout, omdat UDP geen handshake heeft om te weigeren. Daarom loont het het formaat van de vermelding te controleren tegen de Nebula-referentie voor static_host_map en niet tegen het geheugen. De referentie behandelt ook eindpuntenlijsten en het gedrag van DNS-verversing.

Bootstrap moet werken vóór de overlay

Een DNS-naam in de kaart moet worden opgelost via de resolver die de host heeft voordat er een tunnel bestaat, dat wil zeggen de gewone systeemresolver. Test dat vanaf dezelfde machine, bij het opstarten, met de overlay gestopt. Een naam die alleen via de eigen DNS van de overlay wordt opgelost, kan de overlay niet bootstrappen. Dezelfde test geldt voor de route: een firewallregel die de overlay toestaat maar niet de eerste UDP-uitwisseling, blokkeert het eerste pakket.

Controleer de poort met een UDP-hulpprogramma in plaats van aan te nemen dat die open is. Bevestig dat elke poortdoorschakeling op de route naar de juiste interne host wijst en dat er een terugweg is. Als de hostnaam naar meerdere adressen oplost, test ze allemaal, want een client kan een adres kiezen dat je nooit hebt gecontroleerd.

Statische vermeldingen worden direct gebeld en vragen nooit een vuurtoren. Daarom lijkt een storing hier op een gewone time-out zonder betrokken peer.

Wat er gebeurt na de eerste handshake

Zodra een host een vuurtoren bereikt, leert hij over peers en hun bereikbare adressen zonder meer handmatige vermeldingen. Hosts die sinds de laatste verbinding zijn verplaatst, worden via dat kanaal ontdekbaar. Dat is de winst van het klein houden van de handmatige kaart.

Hosts kunnen ook hun eigen extra bereikbare adressen aankondigen, en zo helpt een peer achter een bekend openbaar adres anderen hem te vinden. Die aankondigingen worden geleerd, niet in de statische kaart getypt.

Verversingsgedrag is belangrijk voor eindpunten die als DNS-naam zijn geschreven, omdat een opgelost adres kan veranderen terwijl het proces blijft draaien. De instellingen van Nebula bepalen hoe die opzoekingen gebeuren, inclusief welke resolver wordt gebruikt, dus lees ze in plaats van de systeemstandaard aan te nemen. Op een host waarvan de resolver verandert wanneer een tunnel opkomt, kan de verkeerde instelling een werkende bootstrap veranderen in een naam die midden in de sessie stopt met oplossen. Het opzoeken vastzetten op een stabiele resolver is vaak het verschil tussen een betrouwbare overlay en een die hapert.

Wanneer ontdekking werkt en één peer niet

Als de vuurtorens bereikbaar zijn en de meeste peers verbinden, is de bootstrap niet het probleem. Het resterende paar vindt ofwel geen bruikbare weg naar elkaar of faalt boven de bereikbaarheid. Een andere spelling van het vuurtorenadres toevoegen kan geen van beide gevallen repareren.

Controleer het paar voordat je de kaart bewerkt waarop al het andere al steunt. Een kaartwijziging verstoort elke host, dus het is het laatste dat je aanraakt, niet het eerste.

Begin met certificaten van dezelfde autoriteit, want een geweigerde handshake kan van een afstand op een onbereikbare peer lijken. Controleer daarna of het paar een directe weg kan opzetten en of er een relay is geconfigureerd voor netwerken die direct verkeer weigeren. Een relay voegt een hop en een afhankelijkheid toe, maar het is een ondersteund antwoord, en de weg van het paar repareren is een andere taak dan de ontdekking repareren.