OpenVPN கிளையண்ட் சேவையகத்தை அடைகிறது ஆனால் LAN புரவலர்களை அடையவில்லை: சரிபார்ப்புப் பட்டியல்

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

முதல் படி: கிளையண்டின் வழியமைப்பு முடிவைக் கவனிக்கவும்

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

ip route get 192.168.50.10

பதில் உங்கள் இயற்பியல் அடாப்டர் மற்றும் அலுவலக நுழைவாயிலைக் குறிப்பிட்டால், சேவையகப் பக்கத்தில் எந்த மாற்றமும் உதவாது. OpenVPN சேவையகம் தள்ளும்போது மட்டுமே வழிகளை வழங்கும், எனவே சேவையக உள்ளமைவில் push "route 192.168.50.0 255.255.255.0" தேடி, பின்னர் கிளையண்டை மீண்டும் இணைக்கவும். பெரும்பாலான கிளையண்ட்கள் தள்ளப்பட்ட வழிகளை இணைக்கும் நேரத்தில் பயன்படுத்துகின்றன, சுயவிவரத்தை மீண்டும் ஏற்றும்போது அல்ல.

Windows-இல் அதே கேள்விக்கு வேறு கட்டளை உள்ளது. Find-NetRoute -RemoteIPAddress 192.168.50.10 அடுக்கு தேர்ந்தெடுக்கும் இடைமுகத்தையும் அடுத்த தாவலையும் அச்சிடுகிறது, route print -4 தள்ளப்பட்ட முன்னொட்டு உள்ளதா இல்லையா என்பதைக் காட்டுகிறது.

இரண்டாம் படி: சேவையகம் பாக்கெட்டை முன்னனுப்பும் என்பதை உறுதிசெய்யவும்

கிளையண்ட் வழி சரியாக இருந்தால், பாக்கெட் சேவையகத்தை அடைகிறது, சேவையகம் அதை முன்னனுப்ப ஒப்புக்கொள்ள வேண்டும். கர்னல் சுவிட்ச் முதல் வாயில், sysctl net.ipv4.ip_forward 1-ஐத் திருப்பித் தர வேண்டும். echo 1 > /proc/sys/net/ipv4/ip_forward மூலம் அதை அமைப்பது அடுத்த மறுதொடக்கம் வரை வேலை செய்யும், அதனால்தான் அதே புகார் வாரங்கள் கழித்துத் திரும்பி வருகிறது.

மறுதொடக்கத்தைத் தாண்டி நிலைத்திருக்கும் இடத்தில் அதை எழுதுங்கள்:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

இரண்டாவது வாயில் வடிகட்டி அட்டவணை. Docker நிறுவப்பட்ட புரவலரில் பெரும்பாலும் FORWARD கொள்கை DROP ஆக இருக்கும், சுரங்கப்பாதை அந்த முடிவை மரபுரிமையாகப் பெறுகிறது. iptables -L FORWARD -v -n கொள்கையையும் பாக்கெட் கணக்குகளையும் காட்டுகிறது; கொள்கை DROP ஆக இருந்தால், முன்னனுப்பலுக்கு சுரங்கப்பாதையிலிருந்து LAN நோக்கிய திசைக்கு ஒரு வெளிப்படையான அனுமதியும், பதிலுக்கு மற்றொன்றும் தேவை.

மூன்றாம் படி: பாக்கெட்டை LAN வரை பின்தொடர்ந்து பதிலைத் தேடுங்கள்

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

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

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

நான்காம் படி: மொழிபெயர்ப்புக்கும் திரும்பும் வழிக்கும் இடையே தேர்ந்தெடுக்கவும்

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

விதியைக் குளம் மற்றும் LAN இடைமுகத்திற்கு வரம்பிடுங்கள், பின்னர் அதை நிரந்தரமாக்குங்கள், இல்லையெனில் அடுத்த ஃபயர்வால் மீளேற்றம் உங்கள் திருத்தத்தை அமைதியாக அகற்றும். விலை அடையாளம்: LAN பதிவுகளிலும் அணுகல் விதிகளிலும் ஒவ்வொரு கிளையண்டும் VPN சேவையகம் போலத் தெரிகிறது, மேலும் per-client policy becomes guesswork.

LAN திசைவியில் VPN சேவையகத்தை நோக்கிய 10.8.0.0/24-க்கான நிலையான வழி, கிளையண்ட் முகவரிகளைத் தெரியும்படி வைத்திருக்கும், அந்தத் திசைவி உங்களுடையதாக இருந்தால் இதுவே சிறந்த நீண்டகால பதில். பல தளங்கள் சிறிது காலம் இரண்டையும் இயக்குகின்றன, உடனடித் திருத்தத்திற்கு NAT, ஃபயர்வால் கொள்கை எழுதப்பட்ட பிறகு வழி. சேவையகம் குளம் அல்லாமல் தளம்-க்கு-தளம் சக எனில், சேவையகப் பக்கமும் தொலை சப்நெட்டுக்கு iroute தேவை, இல்லையெனில் சக வழி உள்ளது ஆனால் கிளையண்ட் போக்குவரத்து அதனுடன் ஒருபோதும் இணைக்கப்படுவதில்லை.

ஐந்தாம் படி: கிளையண்டிலிருந்து சரிபார்த்து என்ன மாறியது என்பதைப் பதிவு செய்யுங்கள்

சுழற்சியை சேவையகத்திலிருந்து அல்ல, கிளையண்டிலிருந்து மூடுங்கள். LAN புரவலரில் உண்மையான சேவையுடன் இணைந்து, பின்னர் iptables -t nat -L POSTROUTING -v -n மூலம் மொழிபெயர்ப்பு கணக்குகள் நகர்ந்ததை உறுதிசெய்யுங்கள், ஏனெனில் பூஜ்ஜிய பாக்கெட்டுகள் கொண்ட விதி ஒருபோதும் பொருந்தாத விதி. திரும்பும் திசை கண்காணிக்கப்படுகிறது என்பதற்கான சான்று தேவைப்படும்போது conntrack -L -s 10.8.0.5 ஓட்டத்தையும் அதன் நிலையையும் காட்டுகிறது.

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