VPN மீண்டும் இணைந்த பிறகும் ப்ராக்ஸி பழைய டன்னல் முகவரியிலேயே உள்ளதா?

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

இரண்டாவது தோல்வியே ஆபத்தானது: டன்னல் இயங்குகிறது, பக்கங்கள் ஏற்றப்படுகின்றன, வெளியேறும் முகவரி மட்டுமே தவறானது.

டன்னலில் இருந்து அல்ல, லிசனரில் இருந்து தொடங்குங்கள்

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

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

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

எதையும் திருத்தும் முன் நான்கு சோதனைகள்

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

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

சாதனத்தின் முகவரி எளிது: ip -4 addr show dev tun0 தற்போதையதை அச்சிடுகிறது, ip -4 route get 1.1.1.1 அந்த இலக்குக்கு கர்னல் எந்த இடைமுகத்தைத் தேர்ந்தெடுக்கும் என்பதைக் காட்டுகிறது. சரியான முகவரியில் பிணையும் ஃபார்வர்டர் முகவரி மறையும்போது சத்தமாகத் தோல்வியடையும். சாதனத்தில் பிணையும், அல்லது இயல்புநிலை மூலத்துக்குத் திரும்பும் ஃபார்வர்டர் தொடர்ந்து வேலை செய்து கசியும், அதுவே அமைதியான முடிவு.

ஆவணங்களை நீங்கள் இயக்கும் வெளியீட்டுடன் பொருத்துங்கள், தேடலின் முதல் முடிவுடன் அல்ல. Squid இன் வெளிச்செல்லும் முகவரி உத்தரவு v7 மற்றும் அதற்கு முந்தையவற்றுக்கு ஆவணப்படுத்தப்பட்டுள்ளது, v8 ஆவணங்கள் அந்த உத்தரவு அங்கு இல்லை என்று தெளிவாகக் கூறுகின்றன, எனவே அதைச் சுற்றி கட்டப்பட்ட ஸ்கிரிப்ட் அந்த எல்லையைக் கடக்காது (Squid tcp_outgoing_address குறிப்பு பார்க்கவும்). எதையும் மீண்டும் ஏற்றும் முன் தயாரிப்பின் சொந்த பாகுபடுத்தியுடன் சரிபாருங்கள்: squid -k parse பிழைகளைத் தெரிவித்து இயங்கும் செயல்முறையைத் தொடாமல் வெளியேறுகிறது.

ஒவ்வொரு டன்னலையும் எண்ணிட்டு பழைய மாற்றங்களைத் தூக்கி எறியுங்கள்

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

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

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

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

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

புதிய வெளியேற்றத்தைப் புதிய கோரிக்கையால் நிரூபியுங்கள்

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

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

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

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