Noda ID aŭ reta ID: kiu aliĝas al ZeroTier-reto

Du identigiloj aperas en ĉiu ZeroTier-interparolo, kaj ili sufiĉe similas por esti konfuzitaj en babilfenestro. La noda ID nomas aparaton. La reta ID nomas la virtualan reton, al kiu tiu aparato volas aliĝi. Aliĝo prenas la duan, kaj rajtigo de membro prenas la unuan.

Du identigiloj, du taskoj

Noda identeco kreiĝas kiam la servo unuafoje funkcias sur maŝino, kaj ĝi estas deksesuma adreso el dek signoj. Ĝi restas kun tiu instalado ĝis la identecaj dosieroj forviŝiĝos, pro kio reinstalo povas krei novan membron, kiun neniu aprobis. Reta ID estas dek ses deksesumaj signoj, kaj ĝi identigas virtualan reton anstataŭ maŝinon. La regilo, kiu posedas la reton, mem estas nodo, pro kio la unuaj dek signoj de la reta ID kongruas kun la adreso de la regilo.

Neniu el la du valoroj estas sekreto kaj neniu anstataŭas la alian. Kunhavigi la retan ID kun ĉiu partoprenanto estas normale; kunhavigi nodan ID montras unu aparaton al la regilo.

Legu ĉiun valoron el la komando, kiu raportas ĝin

Unu komando raportas la identecon de la loka servo, kaj alia raportas la retojn, al kiuj ĝi aliĝis. Peti valoron de la malĝusta komando estas la maniero, per kiu homoj finas algluante retan ID en membroliston.

zerotier-cli info
zerotier-cli status
zerotier-cli listnetworks

La unua presas la nodan adreson kaj ĉu la servo estas enrete. La dua aldonas informon pri versio kaj pordo. La tria listigas aliĝintajn retojn kun iliaj retaj ID-oj, stato kaj atribuitaj adresoj, kaj ĝi estas la sola, kiun oni uzu kiam vi bezonas la retan ID.

Aliĝu per la reto, rajtigu per la nodo

La aliĝkomando prenas la retan ID provizitan de tiu, kiu administras la regilon. Pozitiva respondo de la komando signifas, ke la peto estis sendita, ne ke membreco en privata reto estis donita.

Post la aliĝo, la administranto rajtigas la aparaton per ĝia noda ID en la membrolisto de tiu reto. Li ne plu bezonas la retan ID, kaj li ne povas rajtigi aparaton per ĝia gastigantnomo, ĉar la identeco estas la adreso. Se vi estas la administranto, legu la membroliston kaj komparu la nodan adreson kun la peto. Peto, kiu nomas reton sed ne nodan adreson, ne estas plenumebla.

La komuna prefikso havas kialon

Ĉar reta ID komenciĝas per la noda adreso de la regilo, la samaj dek signoj aperas en ambaŭ lokoj. Tio estas enkursiga oportuneco, ne signo, ke la du valoroj estas interŝanĝeblaj.

Ĝi ankaŭ klarigas, kial la identeco de regilo gravas pli ol ĝia vidiga nomo. Restarigi regilon sub nova identeco kreas alian adresspacon, do la retoj difinitaj sub la malnova ne estas la samaj retoj eĉ se la nomoj estas reuzataj.

Konservu la identecon de la regilo en via sekurkopio kune kun ĝia agordo. Trakti tiun identecon kiel etikedon, kiun oni povas regeneri, transformas restarigon en redesegnon.

Kontrolu la rezulton, ne la eligon de la komando

Sukcesa aliĝo estas la komenco de la kontrolo, ne ĝia fino. Poste rigardu la retan eron kaj legu tri kampojn: la staton, la atribuitan adreson kaj la retan ID.

zerotier-cli listnetworks -j
ip -br addr show | grep zt
ping -c 2 10.147.20.5

La unua komando presas la saman liston en analizebla formo, kio faciligas komparon kun tio, kion la administranto atendis. La dua konfirmas, ke la interfaco ricevis adreson, kaj la tria testas samtavolanon en la reto anstataŭ la lokan staton.

Se la ero diras ACCESS_DENIED, la noda ID ne estas rajtigita. Se ĝi diras NOT_FOUND, la reta ID estas malĝusta. Se ĝi diras OK sen adreso, la adresatribuo de la regilo estas la sekva demando, kaj neniu el tiuj tri estas respondita per denova aliĝo.