Squid வழியாக ஒரு VPN முடிவுப்புள்ளி: குறுகிய CONNECT விலக்கு

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

Squid ஒரு CONNECT கோரிக்கையை எவ்வாறு தீர்மானிக்கிறது

CONNECT கோரிக்கை ஒரு ஹோஸ்ட் மற்றும் போர்ட்டைக் குறிப்பிடுகிறது, Squid http_access வரிகளை வரிசையாகக் கடந்து அவற்றில் ஒன்று பொருந்தும் வரை செல்கிறது. பொருந்தும் மறுப்பு மதிப்பீட்டை உடனடியாக முடிக்கிறது, வாடிக்கையாளர் ப்ராக்ஸியிலிருந்து 403 பெறுகிறார். அதனால்தான் ஒரு விதியின் நிலை அதன் வார்த்தைகளை விட முக்கியம். அதே வரியை ஒரு படி மேலே நகர்த்துவது முடிவை முற்றிலும் மாற்றலாம்.

வழக்கமான காவலர்கள் Safe_ports க்கு வெளியே உள்ள அனைத்தையும் மறுக்கின்றன, SSL_ports க்கு வெளியே CONNECT ஐ மறுக்கின்றன. அந்தப் பெயர்கள் உங்கள் சொந்த உள்ளமைவில் வரையறுக்கப்பட்ட ACL கள், எனவே அவற்றின் உள்ளடக்கம் நெறிமுறைக்கு அல்ல, உங்களுக்குச் சொந்தம். ஒரு விநியோகம் Safe_ports ஆக பரந்த போர்ட் வரம்பை அனுமதித்து CONNECT ஐ தனித்தனியாக கட்டுப்படுத்தலாம். ஒரு போர்ட் வடிவமைப்பால் தடுக்கப்பட்டுள்ளது என்று கருதும் முன் நேரடி மதிப்புகளைப் படியுங்கள்.

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

மூன்று தனித்தனி ACL களுக்குப் பதிலாக ஒரு ஒருங்கிணைந்த பொருத்தத்தை உருவாக்குங்கள்

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

கீழே உள்ள வடிவம் மதிப்பாய்வு செய்யப்பட்ட மதிப்புகளால் மாற்றப்பட வேண்டிய ஆவண வரம்புகளைப் பயன்படுத்துகிறது. Squid இந்தப் பெயர்களில் எதையும் தனக்காக ஒதுக்கவில்லை, எனவே அவற்றைத் தேர்ந்தெடுப்பதும் சீராக வைத்திருப்பதும் உங்கள் வேலை. இந்த செய்முறை all-of குழுவை ஆதரிக்கும் ஆவணப்படுத்தப்பட்ட உள்ளமைவைக் கொண்ட Squid 6 மற்றும் 7 க்கு மட்டுமே. தற்போதைய குறிப்பு அந்த வழிமுறைகளை Squid 8 இல் கிடைக்காதவை எனக் குறிக்கிறது, எனவே இதை இடமாற்றப் பாதையாக அல்ல, பதிப்பு-கட்டுப்பட்ட செய்முறையாகக் கருதுங்கள், பயன்படுத்தும் முன் உங்கள் சொந்த பதிப்பின் குறிப்பில் வழிமுறையைச் சரிபார்க்கவும்.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

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

போர்ட் காவலர்களை அகற்றாமல் வளைக்கவும்

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

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

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

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

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

விலக்கை எங்கு வைக்கக் கூடாது

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

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

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

பாகுபடுத்தி மற்றும் உண்மையான கோரிக்கையுடன் எல்லையைச் சரிபார்க்கவும்

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

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

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

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