Ĉiu lumturo povas rakonti al gastiganto pri ĉiu alia samtavolano krom pri tio, kie la lumturo mem loĝas. Io devas esti konata antaŭ ol la supertavolo ekzistas, kaj Nebula metas tiun ion en unu malgrandan mapon. La mapo parigas supertavolan identecon kun adreso, kiu funkcias en la ordinara reto. Ĉio lernita poste dependas de tio, ke tiu parigo estas ĝusta.

Du adresoj kun du taskoj

Ĉiu Nebula-gastiganto posedas supertavolan adreson, kiu restas fiksa dum la aparato moviĝas inter retoj. Tiu adreso estas la identeco uzata de atestiloj, fajroŝirmilaj reguloj kaj samtavolanaj rilatoj, kaj sola ĝi enkursigas nenie. La atingebla finpunkto estas io alia: gastigantnomo aŭ adreso en la suba reto plus UDP-pordo, kaj ĝi ŝanĝiĝas ĉiufoje, kiam la maŝino ŝanĝas lokon. La statika mapo estas la kunligo inter la du.

Nur gastigantoj, kiuj devas esti vokataj malvarme, apartenas al la mapo, kio kutime signifas la lumturojn kaj eble unu relajson. Teni tiun liston mallonga estas celo de la dezajno, ĉar ĉiu permana enskribo fariĝas fakto, kiun iu devas prizorgi. Konfuzi la du specojn de adreso estas la kutima agorda eraro: publika adreso metita en la lumturan liston ne komencigas la malkovron.

Identeco iras tien, kie identeco estas atendata. Atingebleco iras en la mapon.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomio de mapa enskribo

La ŝlosilo estas la supertavola adreso skribita kiel citita signoĉeno, kaj la valoro estas listo de finpunktoj, do unu identeco povas havi plurajn enirejojn. Ĉiu finpunkto portas gastiganton kaj pordon, kaj la pordo devas kongrui kun tio, kion la alia flanko efektive aŭskultas. La norma valoro de Nebula estas UDP 4242, kio estas komenca punkto, ne promeso pri via deplojo.

Pluraj finpunktoj utilas, kiam lumturo havas pli ol unu eneniron, ekzemple publikan adreson kaj privatan adreson por gastigantoj en la sama segmento. La kliento provas ilin laŭvice, do metu la plej fidindan unue. Por IPv6, metu la adreson en rektajn krampojn antaŭ ol aldoni la pordon; erari pri tio produktas analizan eraron, kiu montras la malĝustan linion.

Malĝusta pordo produktas silenton anstataŭ eraron, ĉar UDP ne havas manpremon por rifuzi. Tial indas kontroli la formatskribon kontraŭ la referenco de Nebula pri static_host_map kaj ne kontraŭ la memoro. La referenco ankaŭ kovras finpunktajn listojn kaj la konduton de DNS-ĝisdatigo.

Ekstartigo devas funkcii antaŭ la supertavolo

DNS-nomo en la mapo devas esti solvata per la solvilo, kiun la gastiganto havas antaŭ ol ekzistas iu ajn tunelo, tio estas la ordinara sistema solvilo. Testu ĝin de la sama maŝino, ĉe ekstarto, kun la supertavolo haltigita. Nomo, kiu solviĝas nur per la propra DNS de la supertavolo, ne povas ekstartigi la supertavolon. La sama testo validas por la itinero: fajroŝirmila regulo, kiu permesas la supertavolon sed ne la unuan UDP-interŝanĝon, blokas la komencan paketon.

Esploru la pordon per UDP-ilo anstataŭ supozi, ke ĝi estas malfermita. Konfirmu, ke ajna pordadreso sur la vojo celas la ĝustan internan gastiganton kaj ke revena vojo ekzistas. Se la gastigantnomo solviĝas al pluraj adresoj, testu ĉiun, ĉar kliento povas elekti adreson, kiun vi neniam kontrolis.

Statikaj enskriboj estas vokataj rekte kaj neniam konsultas lumturon. Tial paneo ĉi tie aspektas kiel ordinara tempolimo sen iu ajn samtavolano.

Kio okazas post la unua manpremo

Post kiam gastiganto atingas lumturon, ĝi lernas pri samtavolanoj kaj iliaj atingeblaj adresoj sen pli da permanaj enskriboj. Gastigantoj, kiuj moviĝis ekde la lasta konekto, fariĝas malkovreblaj per tiu kanalo. Tio estas la rekompenco por teni la permanan mapon malgranda.

Gastigantoj ankaŭ povas anonci proprajn pliajn atingeblajn adresojn, kaj tiel samtavolano malantaŭ konata publika adreso helpas aliajn trovi ĝin. Tiuj anoncoj estas lernataj, ne tajpitaj en la statikan mapon.

La konduto de ĝisdatigo gravas por finpunktoj skribitaj kiel DNS-nomoj, ĉar solvita adreso povas ŝanĝiĝi dum la procezo daŭre funkcias. La agordoj de Nebula regas, kiel tiuj serĉoj okazas, inkluzive de kiu solvilo uziĝas, do legu ilin anstataŭ supozi la sisteman normon. Ĉe gastiganto, kies solvilo ŝanĝiĝas kiam tunelo ekfunkcias, la malĝusta agordo povas transformi funkciantan ekstartigon en nomon, kiu ĉesas solviĝi meze de la seanco. Fiksi la serĉon al stabila solvilo ofte estas la diferenco inter fidinda supertavolo kaj intermita.

Kiam malkovro funkcias kaj unu samtavolano ne

Se lumturoj estas atingeblaj kaj plej multaj samtavolanoj konektiĝas, la ekstartigo ne estas la problemo. La restanta paro aŭ ne povas trovi uzeblan vojon unu al la alia, aŭ malsukcesas super la atingeblo. Aldoni ankoraŭ unu literumon de la lumtura adreso ne povas ripari iun ajn el la du kazoj.

Kontrolu la paron antaŭ ol redakti la mapon, sur kiu jam apogiĝas ĉio alia. Ŝanĝo de la mapo ĝenas ĉiun gastiganton, do ĝi estas la lasta afero tuŝenda, ne la unua.

Komencu per atestiloj de la sama aŭtoritato, ĉar rifuzita manpremo povas de malproksime aspekti kiel neatingebla samtavolano. Poste kontrolu, ĉu la paro povas starigi rektan vojon kaj ĉu relajso estas agordita por retoj, kiuj rifuzas rektan trafikon. Relajso aldonas salton kaj dependecon, sed ĝi estas subtenata respondo, kaj ripari la vojon de la paro estas alia tasko ol ripari la malkovron.

Rilataj artikoloj