தன்னைத் தானே வினவும் கிளையண்டிற்கு மட்டுமே SRV பதிவு உதவுவது ஏன்

உங்கள் மண்டலத்தில் SRV பதிவைச் சேர்ப்பது எந்த VPN கிளையண்டிற்கும் அதைத் தேடக் கற்பிக்காது. கிளையண்ட் லேபிளை அறிந்திருக்க வேண்டும், வினவலை அனுப்ப முடிவெடுக்க வேண்டும், திரும்பி வருவதற்கேற்ப செயல்பட வேண்டும், மேலும் DNS முதல் இரண்டை வழங்க முடியாது. எனவே தோல்வியடைந்த SRV திட்டங்களில் பெரும்பாலானவை DNS உடையில் உள்ள கிளையண்ட் சிக்கல்கள். முதலில் கிளையண்டின் கண்டறிதல் நடத்தையைப் படியுங்கள், பின்னர் அது உண்மையில் வினவும் லேபிளை மட்டும் வெளியிடுங்கள்.

யாரும் வினவாத பதிவு யாருக்கும் உதவ முடியாது

SRV ஒரு சேவையின் இருப்பிடத்தை வெளியிடுகிறது; அது சேவையை அறிவிக்காது. எதுவும் பதிவை கிளையண்டை நோக்கித் தள்ளாது, எந்தத் தீர்வானும் ஒருபோதும் கேட்கப்படாத பெயரைத் தானாக வழங்காது. பயன்பாடு அதைச் செய்ய முடிவெடுக்கும்போது தேடல் தொடங்குகிறது, எனவே லேபிள் தயாரிப்பின் ஆவணங்களிலிருந்தோ நெட்வொர்க்கில் மென்பொருளைக் கவனிப்பதிலிருந்தோ வர வேண்டும். கிளையண்டிற்கு கண்டறிதல் படி இல்லாத இடத்தில், பதிவு மண்டலத்தை மாற்றுகிறது, வேறொன்றையும் அல்ல.

அதனால்தான் நெட்வொர்க்கில் ஒரு தயாரிப்பு வேலை செய்யத் தொடங்கலாம், மற்றொன்று அதே மாற்றத்தால் பாதிக்கப்படாமல் இருக்கும். மாறி மென்பொருள், மேலும் DNS சேவையகம் அதற்குச் சொன்னதைச் சரியாகச் செய்கிறது. திருத்தத்திற்குப் பிறகு மண்டலத்தை மீண்டும் படியுங்கள், ஏனெனில் தவறாகத் தட்டச்சு செய்த லேபிள் ஒரே மாதிரி தெரியும் பதிவுகளுக்கிடையே எளிதில் மறைகிறது.

எழுதுவதற்கு முன் புலங்களைப் படியுங்கள்

ஒரு பதிவு நான்கு மதிப்புகளைக் கொண்டுள்ளது, ஒவ்வொன்றும் வெவ்வேறு கேள்விக்குப் பதிலளிக்கிறது: முன்னுரிமை கிளையண்ட் முயற்சிக்கக்கூடிய இலக்குகளை வரிசைப்படுத்துகிறது, எடை சம முன்னுரிமை இலக்குகளுக்கிடையே சுமையைப் பிரிக்கிறது, போர்ட் போக்குவரத்துப் போர்ட்டைப் பெயரிடுகிறது, இலக்கு ஹோஸ்ட்டைப் பெயரிடுகிறது. விவரக்குறிப்பு . இலக்கிற்கு சேவை வேண்டுமென்றே கிடைக்கவில்லை என்ற பொருளையும் அனுமதிக்கிறது, இது உடைந்த பதிலல்ல, பயனுள்ள பதில்.

இந்தப் புலங்களில் எதுவும் சான்றுகள், சான்றிதழ் கொள்கை அல்லது பயன்பாட்டு பதிப்பைக் கொண்டிருக்கவில்லை, எடையைப் புறக்கணிக்கும் கிளையண்டும் இணைகிறது, திட்டமிட்ட சமநிலை இல்லாமல் மட்டுமே. இலக்கிற்கு அதன் சொந்த முகவரிப் பதிவுகள் தேவை, அது மாற்றுப்பெயராக அல்ல, நியதிப் பெயராக இருக்க வேண்டும். கேட்பவர் இல்லாத ஹோஸ்ட்டைச் சுட்டும் பதிவை வெளியிடுவது DNS பழுதுபோல் படிக்கப்படும் இணைப்புப் பிழையை உருவாக்குகிறது, அதுவே மிக விலையுயர்ந்த தவறான வழிகாட்டல். முழுச் சங்கிலியையும் வெளியிடுங்கள் அல்லது அதில் எதையும் வெளியிடாதீர்கள்.

கிளையண்ட் உண்மையில் அனுப்பும் லேபிளைக் கண்டறியுங்கள்

