ZeroTier இல் அனுமதிக்கப்பட்டும் முகவரி இல்லையா? இரண்டு தனி அமைப்புகள்
உறுப்பினரை அனுமதிப்பதும் அவருக்கு முகவரி வழங்குவதும் இரண்டு தனி அமைப்புகள். IP உருவாக்கும் முன் குளம், ஒதுக்கீட்டு முறை மற்றும் வாடிக்கையாளர் பயன்படுத்திய நிலையைப் படியுங்கள்.
ZeroTier உறுப்பினரை OK எனக் காட்டுகிறது, வலைப்பிணைப்பு இணைக்கப்பட்டுள்ளது, இன்னும் ping செய்ய முகவரி இல்லை. இந்தக் கலவை பிழை போலத் தோன்றுகிறது, பொதுவாக இது பிளவுபட்ட கட்டமைப்பு: உறுப்பினரை அனுமதிப்பது ஒரு சுவிட்ச், அவருக்கு முகவரி வழங்குவது மற்றொன்று. வலைப்பிணைப்பு ஒரு சாதனத்தை ஏற்றுக்கொண்டு அதற்கு எதையும் ஒதுக்காமல் இருக்க முடியும், ஏனெனில் முகவரிக் குளம் அல்லது ஒதுக்கீட்டு முறை ஒருபோதும் அமைக்கப்படவில்லை.
எதையும் மாற்றும் முன் இரு பக்கங்களையும் படியுங்கள். பதில் இரண்டு இடங்களில் தெரிகிறது, அவற்றில் ஒன்று மட்டுமே கட்டுப்படுத்தியில் உள்ளது.
அனுமதியும் ஒதுக்கீடும் வெவ்வேறு சுவிட்சுகள்
அனுமதி இந்த முனை வலைப்பிணைப்பில் பங்கேற்கலாமா என்பதற்குப் பதிலளிக்கிறது. முகவரி ஒதுக்கீடு பங்கேற்ற பிறகு வலைப்பிணைப்பு அதற்கு என்ன தருகிறது என்பதற்குப் பதிலளிக்கிறது, அந்தப் பதில் முகவரிக் குளத்திலிருந்தும் ஒதுக்கீட்டு முறையிலிருந்தும் வருகிறது. எந்த அமைப்பும் மற்றதைக் குறிக்கவில்லை. ஒன்று அனுமதி, மற்றொன்று ஒதுக்கீடு.
கட்டுப்படுத்தி கட்டமைப்பில் பொதுவாக நிர்வகிக்கப்பட்ட வழி, முகவரி வரம்பு மற்றும் தானியங்கி ஒதுக்கீடு பயன்படுத்தப்படுகிறதா என்பதைத் தீர்மானிக்கும் முறை இருக்கும். வேறு சூழலிலிருந்து வலைப்பிணைப்பு ID ஐ நகலெடுப்பது உறுப்பினர் நிலையைக் கொண்டுவரும், அந்தக் கட்டமைப்பில் எதையும் கொண்டுவராது.
அதனால்தான் சாதனம் உறுப்பினர் பட்டியலில் ஆரோக்கியமாகத் தெரியும், அதன் ஒதுக்கப்பட்ட முகவரி நிரல் காலியாகவே இருக்கும். கட்டுப்படுத்தி அதை ஏற்றுக்கொண்டது, கொடுக்க ஏதுமில்லை. இரண்டு கூற்றுகளும் ஒரே நேரத்தில் உண்மை.
| Layer | What it decides | Where it is configured |
|---|---|---|
| Membership | Whether the node may join | Member authorization on the network |
| Pool | Which addresses exist to hand out | Network address range |
| Assignment mode | Whether they are handed out automatically | Network v4/v6 assignment settings |
உறுப்பினரின் உண்மையான நிலையைப் படித்தல்
கட்டுப்படுத்தி கருதியதை அல்ல, வாடிக்கையாளர் உண்மையில் பெற்றதைக் கேளுங்கள். எளிய பட்டியல் நிலை மற்றும் முகவரி நிரல்களைக் காட்டுகிறது, JSON வடிவம் வாடிக்கையாளர் பயன்படுத்திய வலைப்பிணைப்பு கட்டமைப்பை, நிர்வகிக்கப்பட்ட முகவரிகள் மற்றும் வழிகளுடன் காட்டுகிறது.
zerotier-cli listnetworks
zerotier-cli -j listnetworks | jq '.networks[] | {nwid, status, assignedAddresses}'இரண்டு வெளியீடுகளையும் ஒரே வலைப்பிணைப்பு ID க்கு ஒப்பிடுங்கள், இயங்குதளத்தின் சொந்தப் பட்டியலில் தோன்றும் இயற்பியல் அடாப்டர்களுக்கல்ல. காலியான முகவரித் தொகுப்புடன் OK தெரிவிக்கும் வரி இணைப்புப் பிழையல்ல, ஒதுக்கீட்டு இடைவெளியை உறுதிப்படுத்துகிறது. தவறான வரியைப் படிப்பது இந்தப் பிழையின் மற்ற பாதி.
ACCESS_DENIED நிலை அனுமதியை நோக்கிக் காட்டுகிறது, அது வேறு பழுதுநீக்கம். கட்டளை உள்ளூர் அங்கீகார டோக்கனைப் படிக்கவே முடியவில்லை என்றால், பிரச்சினை கட்டுப்படுத்தியின் மறுப்பல்ல, உள்ளூர் அனுமதிகள், திருத்தம் நீங்கள் அமர்ந்திருக்கும் இயந்திரத்திலேயே.
வாடிக்கையாளர் கட்டுப்படுத்தி அனுப்புவதைப் புறக்கணிக்கும்போது
நிர்வகிக்கப்பட்ட கட்டமைப்பு பயன்படுத்தப்படுகிறதா என்பதைத் தீர்மானிக்கும் சொந்த அமைப்புகள் வாடிக்கையாளருக்கு உண்டு. நிர்வகிக்கப்பட்ட முகவரிகள், நிர்வகிக்கப்பட்ட வழிகள் அல்லது இயல்புநிலை வழி கையாளுதலை முடக்கும் சுயவிவரம் வலைப்பிணைப்பு அனுப்புவதைத் தூக்கி எறியும், உறுப்பினர் பட்டியல் கட்டுப்படுத்தியின் பக்கத்திலிருந்து இன்னும் சரியாகவே தெரியும்.
அந்தக் கொடிகள் உள்ளூர் முனையை மட்டுமே பாதிக்கின்றன. அவற்றை மாற்றுவது மற்ற உறுப்பினர்கள் பெறுவதை மாற்றாது, ஒருபோதும் வரையறுக்கப்படாத குளத்தைச் சரிசெய்யாது.
எனவே கண்டறிதலுக்கு இரண்டு கிளைகள் உள்ளன: கட்டுப்படுத்தியிடம் கொடுக்க முகவரி இல்லை, அல்லது வாடிக்கையாளர் வழங்கப்பட்டதை மறுத்தார். அவை வெவ்வேறு இயந்திரங்களில் வெவ்வேறு பழுதுநீக்கங்களுக்கு இட்டுச் செல்கின்றன. JSON வெளியீடு அவற்றை வேறுபடுத்துகிறது, ஏனெனில் முகவரி வலைப்பிணைப்பின் கட்டமைப்பில் இல்லை, அல்லது உள்ளது ஆனால் வாடிக்கையாளரின் பயன்படுத்திய நிலையில் இல்லை.
முகவரியை உருவாக்குவதற்குப் பதிலாக என்ன சரிசெய்வது
தன்னிச்சையான நிலையான முகவரியைத் தட்டச்சு செய்வது கவர்ச்சிகரமான மூன்றாவது விருப்பம், மிக மோசமானது. சீரற்ற முகவரி மற்றொரு முனையுடன் மோதலாம், வலைப்பிணைப்பு பரப்பும் வழிகளுக்கு வெளியே இருக்கலாம், அல்லது firewall விதிகள் வேறுவிதமாகக் கருதும் வரம்பில் விழலாம். அடுத்து வலைப்பிணைப்பைப் பார்க்கும் அனைவரிடமிருந்தும் காணாமல் போன குளத்தையும் மறைக்கிறது. அதற்குப் பதிலாக ஒதுக்கீட்டைச் சரிசெய்யுங்கள், கட்டுப்படுத்தியும் வாடிக்கையாளரும் முடிவில் உடன்படட்டும்.
வலைப்பிணைப்பு என்ன வழங்க வேண்டும் என்று நிர்வாகியிடம் கேளுங்கள், பின்னர் குளம் நோக்கப்பட்ட வரம்பை உள்ளடக்குகிறதா, ஒதுக்கீட்டு முறை இயக்கப்பட்டுள்ளதா என்பதைச் சரிபாருங்கள். மாற்றத்திற்குப் பிறகு மீண்டும் இணையுங்கள், வாடிக்கையாளர் தானாகவே உடனடியாக புதிய கட்டமைப்பை அடைந்துவிடும் என எதிர்பார்ப்பதற்குப் பதிலாக.
முகவரி தோன்றியதும், உண்மையில் தேவைப்பட்டதைச் சோதியுங்கள்: பியர், சேவை அல்லது நுழைவாயிலுக்குப் பின் உள்ள துணை வலைப்பிணைப்பு. உறுப்பினருக்குப் பின் உள்ள LAN ஐ அடைய உறுப்பினர் நிலைக்கு அப்பால் வழியமைப்பும் முன்னனுப்பலும் தேவை, பொது இணைய அணுகலுக்கு வெளியேறும் முனை தேவை, எனவே செயல்படும் முகவரி அந்தச் சோதனையின் தொடக்கம், முடிவல்ல.