உங்கள் LAN ஒரு VPN கிளையன்ட்டில் உள்ள சேவையை ஏன் அடைய முடியவில்லை

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

உடைந்தது சுரங்கப்பாதை அல்ல

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

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

வழியின் வடிவம்: குளம் எங்கே என்று LAN-க்குச் சொல்லுங்கள்

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

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

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

push "route 192.168.1.0 255.255.255.0"

சேவையகத்திற்குப் பின்னால் அல்ல, ஒரு கிளையன்ட்டுக்குப் பின்னால் உள்ள துணை வலையமைப்புக்கு, சேவையகத்திற்கு கணினி வழியும், அந்த கிளையன்ட்டின் கோப்பில் iroute உள்ளீடும் (client-config-dir கீழ்) தேவை. iroute இல்லாமல், OpenVPN-க்கு முன்னொட்டு உள்ளது என்று தெரியும், எந்த கிளையன்ட் அதைச் சொந்தமாக்குகிறது என்று தெரியாது: பாக்கெட்டுகள் வருகின்றன, டீமானிடம் அவற்றைப் பொருத்துவதற்கு எதுவும் இல்லை.

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

NAT-இன் வடிவம்: உள்ளே DNAT, மற்றும் அனைவரும் தவிர்க்கும் SNAT வரி

LAN கேட்வேயைத் தொட முடியாதபோது, அல்லது சரியாக ஒரு போர்ட்டை வெளியிட விரும்பும்போது, VPN ஹோஸ்ட்டில் மொழிபெயர்ப்பு LAN-இல் எந்த வழியும் இல்லாமல் வேலை செய்கிறது. போர்ட்டை வெளியிடுங்கள், ஃபார்வேர்ட் செய்யுங்கள், சுரங்கப்பாதைக்குள் செல்லும் வழியில் மூலத்தை மொழிபெயர்க்கவும்:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

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

நுகர்வோர் ஃபார்ம்வேர்ஸ் தன் சொந்த சங்கிலிப் பெயர்களைப் பயன்படுத்துகிறது, அந்த மொழிபெயர்ப்பை உங்களுக்காக உருவாக்குவதில்லை. Tomato-வில், உள்வரும் விதி WANPREROUTING-இல் விழுகிறது, பின்னர் wanin போன்ற வடிகட்டி சங்கிலியில், முழுமையாகத் தெரியும் விதித் தொகுப்புக்கும் கைமுறை POSTROUTING வரி தேவை. அது ஃபார்ம்வேர் பிழை அல்ல; அது உள்வரும் போக்குவரத்துக்கு மட்டும் எழுதப்பட்ட விதித் தொகுப்பு.

சரியாகத் தெரியும் விதி பாக்கெட்டை ஏன் இன்னும் வீழ்த்துகிறது

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

• சங்கிலி வரிசை. iptables -I மேலே செருகுகிறது, -A முடிவில் சேர்க்கிறது, எனவே முந்தைய அனுமதிக்கும் அல்லது தடுக்கும் விதியே முதலில் முடிவு செய்கிறது.
• தவறான சங்கிலி. ரவுட்டரையே இலக்காகக் கொண்ட போக்குவரத்து INPUT-ஐக் கடக்கிறது, ஃபார்வேர்ட் செய்யப்பட்ட போக்குவரத்து அதை ஒருபோதும் தொடுவதில்லை. ஒரு சேவையை வெளியிட இரண்டிலும் விதிகள் தேவைப்படலாம்.
• திசைக் கொடிகள். -i tun0 கிளையன்ட்களிடமிருந்து வரும் போக்குவரத்துடன் பொருந்துகிறது, -o tun0 அவர்களை நோக்கிச் செல்லும் போக்குவரத்துடன். தவறான கொடியுடன் REJECT நீங்கள் நினைக்காத ஒன்றைத் தடுக்கிறது.
• மூலக் கட்டுப்பாடு. ஒரு கிளையன்ட் முகவரியை ஏற்கும் ஃபார்வேர்டிங் அந்தக் கிளையன்ட்டிலிருந்து வேலை செய்கிறது, மற்ற ஒவ்வொரு மூலத்தையும் ஒரு வார்த்தைகூட சொல்லாமல் வீழ்த்துகிறது.

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

LAN-இல் எதையும் மாற்ற முடியாதபோது உள்ளூர் ஃபார்வேர்டிங்

SSH உள்ளூர் ஃபார்வேர்டிங் முழு கேள்வியையும் தவிர்க்கிறது. அதற்கு LAN-இல் வழியோ, கிளையன்ட்டின் ஃபயர்வால் ஒத்துழைப்போ, எங்காவது வெளியிடப்பட்ட போர்ட்டோ தேவையில்லை:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

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

மற்றொரு விதியைச் சேர்ப்பதற்கு முன் இரு திசைகளையும் சரிபார்க்கவும்

மொழிபெயர்ப்பு தடயங்களை விட்டுச் செல்கிறது, அவற்றைப் படிப்பது ஊகிப்பதை விட மேல். VPN ஹோஸ்ட்டில், conntrack -L மொழிபெயர்ப்பு நடந்ததா என்பதைக் காட்டுகிறது, iptables -t nat -L -n -v கவுண்டர்கள் நகர்ந்ததா என்பதைக் காட்டுகிறது, tcpdump -ni any port 3000 எந்த மூல முகவரி உண்மையில் வந்தது என்பதைக் காட்டுகிறது. கிளையன்ட்டில், ss -ltn கேட்பவர் சுரங்கப்பாதை அடையக்கூடிய முகவரியில் இருப்பதை உறுதிசெய்கிறது.

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