Nebula static_host_map: die adres wat ’n vuurtoring nie kan gee nie

Elke vuurtoring kan vir ’n gasheer van elke ander eweknie vertel, behalwe waar die vuurtoring self woon. Iets moet bekend wees voordat die overlay bestaan, en Nebula plaas daardie iets in een klein kaart. Die kaart pas ’n overlay-identiteit by ’n adres wat op die gewone netwerk werk. Alles wat later geleer word, hang daarvan af dat daardie paring reg is.

Twee adresse met twee take

Elke Nebula-gasheer besit ’n overlay-adres wat vas bly terwyl die toestel tussen netwerke beweeg. Daardie adres is die identiteit wat deur sertifikate, firewall-reëls en eweknie-verhoudings gebruik word, en op sigself lei dit nêrens heen nie. Die bereikbare eindpunt is iets anders: ’n gasheernaam of adres op die onderliggende netwerk plus ’n UDP-poort, en dit verander wanneer die masjien van plek verander. Die statiese kaart is die verbinding tussen die twee.

Slegs gashere wat koud geskakel moet word, hoort in die kaart, wat gewoonlik die vuurtorings en miskien ’n aflos beteken. Om daardie lys kort te hou is ’n ontwerpdoel, want elke handmatige inskrywing word ’n feit wat iemand moet onderhou. Om die twee adrestipes te verwar is die gewone konfigurasiefout: ’n openbare adres wat in die vuurtoring-lys geplaas word, laat nie die ontdekking begin nie.

Identiteit gaan waar identiteit verwag word. Bereikbaarheid gaan in die kaart.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomie van ’n kaartinskrywing

Die sleutel is die overlay-adres wat as ’n aangehaalde string geskryf word, en die waarde is ’n lys eindpunte, so een identiteit kan verskeie toegangspunte hê. Elke eindpunt dra ’n gasheer en ’n poort, en die poort moet ooreenstem met wat die ander kant werklik luister. Nebula se verstek is UDP 4242, wat ’n beginpunt is eerder as ’n belofte oor jou ontplooiing.

Verskeie eindpunte is nuttig wanneer ’n vuurtoring meer as een pad in het, soos ’n openbare adres en ’n private adres vir gashere op dieselfde segment. Die kliënt probeer hulle in volgorde, so plaas die betroubaarste een eerste. Vir IPv6, plaas die adres tussen vierkantige hakies voordat jy die poort byvoeg; om dit verkeerd te doen lewer ’n ontledingsfout wat na die verkeerde lyn wys.

’n Verkeerde poort lewer stilte in plaas van ’n fout, want UDP het geen handskud om te weier nie. Dit maak die inskrywingsformaat die moeite werd om teen die Nebula-verwysing vir static_host_map eerder as teen jou geheue na te gaan. Die verwysing dek ook eindpuntlyste en DNS-verfrissingsgedrag.

Opstarting moet werk voordat die overlay bestaan

’n DNS-naam in die kaart moet deur die oplosser opgelos word wat die gasheer het voordat enige tonnel bestaan, dit is die gewone stelseloplosser. Toets dit van dieselfde masjien, by die opstarting, met die overlay gestop. ’n Naam wat net deur die overlay se eie DNS opgelos word, kan nie die overlay opstart nie. Dieselfde toets geld vir die roete: ’n firewall-reël wat die overlay toelaat maar nie die eerste UDP-uitruiling nie, blokkeer die aanvanklike pakket.

Peil die poort met ’n UDP-gereedskap in plaas daarvan om aan te neem dit is oop. Bevestig dat enige poortaanstuur op die pad na die korrekte interne gasheer wys en dat daar ’n terugpad bestaan. As die gasheernaam na verskeie adresse oplos, toets elkeen, want ’n kliënt kan ’n adres kies wat jy nooit nagegaan het nie.

Statiese inskrywings word direk geskakel en raadpleeg nooit ’n vuurtoring nie. Dit is waarom ’n fout hier soos ’n gewone tydsverloop lyk sonder dat enige eweknie betrokke is.

Wat gebeur ná die eerste handskud

Sodra ’n gasheer ’n vuurtoring bereik, leer hy van eweknieë en hul bereikbare adresse sonder meer handmatige inskrywings. Gashere wat sedert die laaste verbinding beweeg het, word deur daardie kanaal ontdekbaar. Dit is die opbrengs daarvan om die handmatige kaart klein te hou.

Gashere kan ook bykomende bereikbare adresse van hul eie adverteer, wat is hoe ’n eweknie agter ’n bekende openbare adres ander help om dit te vind. Daardie advertensies word geleer, nie in die statiese kaart getik nie.

Verfrissingsgedrag maak saak vir eindpunte wat as DNS-name geskryf is, want ’n opgeloste adres kan verander terwyl die proses aanhou loop. Nebula se instellings beheer hoe daardie opsoekings plaasvind, insluitend watter oplosser gebruik word, so lees hulle in plaas daarvan om die stelselverstek aan te neem. Op ’n gasheer wie se oplosser verander wanneer ’n tonnel opkom, kan die verkeerde instelling ’n werkende opstarting in ’n naam verander wat middel-in die sessie ophou oplos. Om die opsoeking aan ’n stabiele oplosser te pen, is dikwels die verskil tussen ’n betroubare overlay en een wat aan en af gaan.

Wanneer ontdekking werk en een eweknie nie

As vuurtorings bereikbaar is en die meeste eweknieë verbind, is die opstarting nie die probleem nie. Die oorblywende paar kan óf nie ’n bruikbare pad na mekaar vind nie, óf dit faal bo bereikbaarheid. Om nog ’n spelling van die vuurtoring-adres by te voeg, kan nie een van die twee gevalle herstel nie.

Kontroleer die paar voordat jy die kaart redigeer waarop alles anders al staatmaak. ’n Kaartverandering versteur elke gasheer, so dit is die laaste ding om aan te raak, nie die eerste nie.

Begin met sertifikate van dieselfde owerheid, want ’n verwerpte handskud kan van ver soos ’n onbereikbare eweknie lyk. Kontroleer dan of die paar ’n direkte pad kan vestig en of ’n aflos opgestel is vir netwerke wat direkte verkeer weier. ’n Aflos voeg ’n sprong en ’n afhanklikheid by, maar dit is ’n ondersteunde antwoord, en om die eweknie-pad reg te maak is ’n ander taak as om ontdekking reg te maak.