Nebula static_host_map: adresa që një far nuk mund ta japë

Çdo far mund t’i tregojë një hosti për çdo partner tjetër, përveç se ku ndodhet vetë fari. Diçka duhet të jetë e njohur para se të ekzistojë overlay-i, dhe Nebula e vendos atë diçka në një hartë të vogël. Harta çiftëzon një identitet overlay me një adresë që funksionon në rrjetin e zakonshëm. Gjithçka që mësohet më vonë varet nga fakti që ky çiftëzim të jetë i saktë.

Dy adresa me dy detyra

Çdo host Nebula zotëron një adresë overlay që mbetet fikse ndërsa pajisja lëviz midis rrjeteve. Kjo adresë është identiteti që përdorin certifikatat, rregullat e firewall-it dhe marrëdhëniet mes partnerëve, dhe e vetme nuk rrugëton askund. Pika fundore e arritshme është diçka tjetër: një emër hosti ose adresë në rrjetin themelor plus një port UDP, dhe ndryshon sa herë që makina ndryshon vendndodhje. Harta statike është bashkimi mes të dyjave.

Në hartë hyjnë vetëm hostet që duhet të thirren në të ftohtë, që zakonisht do të thotë farat dhe ndoshta një relay. Mbajtja e asaj liste të shkurtër është një objektiv projektimi, sepse çdo hyrje manuale bëhet një fakt që dikush duhet ta mirëmbajë. Ngatërrimi i dy llojeve të adresave është gabimi i zakonshëm i konfigurimit: një adresë publike e vendosur në listën e farave nuk e nis zbulimin.

Identiteti shkon atje ku pritet identitet. Arritshmëria shkon në hartë.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomia e një hyrjeje në hartë

Çelësi është adresa overlay e shkruar si varg mes thonjëzave, dhe vlera është një listë pikash fundore, kështu që një identitet mund të ketë disa pika hyrjeje. Çdo pikë fundore mban një host dhe një port, dhe porti duhet të përputhet me atë që pala tjetër dëgjon në të vërtetë. Vlera parazgjedhur e Nebula është UDP 4242, që është një pikënisje dhe jo një premtim për vendosjen tuaj.

Disa pika fundore janë të dobishme kur një far ka më shumë se një rrugë hyrëse, si një adresë publike dhe një adresë private për hostet në të njëjtin segment. Klienti i provon ato me radhë, prandaj vendos më të besueshmen e para. Për IPv6, vendos adresën mes kllapave katrore përpara se të shtosh portin; gabimi këtu prodhon një gabim analize që tregon rreshtin e gabuar.

Një port i gabuar prodhon heshtje në vend të një gabimi, sepse UDP nuk ka shtrëngim duarsh për të refuzuar. Prandaj ia vlen të kontrollohet formati i hyrjes kundrejt referencës së Nebula për static_host_map dhe jo kundrejt kujtesës. Referenca mbulon gjithashtu listat e pikave fundore dhe sjelljen e rifreskimit të DNS.

Bootstrap-i duhet të funksionojë para overlay-it

Një emër DNS në hartë duhet të zgjidhet përmes resolver-it që hosti ka para se të ekzistojë çdo tunel, domethënë resolver-i i zakonshëm i sistemit. Testoje nga e njëjta makinë, në nisje, me overlay-in e ndalur. Një emër që zgjidhet vetëm përmes DNS-së së vetë overlay-it nuk mund ta bëjë bootstrap overlay-in. I njëjti test vlen për rrugën: një rregull firewall-i që lejon overlay-in por jo shkëmbimin e parë UDP bllokon paketën fillestare.

Kontrollo portin me një mjet UDP në vend që të supozosh se është i hapur. Konfirmo që çdo ridrejtim porti në rrugë synon hostin e brendshëm të saktë dhe se ekziston një rrugë kthimi. Nëse emri i hostit zgjidhet në disa adresa, testo secilën, sepse klienti mund të zgjedhë një adresë që nuk e ke kontrolluar kurrë.

Hyrjet statike thirren drejtpërdrejt dhe nuk konsultojnë kurrë një far. Prandaj një dështim këtu duket si një timeout i zakonshëm pa asnjë partner të përfshirë.

Çfarë ndodh pas shtrëngimit të parë të duarve

Sapo një host arrin një far, mëson për partnerët dhe adresat e tyre të arritshme pa më shumë hyrje manuale. Hostet që janë zhvendosur që nga lidhja e fundit bëhen të zbulueshme përmes atij kanali. Ky është shpërblimi për mbajtjen e hartës manuale të vogël.

Hostet mund të njoftojnë gjithashtu adresat e tyre shtesë të arritshme, dhe kështu një partner pas një adrese publike të njohur i ndihmon të tjerët ta gjejnë. Këto njoftime mësohen, nuk shkruhen në hartën statike.

Sjellja e rifreskimit ka rëndësi për pikat fundore të shkruara si emra DNS, sepse një adresë e zgjidhur mund të ndryshojë ndërsa procesi vazhdon të punojë. Cilësimet e Nebula kontrollojnë se si ndodhin ato kërkime, duke përfshirë cili resolver përdoret, prandaj lexoji ato në vend që të supozosh parazgjedhjen e sistemit. Në një host, resolver-i i të cilit ndryshon kur ngrihet një tunel, cilësimi i gabuar mund ta kthejë një bootstrap funksional në një emër që ndalon së zgjidhuri në mes të sesionit. Lidhja e kërkimit me një resolver të qëndrueshëm është shpesh ndryshimi mes një overlay të besueshëm dhe një të ndërprerë.

Kur zbulimi funksionon dhe një partner jo

Nëse farat janë të arritshëm dhe shumica e partnerëve lidhen, bootstrap-i nuk është problemi. Çifti i mbetur ose nuk gjen një rrugë të përdorshme drejt njëri-tjetrit, ose dështon mbi arritshmërinë. Shtimi i një shkrimi tjetër të adresës së farit nuk rregullon asnjë nga dy rastet.

Kontrollo çiftin përpara se të editosh hartën mbi të cilën tashmë mbështetet gjithçka tjetër. Një ndryshim i hartës shqetëson çdo host, prandaj është gjëja e fundit që preket, jo e para.

Fillo me certifikata nga i njëjti autoritet, sepse një shtrëngim duarsh i refuzuar mund të duket nga larg si një partner i paarritshëm. Pastaj kontrollo nëse çifti mund të krijojë një rrugë të drejtpërdrejtë dhe nëse një relay është konfiguruar për rrjetet që refuzojnë trafikun e drejtpërdrejtë. Një relay shton një hop dhe një varësi, por është një përgjigje e mbështetur, dhe rregullimi i rrugës së çiftit është detyrë tjetër nga rregullimi i zbulimit.