Nebula advertise_addrs o static_host_map: pumili ayon sa may-ari

Parehong naglalagay ng address sa harap ng peer ang mga setting na static_host_map at advertise_addrs, at sumasagot sila sa magkaibang tanong. Ang isa ay lokal na file na naglilista ng overlay address at ng underlay endpoint na tatawagan. Ang isa ay host na nagsasabi sa mga parola nito kung aling karagdagang endpoint ang makakaabot dito. Ang pagmamay-ari ang tunay na pagkakaiba: ang mapa ay pinapanatili ng lahat ng nangangailangan nito, at ang anunsyo ng host mismo.

Magpasya ayon sa kung sino ang may-ari ng impormasyon

Ang bawat nagbabagong peer sa static na file ng bawat peer ay gawaing pagpapanatili na lumalaki sa parisukat ng fleet. Iyon ang praktikal na dahilan para gumamit ng kabilang setting kapag ang host mismo ang nakakaalam ng sagot.

Ang tanong ng pagmamay-ari ay hinuhulaan din ang mangyayari kapag nagbago ang address. Sa static na mapa, kailangang tandaan ng isang tao ang bawat peer na may lumang entry. Sa anunsyo, ipinapalathala ng host ang bagong endpoint at ipinapasa ito ng mga parola nito, kaya nananatiling lokal ang pagbabago sa makina na lumipat.

Kailangan pa rin ng bootstrap ang static na entry

Kailangang maabot ng kliyente ang kahit isang parola bago ito makapagtanong kaninuman tungkol sa ibang peer. Ang unang paglukso ay hindi maaaring magmula sa pagtuklas, kaya nagmumula ito sa isang static na entry sa konfigurasyon ng kliyente. Gawing tama ang nag-iisang entry na iyon at matututuhan ang natitirang overlay.

Ang entry sa mapa ay nagpapares ng address ng Nebula sa isa o higit pang maabot na endpoint ng IP o DNS at mga port. Normal na panatilihin doon ang mga parola; panatilihin doon ang bawat peer ay ang pattern na tumatanda nang masama, dahil ang bawat bagong peer ay nangangahulugan ng pag-edit ng mga file sa mga makinang maaaring hindi mo kontrolado. Panatilihing maikli ang listahan para pa rin itong ma-verify ng isang tao sa pamamagitan ng pagbasa.

Mag-anunsyo kapag alam ng host ang endpoint

Ang host sa likod ng port forwarding ay maabot sa pampublikong address na hindi nakatalaga sa alinman sa sarili nitong interface. Hindi nito matutuklasan ang address na iyon sa pamamagitan ng pagtingin sa sarili. Pinapayagan ito ng advertise_addrs na ipalathala ang endpoint sa pamamagitan ng mga parola nito para matutuhan ng ibang peer ang landas na talagang gumagana. Umiiral ang setting dahil ang host ang tanging partidong nakakaalam na ginawa ang mapping.

Gamitin ang address at port na talagang maaabot ng ibang peer. Ganoon din ang pangangatwiran para sa host na may ilang landas ng network, kung saan mas mainam ang isang landas para sa mga peer sa isang partikular na network. Ang anunsyo ay pahayag tungkol sa underlay, hindi kahilingan para sa anuman. Kapag nagbago ang mapping, i-update ang anunsyo sa host at hayaang dalhin ito ng pagtuklas, sa halip na i-edit ang mga static na file sa buong fleet.

Ang pag-anunsyo ay hindi abot

Ang pagpapalathala ng endpoint ay hindi lumilikha ng panuntunan sa pagpapasa ng router, hindi nagbubukas ng firewall sa itaas at hindi nagpaparesolba ng pangalan ng DNS. Magkahiwalay na piraso ng trabaho ang mga iyon, at ang tamang anunsyo na kulang ang port forwarding ay gumagawa ng eksaktong pagkabigo na sinusubukan mong ayusin. Ang anunsyo ay isang pag-aangkin tungkol sa abot, hindi isang mekanismong nagtatatag nito.

Suriin ang landas mula sa labas bago sisihin ang pagtuklas. Ang peer na natututo ng endpoint pero hindi makakumpleto ng handshake ay may problema sa routing o filtering sa underlay, at ang pag-uulit ng parehong address sa dalawang setting ay hindi magbabago niyon.

Panatilihing hiwalay ang overlay address sa endpoint

Ang sertipiko ng node ay tumutukoy sa address nitong Nebula. Ang mga inanunsyong address ay kabilang sa pinagbabatayang network, at maaaring magbago nang hindi hinahawakan ang sertipiko. Ang Paglabas ng bagong sertipiko na may ibang overlay IP ay ibang operasyon, kasama ang sarili nitong mga kahihinatnan para sa bawat ugnayan ng pagtitiwala na nagpako sa luma. Panatilihing hiwalay ang dalawang pagbabago sa runbook, kung hindi ay maitala ang paglipat ng endpoint bilang muling paglabas.

Kapag natigil ang triage, hiwalayin nang malinaw ang dalawang layer: ibinabalik ba ng pagtuklas ang inaasahang endpoint, at naaabot ba ito ng handshake? Kung tama ang pagtuklas at nabigo ang mga packet, nasa ilalim ng overlay ang problema. Kung mali ang pagtuklas, nasa mapa o anunsyo ang problema, at doon nararapat ang pagwawasto.