நுழைவாயில் தனது சொந்த நிர்வாகப் பக்கத்தை வழங்குகிறது: உள் அல்லது பொது முகவரி

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

பக்கம் சுரங்கம் வழியாக அல்ல, வெளியிலிருந்து ஏற்றப்படுகிறது

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

இலக்குப் பாதை ஒரு முகவரியைத் தேர்ந்தெடுக்கிறது, துறைமுகத்தை அல்ல. வழிப்பாதை அட்டவணையில் துறைமுகம் 443 நிர்வாகத்திற்கும் துறைமுகம் 1194 போக்குவரத்திற்கும் என்பது எதற்கும் தெரியாது, எனவே இரண்டும் ஒரே இலக்காகக் கருதப்படுகின்றன.

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

வெளிப்புற முனையை அடையக்கூடியதாக வைத்திருங்கள்

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

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

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

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

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

சேவைக்கு தனிப்பட்ட பெயரைக் கொடுங்கள்

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

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

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

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

செயல்முறை இயங்கும் இடத்திற்கு கொள்கையைப் பொருத்துங்கள்

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

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

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

தனிப்பட்ட அணுகலையும் மறுக்கப்பட்ட பொது பாதையையும் சரிபார்க்கவும்

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

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

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

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