HAProxy 302 ஒரு தனியார் பயன்பாட்டுக்கு: இரண்டாவது தாவலை யார் திறக்கிறார்?

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

கட்டமைப்பில் ஒரே மாதிரி தோன்றும் இரு வழிகள்

ஒரு திருப்பிவிடல் பரிமாற்றத்தை ஒரு பதிலுடன் முடிக்கிறது। கிளையண்ட் Location-ஐப் படித்து, தான் இருக்கும் இடத்திலிருந்தே புதிய கோரிக்கையைத் தொடங்குகிறது, அதாவது நீங்கள் ஒருபோதும் கட்டுப்படுத்தாத வலையமைப்பிலிருந்து। ப்ராக்ஸி இனி ஈடுபடாது। அடுத்தடுத்த அனைத்தும் கிளையண்டின் சொந்த DNS, வழி மற்றும் நம்பிக்கையைப் பொறுத்தது, எனவே பயனர் உலாவியை எங்கு திறந்தாரோ அதைப் பொறுத்து முடிவு மாறும்:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

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

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

HAProxy-இன் திருப்பிவிடல் ஆவணம் இந்த எல்லையைச் சரியாக வரைகிறது: கிளையண்டுக்கு ஒரு திருப்பிவிடலுடன் பதிலளிப்பது, கோரிக்கையை ஒரு பின்தளத்துக்கு அனுப்புவதிலிருந்து வேறுபட்ட செயல்। இரு வழிமுறைகளும் ஒரு கட்டமைப்புக் கோப்பில் சில வரிகளுக்கு இடைவெளியில் இருக்கின்றன, ஆனால் முற்றிலும் வேறாக நடந்துகொள்கின்றன। ஒன்று கோரிக்கையை முடிக்கிறது, மற்றொன்று ப்ராக்ஸி சொந்தமாகக் கொண்ட இரண்டாவது கோரிக்கையைத் தொடங்குகிறது।

உலாவிக்குத் தேவையானது, சேவையகத்தின் VPN தராதது

உலாவியின் சொந்தக் கோரிக்கைக்கு இல்லாதிருக்கக்கூடிய நான்கு விஷயங்கள் தேவை: தனியார் பெயருக்கான DNS பதில், அந்த முகவரிக்கான வழி, கேட்கும் சேவையை அடைய அனுமதி, அந்தச் சேவை வழங்கும் சான்றிதழுக்கான நம்பிக்கை। ப்ராக்ஸி புரவலன் தனது சுரங்கப்பாதையின் மூலம் நான்கையும் கொண்டுள்ளது। அவற்றில் எதுவும் அந்தச் சுரங்கப்பாதையில் ஒருபோதும் இல்லாத கிளையண்டுக்கு மாற்றப்படுவதில்லை, ஏனெனில் சுரங்கப்பாதை URL-இன் பண்பு அல்ல, புரவலனின் பண்பு।

இந்த இடைவெளி «கிட்டத்தட்ட வேலை செய்கிறது» என்ற அறிகுறியை விளக்குகிறது। முதல் கோரிக்கை வெற்றி பெறுகிறது, முகவரிப் பட்டி மாறுகிறது, பின்னர் இணைப்பு தொங்குகிறது அல்லது தோல்வியடைகிறது, ப்ராக்ஸி முழு நேரமும் ஆரோக்கியமாகவே இருக்கிறது। ப்ராக்ஸி கட்டமைப்பில் எதுவும் உடைந்திருக்கவில்லை, அதைச் சரிசெய்வது 10.40.0.20 என்ற முகவரிக்கு வழி இல்லாத கிளையண்டுக்கு உதவ முடியாது। ஒன்று கிளையண்ட் ஒரு வழியைப் பெற வேண்டும், இல்லையெனில் ப்ராக்ஸி அதன் சார்பாக இணைப்பை ஏற்படுத்த வேண்டும்।

பயன்பாட்டைப் ப்ராக்ஸி மட்டுமே அடையக்கூடியபோது

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

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

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

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

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

பயன்பாட்டின் சொந்தத் திருப்பிவிடல்கள் இன்னும் உள்ளேயே சுட்டுகின்றன

முதல் கோரிக்கையை அனுப்புவது ஒருங்கிணைப்பின் பாதி மட்டுமே। பயன்பாடு முழுமையான திருப்பிவிடல்கள், கடினமாகக் குறியிடப்பட்ட சொத்து URL-கள் அல்லது உள்ளே தனக்குத் தெரிந்த பெயருக்கு வரம்பிட்ட குக்கிகளை வெளியிடலாம், அவை ஒவ்வொன்றும் உலாவியை அது அடைய முடியாத முகவரிக்குத் திருப்பி அனுப்புகிறது। உள்ளகப் பெயரைச் சுட்டும் Location தலைப்பு அசல் பிரச்சினையைப் போலவே தெரிகிறது, அதனால்தான் அது ப்ராக்ஸி தோல்வி என்று தவறாகக் கண்டறியப்படுகிறது।

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

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

உண்மையில் உங்களிடம் எந்த வடிவமைப்பு உள்ளது என்பதை முடிவு செய்யுங்கள்

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

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

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

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