OpenVPN மற்றும் HTTPS துறைமுகம் 443 இல்: கேட்பவர் யாருடையது?
TCP மற்றும் UDP 443 தனித்தனி சாக்கெட்டுகள். ஒரு TCP கேட்பவரைப் பங்கிட ஒரு உரிமையாளர் தேவை, OpenVPN இன் துறைமுகப் பங்கீடு ஒரு குறுகிய ஒப்பந்தம், ப்ராக்ஸி தந்திரம் அல்ல.
இரு சேவைகளும் ஒருபோதும் போட்டியிடாமல் 443 துறைமுகத்தில் பதிலளிக்க முடியும், ஏனெனில் கேட்பவர் எண்ணால் மட்டுமல்ல, போக்குவரத்து, முகவரி மற்றும் துறைமுகம் ஆகியவை சேர்ந்து தீர்மானிக்கப்படுகிறது. ஒரே இயந்திரத்தில் வலைச் சேவையகமும் OpenVPN-உம் வைக்கவும், முதலில் பதிலளிக்கத் தகுந்த ஒரே கேள்வி ஒவ்வொரு செயல்முறையும் கர்னலிடம் எந்த சாக்கெட்டைக் கேட்கிறது என்பதே. உள்ளமைவைத் திருத்தும் முன் அந்தப் பட்டியலை எழுதுங்கள், «முகவரி ஏற்கனவே பயன்பாட்டில் உள்ளது» பிழைகளில் பெரும்பாலானவை தாமாகவே விளங்கும். பட்டியலுக்குப் பிறகு எல்லாம் UDP கேட்பவர், பங்கிடப்பட்ட TCP சாக்கெட் அல்லது நெறிமுறையின்படி வழிநடத்தும் முன்முனை ஆகியவற்றுக்கிடையேயான தேர்வே.
ஒவ்வொரு செயல்முறையும் கேட்கும் சாக்கெட்டிலிருந்து தொடங்குங்கள்
bind அந்த மும்மையின் அடிப்படையில் வெற்றி பெறுகிறது அல்லது தோல்வியடைகிறது, எனவே மூன்று பகுதிகளும் ஒத்துப்போகும்போது மட்டுமே இரு டீமன்கள் மோதுகின்றன. அதனால்தான் TCP 443 இல் ஒரு வலைத்தளம் UDP 443 இல் OpenVPN கேட்பவருடன் வரம்பற்ற காலம் இணைந்து வாழ்கிறது, அதனால்தான் அவற்றில் ஒன்றை அதே புரவலனின் இரண்டாவது உள்ளூர் முகவரிக்கு நகர்த்துவதும் விவாதத்தை முடிக்கிறது. உயிருள்ள கேட்பவர்களைப் படியுங்கள், அவற்றை உருவாக்கியிருக்க வேண்டிய கோப்புகளை அல்ல, ஏனெனில் பழைய include அல்லது மறந்துபோன unit கோப்பு நீங்கள் நினைவுகூரும் திருத்தத்தைவிட நீண்ட காலம் நிலைக்கும்.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
root ஆக ss -lntup இயக்கி 443 குறிப்பிடும் ஒவ்வொரு வரியையும், IPv6 உள்ளீடுகள் உட்படப் படியுங்கள். பொதுவாக வைல்டுகார்டு v6 கேட்பவர் v4 போக்குவரத்தையும் ஏற்கும், அதனால் மறந்துபோன கேட்பவர் நீங்கள் பொறுப்பாகக் கருதிய கோப்பை மாற்றிய பிறகும் துறைமுகத்தை ஆக்கிரமித்திருக்கும். செயல்முறையின் பெயர் உங்களை ஆச்சரியப்படுத்தினால், எதையும் தொடுவதற்கு முன் ss -lntup 'sport = :443' மூலம் வெளியீட்டைக் குறைக்கவும்.
வலையமைப்பு அனுமதிக்கும்போது சுரங்கத்தை UDP-க்கு மாற்றுங்கள்
UDP கேட்பவர் மோதலை முழுமையாகத் தவிர்க்கிறது, பொதுவாக இதுவே மிகக் குறுகிய பழுது, ஏனெனில் எந்த சாக்கெட்டும் பங்கிடப்படுவதில்லை, பாதையில் கூடுதல் தயாரிப்பும் நுழைவதில்லை. ஆனால் இது இலவசம் அல்ல. சில வாடிக்கையாளர் வலையமைப்புகள் reset அனுப்பாமல் UDP 443-ஐ விட்டுவிடுகின்றன, எனவே சுரங்கம் bind இல் தோல்வியடைவதற்குப் பதிலாக நிறுவப்படுவதை நிறுத்துகிறது, பயனர் படிக்க எந்தப் பிழையும் இல்லாமல் VPN நின்றுவிட்டதாகத் தெரிவிக்கிறார். UDP கேட்பவர் வலை அடுக்கின் மறுதொடக்கத்தையும் தாங்கும், இது தளம் அடிக்கடி மீண்டும் பயன்படுத்தப்படும் இயந்திரத்தில் முக்கியம். பயனர்கள் அமர்ந்திருக்கும் வலையமைப்பிலிருந்து சோதியுங்கள், ஏனெனில் சேவையகத்தில் உள்ள shell சேவையகம் தன்னை அடைவதை மட்டுமே நிரூபிக்கிறது.
சேவையக உள்ளமைவிலும் வாடிக்கையாளர் சுயவிவரத்திலும் போக்குவரத்தை ஒன்றாக மாற்றுங்கள். இன்னும் TCP கேட்கும் சுயவிவரம் UDP மட்டும் உள்ள கேட்பவருக்கு எதிராக மறுஇணைப்பு சுழற்சிகளில் சுழலும், இரண்டு கோப்புகளையும் ஒப்பிடும் வரை அது வலையமைப்புக் கோளாறு போலத் தோன்றும்.
VPN செயல்முறைக்கு TCP 443 உரிமையை விடுங்கள், மீதியை முன்னே அனுப்புங்கள்
TCP சேவையகப் பயன்முறையில் Community OpenVPN வரும் இணைப்பின் முதல் பைட்டுகளைப் படித்து, தன் சொந்த நெறிமுறை அல்லாத எல்லாவற்றையும் HTTPS பின்தளத்திற்கு அனுப்புகிறது, port-share வழிமுறை அதற்கே. பின்தளம் TLS இயக்கப்பட்ட சாதாரண வலைச் சேவையகம், அந்த வழிமுறையில் அது URL-ஆல் அல்ல, புரவலன் மற்றும் துறைமுகத்தால் பெயரிடப்படுகிறது.
port-share 10.0.0.5 8080
தளம் இரண்டாவது தனிப்பட்ட முகவரியைக் கொண்ட இயந்திரத்தில், அந்த வரி VPN அல்லாத போக்குவரத்தை 10.0.0.5:8080-க்கு அனுப்புகிறது, எனவே HTTPS மெய்நிகர் புரவலன் அங்கே பிணைக்கப்பட்டிருக்க வேண்டும், தீச்சுவர் உள்ளூர் தாவலை அனுமதிக்க வேண்டும். வலைச் சேவையகம் TLS-ஐ தானே முடிக்க வேண்டும், ஏனெனில் வரும் பைட்டுகள் உலாவியின் அசல் கைக்குலுக்கல், இடையில் எதுவும் அவற்றை மறைகுறியாக்கவில்லை. வழிமுறையை சாதாரண HTTP கேட்பவரை நோக்கித் திருப்புங்கள், உலாவிக்கு செல்லாத முறை பிழை கிடைக்கும், அது பின்தளம் தவறான இடத்தில் இருப்பதைப் போலல்ல, உடைந்த தளம் போலப் படிக்கப்படும். வழிமுறை TCP சேவையகப் பயன்முறையில் மட்டுமே உள்ளது, UDP கேட்பவருக்கு ஆய்வு செய்ய ஓட்டம் இல்லை.
VPN செயல்முறை ஒவ்வொரு இணைப்பையும் ஏற்பதால், வலைப் பயன்பாடு அனுப்பப்பட்ட கோரிக்கை பார்வையாளரிடமிருந்து அல்ல, புரவலனின் சொந்த முகவரிகளில் ஒன்றிலிருந்து வருவதைக் காண்கிறது. உண்மையான வாடிக்கையாளர் முகவரி தேவைப்படும் எல்லாம் பின்தளத்தில் PROXY நெறிமுறை ஆதரவு அல்லது அதைச் சேர்க்கும் முன்முனையைச் சார்ந்துள்ளது. பின்தளத்தை வேறு உள்ளூர் முகவரிக்கு நகர்த்துவது பார்வையாளரின் முகவரியைத் திரும்பக் கொண்டுவராது; தளம் புரவலனின் எந்த முகவரிகளைப் பதிவு செய்கிறது என்பதை மட்டும் மாற்றும். பகுப்பாய்வு அறிக்கை கேள்வியை எழுப்பும் முன் இந்த வரம்பைப் பயன்படுத்தல் குறிப்புகளில் எழுதுங்கள்.
தலைகீழ் ப்ராக்ஸி தவறான கருவி; அடுக்கு-நான்கு வழியமைப்பான் அல்ல
HTTP தலைகீழ் ப்ராக்ஸி கோரிக்கைகளைப் படிக்க TLS-ஐ முடிக்கிறது, அதாவது OpenVPN ஓட்டத்தைத் தொடாமல் கடக்க விட முடியாது. SNI அல்லது முதல் பொதியின் ஆய்வின்படி அனுப்பும் அடுக்கு-நான்கு வழியமைப்பான் VPN சார்ந்திருக்கும் அமர்வை முடிக்காத வரை இரண்டிற்கும் முன்னால் நிற்க முடியும். இரு சாதனங்களும் வரைபடத்தில் ஒரே மாதிரி தோன்றும், சாக்கெட்டில் முற்றிலும் வேறுவிதமாக நடந்துகொள்ளும்.
வணிக Access Server தன் சொந்தத் துறைமுகப் பங்கீட்டு அமைப்புகளுடன் வருகிறது, அவை சமூக வழிமுறையுடன் ஒன்றுக்கு ஒன்றாகப் பொருந்துவதில்லை. மற்றொன்றுக்கு எழுதப்பட்ட வழிகாட்டியைத் தழுவும் முன் தயாரிப்பையும் பதிப்பையும் அடையாளம் காணுங்கள். அமைதியாகப் புறக்கணிக்கப்படும் நகலெடுத்த அமைப்பு அமைப்பே இல்லாததைவிட மோசம், ஏனெனில் அதன் பிறகும் கேட்பவர்கள் பட்டியல் நம்பத்தகுந்ததாகவே தோன்றும்.
வலைத்தளத்தையும் சுரங்கத்தையும் இரு தனித்தனி பாதைகளாகச் சோதியுங்கள்
தளத்தை ஏற்றி சுரங்கத்தை இணைக்கவும், பிறகு 443 இப்போது எந்தச் செயல்முறையின் உரிமையில் உள்ளது எனப் பார்க்க கேட்பவர்கள் பட்டியலை மீண்டும் படியுங்கள். ஏற்றப்படும் பக்கம் VPN பற்றி எதையும் நிரூபிக்காது, இணையும் சுரங்கம் தளம் பற்றி எதையும் நிரூபிக்காது, இரண்டும் ஒரே எண்ணைப் பயன்படுத்தினாலும். கீழே உள்ள மூன்று கட்டளைகள் பங்கிடப்பட்ட சாக்கெட், வலைப் பாதை மற்றும் VPN சேவையை அந்த வரிசையில் சோதிக்கின்றன.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
அதே தருணத்திற்கான பின்தள அணுகல் பதிவில் உள்ள வாடிக்கையாளர் முகவரியை VPN பதிவில் உள்ளதுடன் ஒப்பிடுங்கள். தளம் ஒவ்வொரு பார்வையாளரையும் புரவலனாகவே பதிவு செய்தால் அனுப்புதல் வேலை செய்கிறது, முகவரி கையாளுதல் வேலை செய்யவில்லை. இரு பதிவுகளும் அமைதியாக இருந்தால், முன்முனை ஒருபோதும் இணைப்பை ஒப்படைக்கவில்லை. எப்படியிருந்தாலும், சாக்கெட்டை யார் ஏற்கிறார்கள் என்பதைக் கேட்பவர்கள் பட்டியல் தீர்மானிக்கிறது, மற்றொரு கோப்பை மாற்றும் முன் உறுதிப்படுத்த வேண்டிய உண்மை அதுவே.
அந்தக் கேட்பவர் வரைபடத்தை உள்ளமைவுக்கு அருகில் விடுங்கள், அடுத்து 443-ஐத் தொடும் நபர் எந்தச் செயல்முறை ஏற்கிறது, மற்ற நெறிமுறை எங்கே சென்றது என்பதை அறியட்டும். திருத்தம் என்ன செய்யவிருந்தது என்பதை நம்புவதற்குப் பதிலாக மாற்றத்திற்குப் பிறகு உரிமையை உறுதிப்படுத்துங்கள்.