தயாரிப்பின் பெயர் பற்றிய ஊகத்தால் அல்ல, சான்றுகளால் லேபிளை நிர்ணயியுங்கள். ஒன்று ஆவணங்கள் சேவையின் பெயரைக் கூறும், அல்லது பதிவு கிளையண்ட் தொடங்கும்போது வெளியேறும் வினவலைக் காட்டும். இரு வழிகளும் ஒரே இடத்தில் முடிகின்றன: தீர்வானுடன் சோதிக்கத் துல்லியமான பெயரும் வகையும்.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

பதிலை நீங்கள் வெளியிட்ட பதிவுடன் எழுத்து எழுத்தாக ஒப்பிடுங்கள், ஏனெனில் அடிக்கோடுகளும் இறுதி புள்ளியும் பெயரின் பகுதி. உண்மையில் அனுப்பப்பட்ட வினவலுக்கு காலி பதில் மண்டலத்தைச் சுட்டுகிறது, வினவலே இல்லாதது கிளையண்டைச் சுட்டுகிறது, இந்தக் கண்டுபிடிப்புகள் உங்களை வெவ்வேறு குழுக்களிடம் அனுப்புகின்றன. உண்மையான பதில் கீழே உள்ள வரியைப் போல இருக்கும், அங்கு முன்னுரிமை 20 எந்தக் குறைந்த முன்னுரிமைப் பதிவுக்கும் தோற்கிறது, கிளையண்ட் பெயரிடப்பட்ட இலக்கில் 8443 போர்ட்டை அழைக்கிறது.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

இலக்கும் இருக்க வேண்டும்

தீர்க்கப்படும் இலக்கு பதிலளிக்கும் சேவைக்குச் சமமானது அல்ல. இலக்கின் முகவரிப் பதிவுகளைச் சரிபார்த்து, பின்னர் வெளியிடப்பட்ட போர்ட்டிலும் நெறிமுறையிலும் ஏதாவது கேட்கிறதா எனச் சரிபார்க்கவும். UDP மட்டும் கேட்பவரைச் சுட்டும் TCP பதிவு எந்த மண்டலத் திருத்தமும் சரிசெய்யாத முரண்பாடு. இலக்கு நிலையற்றதாக இருக்கும்போது TTL குறுகியதாக வைத்திருங்கள், பெயர் நகர்வதை நிறுத்தியதும் நீட்டுங்கள்.

கண்டறிதலை உண்மையில் செயல்படுத்தும் கிளையண்டுகள் பதிவை எவ்வளவு மதிக்கின்றன என்பதில் வேறுபடுகின்றன. சிலர் முன்னுரிமையை மட்டும் பயன்படுத்துகிறார்கள், சிலர் எடையை ஆலோசனையாகக் கருதுகிறார்கள், சிலர் போர்ட்டைப் புறக்கணித்து இயல்புநிலை மதிப்பைக் கருதுகிறார்கள். அந்த வேறுபாடுகள் லேபிளுக்கு அருகில் உங்கள் குறிப்புகளில் இருக்க வேண்டும், ஏனெனில் அவை இல்லாவிட்டால் தீர்வானின் குறைபோல் தெரியும் நடத்தையை விளக்குகின்றன.

கண்டறிதல் என்பது அங்கீகாரம் அல்ல

SRV பதில் எங்கு இணைவது எனக் கூறுகிறது, நீங்கள் சேர்ந்த பிறகு யாரை நம்புவது என்பது பற்றி எதுவும் கூறவில்லை. கிளையண்டின் சான்றிதழ் சரிபார்ப்பையும் சேவையக அடையாளச் சரிபார்ப்புகளையும் இருந்தபடியே வைத்திருங்கள், ஏனெனில் மற்றொருவர் போலியாக்கக்கூடிய பதிவு நம்பிக்கை முடிவாக மாறக்கூடாது. DNS பதில்கள் தற்காலிகமாகச் சேமிக்கப்பட்டு மண்டலத்தைக் கட்டுப்படுத்தும் யாராலும் திருத்தப்படலாம், இது கொள்கையை குறியாக்குவதற்கு மோசமான இடமாக்குகிறது.

கண்டறிதல் ஆதரவு இல்லாத கிளையண்டிற்கு, அது ஏற்கும் சுயவிவரத்தையோ நுழைவாயில் URL-ஐயோ விநியோகிக்கவும், எந்தத் தயாரிப்பு எந்த முறையைப் பயன்படுத்துகிறது எனப் பதிவு செய்யவும். அந்தக் குறிப்பு அடுத்த நிர்வாகி ஒரு பதிவைச் சேர்த்து அது எல்லா இடங்களிலும் வேலை செய்யும் என எதிர்பார்ப்பதைத் தடுக்கிறது. SRV விவரக்குறிப்பு இலக்குகளுக்கிடையேயான தேர்வை விவரிக்கிறது, அதை அனுமதி வழிமுறையாகப் படிப்பதே பயனுள்ள பதிவு பாதுகாப்பு அனுமானமாக மாறும் வழி. வேண்டுமென்றே வெளியிடுங்கள், உங்கள் ஆவணங்களில் லேபிளைப் பெயரிடுங்கள், இவை ஏதேனும் முக்கியமா என முடிவு செய்யும் கூறாகக் கிளையண்டைக் கருதுங்கள்.