VPN முனைப் புள்ளி பெயர் மற்றும் தனிப்பட்ட சேவைப் பெயர்: இரண்டு உரிமையாளர்கள்

இரண்டு பெயர்கள் ஒரே கிளையை விவரித்து முற்றிலும் வேறுபட்ட கேள்விகளுக்குப் பதிலளிக்க முடியும். vpn.branch.example தொலை சகாவுக்கு VPN முனைப் புள்ளி எங்கே கிடைக்கும் என்பதைச் சொல்கிறது, மேலும் எந்தச் சுரங்கப்பாதையும் உருவாகும் முன் அது தீர்க்கப்பட வேண்டும். inventory.branch.example அதிகாரம் பெற்ற பயனருக்கு தனிப்பட்ட பயன்பாடு எங்கே உள்ளது என்பதைச் சொல்கிறது, சுரங்கப்பாதை உயர்ந்த பிறகே அதற்கு முக்கியத்துவம் உண்டு. ஒன்றைப் பராமரிப்பது மற்றொன்றுக்கு எதையும் செய்யாது.

எதையும் பிழைத்திருத்தம் செய்யும் முன் இரண்டு பதிவுகளுக்கும் பெயரிடுங்கள்

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

இந்தச் சிறிய பட்டியல் இத்துறையில் மிகவும் பொதுவான தவறான நோயறிதலைத் தடுக்கிறது: முழுவதுமாக அதன் உள்ளேயே வாழும் பதிவைச் சரிசெய்ய, வேலை செய்யும் கிளைச் சுரங்கப்பாதையை மறுதொடக்கம் செய்வது. சுரங்கப்பாதை சேவைப் பெயருக்கான போக்குவரத்து; அது அதன் அதிகாரம் அல்ல.

மாற்றம் பரிந்துரைக்கப்படும்போது, அது இரண்டு பதிவுகளில் எதைத் தொடுகிறது என்று கேளுங்கள். யாரும் பதிலளிக்க முடியாவிட்டால், மாற்றம் திட்டமிடத் தயாராக இல்லை.

எந்தச் சுரங்கப்பாதையும் உருவாகும் முன் முனைப் புள்ளி தீர்க்கப்பட வேண்டும்

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

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

மாறும் DNSக்கும் பதிவு புதுப்பிப்பு கடக்க முடியாத எல்லைகள் உண்டு. பதிவைப் புதுப்பிப்பது எந்த ஃபயர்வால் துறையையும் திறக்காது, NAT வரைபடத்தை உருவாக்காது, சகாவின் அடையாளத்தை நிரூபிக்காது. மூடிய துறையுடன் வெளியிடப்பட்ட முகவரி சரியாகத் தீர்க்கும், இருந்தும் எதனுடனும் இணைக்க முடியாத வாடிக்கையாளரைத் தருகிறது.

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

சேவைப் பெயர் பயன்பாடு எங்கே உள்ளது என்பதை விவரிக்கிறது

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

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

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

இரண்டு பாதைகளையும் தனித்தனியாகச் சோதிக்கவும்

சுரங்கப்பாதையின் வெளியிலிருந்து முனைப் புள்ளியையும் உள்ளிருந்து சேவையையும் சரிபார்த்து, முடிவுகளை இரண்டு சுயாதீன உண்மைகளாக வைத்திருங்கள்:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

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

ஒவ்வொரு முகவரி மாற்றத்திற்குப் பிறகும் இணையை இயக்கி, எந்தப் பதிவு நகர்ந்தது என்பதைக் குறிப்பிடுங்கள். «DNS புதுப்பிக்கப்பட்டது» என்று மட்டும் சொல்லும் ஒப்படைப்பு, இரண்டு வாழ்க்கைச் சுழற்சிகளில் எது உண்மையில் இயங்கியது என்று அடுத்த பொறியாளரை ஊகிக்க விடுகிறது.