ZeroTier ay ONLINE ngunit ACCESS_DENIED: saan ito aayusin?

Nag-uulat ang ZeroTier ng ONLINE sa antas ng serbisyo at ACCESS_DENIED sa antas ng network, at ang pares na ito ay hindi kontradiksyon. Ang una ay pahayag tungkol sa landas sa pagitan ng iyong kliyente at ng imprastrukturang pangkoordinasyon. Ang pangalawa ay pahayag tungkol sa listahan ng miyembro ng isang network. Basahin ang mga ito nang hiwalay, at sasabihin sa iyo ng kombinasyon kung saan eksaktong titingin.

Ano ang sinusukat ng ONLINE

Iniuulat ng utos ng katayuan kung ang lokal na serbisyo ay may gumaganang landas patungo sa mga root server na nagkoordina ng pagtuklas ng peer. Wala itong sinasabi tungkol sa isang partikular na network, at wala rin tungkol sa kung inaprubahan ng controller ang device na ito. Kaya ang bagong pag-install sa gumaganang koneksyon ay agad na nag-uulat ng ONLINE, bago pa man ito awtorisahin ng kahit sino saanman.

Ituring ang ONLINE na pahayag tungkol sa pagtutubero at ang katayuan ng bawat network na pahayag tungkol sa pagiging miyembro. Ang paggamit ng isa upang ipaliwanag ang isa pa ang pinagmumulan ng karamihan ng pagkalitong ito.

Ano ang hinihiling ng ACCESS_DENIED sa iyo

Sa isang pribadong network, nag-iingat ang controller ng listahan ng miyembro. Ang node na wala sa listahang iyon, o nakalista ngunit hindi awtorisado, ay tumatanggap ng ACCESS_DENIED na wala kahit anong konfigurasyon maliban sa pangunahing handshake. Nasa panig ng controller ang pag-aayos at kailangan nito ang address ng node, hindi ang pangalan ng makina, kaya itugma ang address sa output ng kliyente sa entry ng miyembro at awtorisahin ang entry na iyon.

Ang muling pag-install ng kliyente ay maling unang hakbang, dahil ang bagong pag-install ay nagdadala ng bagong pagkakakilanlan at hindi na ito saklaw ng lumang awtorisasyon. Kung pampubliko ang network, ang parehong katayuan ay tumuturo sa ibang kalagayan, kaya tanungin ang may-ari ng controller kung pribado ang network bago humingi ng pag-apruba. Ang nag-iisang tanong na iyon ang magpapasya sa natitirang usapan.

Ang teksto ng katayuan ay sanga, hindi hatol

Pinapaliit ng bawat katayuan ang susunod na pagsusuri, at ang pagbasa sa mga ito bilang isang mensahe ng pagkabigo ang dahilan kung bakit nagiging buong hapon ng mga muling pag-install ang dalawang minutong pag-aayos. NOT_FOUND ay nangangahulugang wala ang identifier na inilagay mo sa controller na iyon, kaya hindi pa naaabot ang tanong tungkol sa pagiging miyembro. REQUESTING_CONFIGURATION ay nangangahulugang naabot ng node ang controller at naghihintay ng konfigurasyong hindi dumarating, na tumuturo sa landas at hindi sa awtorisasyon. OK ay nangangahulugang naroon na ang pagiging miyembro at konfigurasyon, kaya ang susunod na tanong ay ang itinalagang address at pagkatapos ay ang serbisyo mismo.

Dalawang utos ang naghihiwalay sa lahat ng ito, at pareho silang nagbabasa ng parehong kliyente. Sanggunian ng ZeroTier CLI ay naglilista ng mga string ng katayuan bawat network na ibinabalik nila. Ang unang utos ay ang pananaw sa serbisyo at ang pangalawa ay bawat network:

zerotier-cli status
zerotier-cli listnetworks

Itago ang teksto ng katayuan kapag humihingi ka ng tulong sa administrator. Ang lokal na utos na join na nag-print ng kumpirmasyon ay nagpapatunay lamang na tinanggap ang kahilingan sa lokal, na ibang katotohanan kaysa sa poder na matanggap.

Ang pagiging miyembro ay kabilang sa isang pagkakakilanlan

Ang mga file ng pagkakakilanlan ng kliyente ang kinikilala ng controller, kaya ang pagkopya ng konfigurasyon sa ibang makina o pagbura ng pagkakakilanlan habang nagre-reinstall ay lumilikha ng miyembrong hindi pa nakita ng controller. Ito rin ang dahilan kung bakit ibang bagay ang pagbura ng rekord ng miyembro kaysa sa pagbawi ng awtorisasyon nito. Ang awtorisadong node na tumatakbo pa ay patuloy na sumusubok, at ang rekord na binura sa halip na binawi ay maaaring bumalik bilang bagong kahilingan mula sa parehong address.

Kapag pinagpaliban mo ang isang device, bawiin muna ang awtorisasyon nito at tiyakin na ipinapakita ng entry ang kalagayang iyon bago ka mag-alis ng anuman. Ang pagkakasunod-sunod ang pagkakaiba ng malinis na pag-alis at mahiwagang muling pagsasama.

I-verify pagkatapos ng pagbabago

Basahin muli ang entry ng network, hindi ang utos na gumawa ng pagbabago. Sinasaklaw ng apat na tanong ang resulta, at maaaring mali ang alinman sa kanila habang tama ang tingin ng iba:

zerotier-cli listnetworks
ip -br addr show
ping -c 2 10.147.20.5
ip route get 10.147.20.5

Ang una ay nagpi-print ng pagiging miyembro at itinalagang address para sa bawat network, at ang pangalawa ay nagpapakita kung talagang natanggap ng interface ang address na iyon. Ang huling dalawa ay nagpapatunay na tumutugon ang peer sa network at kung aling interface ang nagdadala ng trapiko. Itala kung aling utos ang sumagot sa aling tanong, upang ang susunod na tao ay magsimula sa ebidensya at hindi sa alaala.

Kung ang pagiging miyembro ay OK at naroon ang address ngunit hindi tumutugon ang mga peer, lumipat na ang problema sa routing o sa patakaran ng peer mismo. Alisin ang teksto ng katayuan sa usapang iyon, dahil nagawa na nito ang trabaho nito. Magkaibang paksa ang rekord ng pagiging miyembro at ang landas, at habang mas maaga silang paghiwalayin, mas maikli ang pagsisiyasat.