Nebula static_host_map: l’adreça que un far no pot donar

Cada far pot explicar a un host sobre tots els altres parells excepte on viu el mateix far. Alguna cosa ha de ser coneguda abans que existeixi l’overlay, i Nebula posa aquesta cosa en un mapa petit. El mapa aparella una identitat d’overlay amb una adreça que funciona a la xarxa ordinària. Tot el que s’aprèn després depèn que aquest aparellament sigui correcte.

Dues adreces amb dues feines

Cada host de Nebula té una adreça d’overlay que es manté fixa mentre el dispositiu es mou entre xarxes. Aquesta adreça és la identitat que fan servir els certificats, les regles de tallafoc i les relacions entre parells, i per si sola no encamina enlloc. El punt final abastable és una altra cosa: un nom d’host o una adreça a la xarxa subjacent més un port UDP, i canvia sempre que la màquina canvia de lloc. El mapa estàtic és la unió entre les dues.

Al mapa només hi van els hosts que s’han de marcar en fred, cosa que normalment vol dir els fars i potser un repetidor. Mantenir aquesta llista curta és un objectiu de disseny, perquè cada entrada manual es converteix en un fet que algú ha de mantenir. Confondre els dos tipus d’adreça és l’error de configuració habitual: una adreça pública posada a la llista de fars no fa començar el descobriment.

La identitat va on s’espera la identitat. L’abastabilitat va al mapa.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomia d’una entrada del mapa

La clau és l’adreça d’overlay escrita com una cadena entre cometes, i el valor és una llista de punts finals, així que una identitat pot tenir diverses portes d’entrada. Cada punt final porta un host i un port, i el port ha de coincidir amb el que l’altra banda escolta realment. El valor per defecte de Nebula és UDP 4242, que és un punt de partida i no una promesa sobre la teva implantació.

Diversos punts finals són útils quan un far té més d’un camí d’entrada, com ara una adreça pública i una adreça privada per als hosts del mateix segment. El client els prova per ordre, així que posa el més fiable primer. Per a IPv6, posa l’adreça entre claudàtors abans d’afegir el port; equivocar-te aquí produeix un error d’anàlisi que assenyala la línia incorrecta.

Un port equivocat produeix silenci en lloc d’un error, perquè UDP no té cap encaixada de mans per rebutjar. Per això val la pena comprovar el format de l’entrada contra la referència de static_host_map de Nebula i no contra la memòria. La referència també cobreix les llistes de punts finals i el comportament d’actualització del DNS.

L’arrencada ha de funcionar abans de l’overlay

Un nom DNS del mapa s’ha de resoldre pel resolutor que el host té abans que existeixi cap túnel, és a dir, el resolutor ordinari del sistema. Prova-ho des de la mateixa màquina, en arrencar, amb l’overlay aturat. Un nom que només es resol pel DNS propi de l’overlay no pot arrencar l’overlay. La mateixa prova s’aplica a la ruta: una regla de tallafoc que permet l’overlay però no el primer intercanvi UDP bloqueja el paquet inicial.

Comprova el port amb una eina UDP en lloc de suposar que és obert. Confirma que qualsevol reenviament de port del camí apunta al host intern correcte i que hi ha un camí de tornada. Si el nom d’host es resol a diverses adreces, prova cada una, perquè el client pot triar una adreça que mai no has comprovat.

Les entrades estàtiques es marquen directament i mai no consulten cap far. Per això una fallada aquí sembla un temps d’espera normal sense cap parell implicat.

Què passa després de la primera encaixada de mans

Quan un host arriba a un far, aprèn sobre els parells i les seves adreces abastables sense més entrades manuals. Els hosts que s’han mogut des de l’última connexió es tornen descobribles per aquell canal. Aquesta és la recompensa de mantenir petit el mapa manual.

Els hosts també poden anunciar adreces abastables addicionals pròpies, i així un parell darrere d’una adreça pública coneguda ajuda els altres a trobar-lo. Aquests anuncis s’aprenen, no s’escriuen al mapa estàtic.

El comportament d’actualització importa per als punts finals escrits com a noms DNS, perquè una adreça resolta pot canviar mentre el procés continua en marxa. La configuració de Nebula controla com es fan aquestes consultes, incloent-hi quin resolutor s’usa, així que llegeix-la en lloc de suposar el valor per defecte del sistema. En un host el resolutor del qual canvia quan s’aixeca un túnel, la configuració equivocada pot convertir un arrencada funcional en un nom que deixa de resoldre’s a mig camí de la sessió. Fixar la consulta a un resolutor estable sovint és la diferència entre un overlay fiable i un d’intermitent.

Quan el descobriment funciona i un parell no

Si els fars són abastables i la majoria de parells es connecten, l’arrencada no és el problema. La parella restant o no troba un camí usable entre ells o falla per sobre de l’abastabilitat. Afegir una altra grafia de l’adreça del far no pot reparar cap dels dos casos.

Comprova la parella abans d’editar el mapa en què ja es recolza tota la resta. Un canvi de mapa pertorba tots els hosts, així que és l’última cosa a tocar, no la primera.

Comença amb certificats de la mateixa autoritat, perquè una encaixada de mans rebutjada pot semblar de lluny un parell inabastable. Després comprova si la parella pot establir un camí directe i si hi ha un repetidor configurat per a xarxes que rebutgen el trànsit directe. Un repetidor afegeix un salt i una dependència, però és una resposta suportada, i arreglar el camí del parell és una tasca diferent d’arreglar el descobriment.