Nebula static_host_map: adressen som en fyr inte kan ge

Varje fyr kan berätta för en värd om varje annan peer utom var fyren själv bor. Något måste vara känt innan overlayen finns, och Nebula lägger det något i en liten karta. Kartan parar en overlay-identitet med en adress som fungerar på det vanliga nätet. Allt som lärs senare beror på att det paret är rätt.

Två adresser med två uppgifter

Varje Nebula-värd äger en overlay-adress som står fast medan enheten flyttar mellan nät. Den adressen är identiteten som certifikat, brandväggsregler och peer-relationer använder, och ensam routar den ingenstans. Slutpunkten som nås är något annat: ett värdnamn eller en adress på det underliggande nätet plus en UDP-port, och den ändras varje gång maskinen byter plats. Den statiska kartan är förbindelsen mellan de två.

Bara värdar som måste ringas upp kallt hör hemma i kartan, vilket oftast betyder fyrarna och kanske en relay. Att hålla listan kort är ett designmål, eftersom varje manuell post blir ett faktum som någon måste underhålla. Att blanda ihop de två adresstyperna är det vanliga konfigurationsfelet: en offentlig adress i fyrlistan får inte upptäckten att starta.

Identitet går dit identitet förväntas. Nåbarhet går i kartan.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomin hos en kartpost

Nyckeln är overlay-adressen skriven som en sträng inom citattecken, och värdet är en lista med slutpunkter, så en identitet kan ha flera ingångar. Varje slutpunkt bär en värd och en port, och porten måste stämma med det den andra sidan faktiskt lyssnar på. Nebulas standard är UDP 4242, vilket är en utgångspunkt och inte ett löfte om din driftsättning.

Flera slutpunkter är användbara när en fyr har mer än en väg in, till exempel en offentlig adress och en privat adress för värdar i samma segment. Klienten prövar dem i ordning, så sätt den mest pålitliga först. För IPv6 sätter du adressen inom hakparenteser innan porten läggs till; att göra fel ger ett tolkningsfel som pekar på fel rad.

En fel port ger tystnad i stället för ett fel, eftersom UDP inte har någon handskakning att avvisa med. Därför är det värt att kontrollera formatet mot Nebulas referens för static_host_map i stället för minnet. Referensen täcker också slutpunktslistor och DNS-uppdateringens beteende.

Bootstrap måste fungera före overlayen

Ett DNS-namn i kartan måste lösas genom den resolver som värden har innan någon tunnel finns, det vill säga den vanliga systemresolvern. Testa det från samma maskin vid uppstart med overlayen stoppad. Ett namn som bara löses genom overlayens egen DNS kan inte bootstrappa overlayen. Samma test gäller för rutten: en brandväggsregel som tillåter overlayen men inte det första UDP-utbytet blockerar det första paketet.

Kontrollera porten med ett UDP-verktyg i stället för att anta att den är öppen. Bekräfta att varje portvidarebefordran på vägen pekar på rätt intern värd och att det finns en returväg. Om värdnamnet löses till flera adresser, testa var och en, eftersom en klient kan välja en adress du aldrig kontrollerat.

Statiska poster rings upp direkt och frågar aldrig en fyr. Därför ser ett fel här ut som en vanlig tidsutgång utan någon inblandad peer.

Vad som händer efter den första handskakningen

När en värd når en fyr lär den sig om peers och deras nåbara adresser utan fler manuella poster. Värdar som har flyttat sig sedan den senaste anslutningen blir upptäckbara genom den kanalen. Det är vinsten med att hålla den manuella kartan liten.

Värdar kan också annonsera egna extra nåbara adresser, och så hjälper en peer bakom en känd offentlig adress andra att hitta den. De annonserna lärs in, de skrivs inte i den statiska kartan.

Uppdateringsbeteendet spelar roll för slutpunkter skrivna som DNS-namn, eftersom en löst adress kan ändras medan processen fortsätter att köras. Nebulas inställningar styr hur dessa uppslag sker, inklusive vilken resolver som används, så läs dem i stället för att anta systemets standard. På en värd vars resolver ändras när en tunnel kommer upp kan fel inställning göra en fungerande bootstrap till ett namn som slutar lösas mitt i sessionen. Att fästa uppslaget vid en stabil resolver är ofta skillnaden mellan en pålitlig overlay och en som hackar.

När upptäckten fungerar och en peer inte

Om fyrarna nås och de flesta peers ansluter är bootstrap inte problemet. Det återstående paret hittar antingen ingen användbar väg till varandra eller misslyckas ovanför nåbarheten. Att lägga till en annan stavning av fyrans adress reparerar inget av de två fallen.

Kontrollera paret innan du redigerar kartan som allt annat redan vilar på. En kartändring stör varje värd, så det är det sista man rör, inte det första.

Börja med certifikat från samma myndighet, eftersom en avvisad handskakning på avstånd kan se ut som en onåbar peer. Kontrollera sedan om paret kan upprätta en direkt väg och om en relay är konfigurerad för nät som avvisar direkt trafik. En relay lägger till ett hopp och ett beroende, men det är ett stött svar, och att laga parets väg är en annan uppgift än att laga upptäckten.