Nebula advertise_addrs aŭ static_host_map: elektu laŭ la posedanto
Statikan mapon prizorgas ĉiu peer, kiu alvokas ĝin; anoncitan adreson publikigas la gastiganto. Elektu laŭ tio, kiu konas la finpunkton.
La agordoj static_host_map kaj advertise_addrs ambaŭ metas adreson antaŭ peer, kaj ili respondas malsamajn demandojn. Unu estas loka dosiero listiganta overlay-adreson kaj la underlay-finpunkton por alvoki. La alia estas gastiganto, kiu diras al siaj lumturoj, kiuj pliaj finpunktoj povas atingi ĝin. La posedo estas la vera diferenco: la mapon prizorgas ĉiuj, kiuj bezonas ĝin, kaj la anoncon la gastiganto mem.
Decidu laŭ tio, kiu posedas la informon
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
Ĉiu ŝanĝiĝanta peer en la statika dosiero de ĉiu peer estas prizorga tasko, kiu kreskas kun la kvadrato de la ŝiparo. Tio estas la praktika kialo turni al la alia agordo, kiam la gastiganto mem konas la respondon.
La demando pri posedo ankaŭ antaŭdiras, kio okazas, kiam adreso ŝanĝiĝas. Kun statika mapo, iu devas memori ĉiun peer, kiu tenas la malnovan rikordon. Kun anonco, la gastiganto publikigas la novan finpunkton kaj ĝiaj lumturoj transdonas ĝin, do la ŝanĝo restas loka al la maŝino, kiu translokiĝis.
Bootstrap ankoraŭ bezonas statikajn rikordojn
Kliento devas atingi almenaŭ unu lumturon antaŭ ol ĝi povas demandi iun pri aliaj peer. Tiu unua salto ne povas veni de malkovro, do ĝi venas de statika rikordo en la agordo de la kliento. Faru tiun unu rikordon ĝusta kaj la resto de la overlay povas esti lernita.
Mapa rikordo parigas Nebula-adreson kun unu aŭ pliaj atingeblaj IP aŭ DNS finpunktoj kaj pordoj. Teni la lumturojn tie estas normale; teni ĉiun peer tie estas la ŝablono, kiu malbone maljuniĝas, ĉar ĉiu nova peer signifas redakti dosierojn sur maŝinoj, kiujn vi eble ne kontrolas. Tenu la liston sufiĉe mallonga, ke homo ankoraŭ povas kontroli ĝin legante ĝin.
Anoncu, kiam la gastiganto konas la finpunkton
Gastiganto malantaŭ pordvarbado estas atingebla ĉe publika adreso, kiu ne estas asignita al iu ajn el ĝiaj propraj interfacoj. Ĝi ne povas malkovri tiun adreson rigardante sin. advertise_addrs permesas al ĝi publikigi la finpunkton tra siaj lumturoj, por ke aliaj peer lernu vojon, kiu vere funkcias. La agordo ekzistas ĝuste tial, ĉar la gastiganto estas la sola partio, kiu scias, ke la mapado estis farita.
Uzu la adreson kaj pordon, kiujn aliaj peer vere povas atingi. La sama rezonado validas por gastiganto kun pluraj retaj vojoj, kie unu vojo estas preferinda por peer en aparta reto. Anonco estas aserto pri la underlay, ne peto pri io ajn. Kiam la mapado ŝanĝiĝas, ĝisdatigu la anoncon ĉe la gastiganto kaj lasu malkovron porti ĝin, anstataŭ redakti statikajn dosierojn en la tuta ŝiparo.
Anonco ne estas atingeblo
Publikigi finpunkton ne kreas la plusendan regulon de la enkursigilo, ne malfermas supran fajroŝirmilon kaj ne igas DNS-nomon solviĝi. Tiuj estas apartaj laborpecoj, kaj ĝusta anonco kun mankanta pordvarbado produktas ĝuste tiun fiaskon, kiun vi provis ripari. Anonco estas aserto pri atingeblo, ne mekanismo, kiu establas ĝin.
Kontrolu la vojon de ekstere antaŭ ol kulpigi malkovron. Peer, kiu lernas la finpunkton sed ne povas fini handshake, havas enkursigan aŭ filtradan problemon sur la underlay, kaj ripeti la saman adreson en ambaŭ agordoj ne ŝanĝos tion.
Tenu la overlay-adreson aparte de la finpunkto
La atestilo de la nodo identigas ĝian Nebula-adreson. La anoncitaj adresoj apartenas al la suba reto, kaj ili rajtas ŝanĝiĝi sen tuŝi la atestilon. Eldoni novan atestilon kun malsama overlay-IP estas malsama operacio, kun siaj propraj sekvoj por ĉiu fida rilato, kiu fiksis la malnovan. Tenu la du ŝanĝojn aparte en la runbook, alie translokigo de finpunkto estos registrita kiel reeldono.
Kiam triage haltas, apartigu la du tavolojn eksplicite: ĉu malkovro redonas la atendatan finpunkton, kaj ĉu handshake atingas ĝin? Se malkovro pravas kaj pakaĵoj malsukcesas, la problemo estas sub la overlay. Se malkovro malpravas, la problemo estas en la mapo aŭ la anonco, kaj la riparo apartenas tie.