Port-Share அனைத்து வலைத்தள பார்வையாளர்களையும் localhost போல காட்டுவது ஏன்

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

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

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

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

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

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

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

போக்குவரத்து அனுப்பல் என்பது தலைப்பு செருகல் அல்ல

அனுப்பி பைட்டுகளை நகர்த்துகிறது. அது HTTP ஐப் பகுப்பாய்வு செய்யாது, எனவே ஒருபோதும் கோரிக்கையாகப் படிக்காத கோரிக்கையில் தலைப்பைச் செருக முடியாது, தொடாமல் கடத்தும் TLS ஓட்டத்தில் எதையும் சேர்க்க முடியாது. ப்ராக்ஸி தலைப்பை எதிர்பார்க்கும் தொகுதி, எந்தப் பகுதியும் உருவாக்காத ஒன்றுக்காகக் காத்திருக்கும்.

மூல முகவரியை இரு வழிமுறைகள் சுமக்க முடியும், இரண்டிற்கும் இரு முனைகளிலும் ஒப்புதல் தேவை. PROXY நெறிமுறை இணைப்பின் தொடக்கத்தில் சிறிய தலைப்பைச் சேர்க்கிறது, பின்தளம் அதை எதிர்பார்க்கும் வகையில் அமைக்கப்பட வேண்டும்; எதிர்பார்க்காத பின்தளம் அந்த பைட்டுகளைக் கோரிக்கையின் தொடக்கமாகக் கருதி குழப்பமான முறையில் தோல்வியடையும். X-Forwarded-For போன்ற நம்பகமான ப்ராக்ஸி தலைப்புகள், HTTP ஐப் புரிந்துகொள்ளும் ப்ராக்ஸி அவற்றை அமைக்கும்போதும், எந்த இணைகள் அவற்றை உறுதிப்படுத்தலாம் என்று பின்தளத்திற்குச் சொல்லும்போதும் செயல்படும்.

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

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

விருப்ப மூல-வரைபட அடைவு

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

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

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

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

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

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

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

பக்கத்தை அல்ல, விதியைச் சோதியுங்கள்

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

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

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

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