சாக்கெட் பியர் அல்லது அனுப்பப்பட்ட தலைப்பு: எந்த முகவரியை நம்புவது?

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

எதையும் ஒப்பிடும் முன் பாதையை விவரிக்கவும்:

Client -> approved reverse proxy -> application origin

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

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

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

அனுப்பும் புலம் என்பது ஒரு சங்கிலி பற்றிய மெட்டாடேட்டா. X-Forwarded-For, X-Real-IP மற்றும் தரப்படுத்தப்பட்ட புலம் Forwarded அவற்றை எதிரொலிக்கும் இறுதிப் புள்ளியை அடையும் எந்த கிளையண்டும் எழுதலாம், எனவே அவற்றின் நம்பகத்தன்மை அவற்றை அமைக்க யாருக்கு அனுமதி இருந்தது என்பதை முழுமையாகச் சார்ந்துள்ளது.

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

தலைப்பு ஒருபோதும் இணைப்பை மறுவழிப்படுத்தாது

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

எதிர்மறை தவறும் அதே அளவு பொதுவானது: HTTPS கிளையண்ட் வழங்கிய அனுப்பும் தலைப்பை உண்மையாக்காது. பொய்யான கூற்றின் போக்குவரத்தை உண்மையானதைப் போலவே பாதுகாக்கிறது.

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

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

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

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

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

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

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

பல-தட சங்கிலிகளை வேண்டுமென்றே கையாளுங்கள்

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

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

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

இரண்டு அவதானிப்புகளையும் பதிவில் வைத்திருங்கள்

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

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