தொலை பயனர்கள் VPN ஹப் வழியாக இரண்டாவது தளத்தை அடையவில்லை

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

செல்வதற்கு மூன்று தேடல்கள் தேவை, ஒரு சுரங்கப்பாதை அல்ல

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

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

தொலை முன்னொட்டைத் தொலைக் கிளையண்டிற்குத் தள்ளுங்கள்

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

push "route 10.20.0.0 255.255.255.0"

தள்ளப்பட்ட பாதை கிளையண்ட் இணைக்கும்போது நடைமுறைக்கு வருகிறது, எனவே ஆன்லைனில் இருக்கும் பயனர் மீண்டும் இணையும் வரை எதையும் காண்பதில்லை. கிளையண்டில் சரிபார்க்கவும்: Linux-இல் ip route get 10.20.0.50, Windows-இல் route print. வெளியீடு சுரங்கப்பாதை இடைமுகத்தைப் பெயரிட வேண்டும்.

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

ஹப்பிற்கு உண்மையான வெளியேற்றப் பாதையைக் கொடுங்கள்

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

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

தளம்-க்கு-தளம் பகுதி தானே OpenVPN ஆக இருந்தால், பாதை அதே உள்ளமைவில் கூட்டாளியின் சுரங்கப்பாதை முகவரியை நுழைவாயிலாகக் கொண்டு வாழலாம்: route 10.20.0.0 255.255.255.0 172.30.0.2. நுழைவாயில் விருப்பமானது அல்ல. அதை விட்டுவிட்டால் அடுத்த ஹாப் செயலாக்கத்தின் இயல்புநிலைக்குச் செல்லும், அது ஒற்றை-தொலை கிளையண்டிற்கும் பல-கூட்டாளி ஹப்பிற்கும் இடையே வேறுபடும்.

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

தொலைப் பக்கத்தைப் பயனர் குளம் வரை நீட்டுங்கள்

தலைமை அலுவலகம் ஏற்கனவே ஹப்பின் LAN, 10.10.0.0/24-ஐ உள்ளடக்கியது. பயனர் குளம் இரண்டாவது முன்னொட்டு, அது தேர்விகளிலும் இருக்க வேண்டும், இல்லையேல் 10.80.0.25-க்கு அனுப்பப்படும் பதிலை எந்தக் கொள்கையும் உள்ளடக்காது. ஒவ்வொரு கூட்டாளியும் தனது பக்கத்திலிருந்து அதே ஜோடி முன்னொட்டுத் தொகுப்புகளைப் பெயரிடுகிறது:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

ஒரு சாதனத்தின் local_ts மற்றொன்றின் remote_ts. ஹப்பின் தொகுதியைத் தலைமை அலுவலகத்திற்கு நகலெடுங்கள், ஜோடி தலைகீழாகிறது, எனவே குழந்தை SA ஒருபோதும் எழாது.

பழைய ipsec.conf தொடரியல் கமாவால் பிரிக்கப்பட்ட leftsubnet-ஐப் பயன்படுத்துகிறது. இயங்கும் பாதுகாப்பு சங்கம் பேச்சுவார்த்தை செய்த தேர்விகளை வைத்திருக்கிறது, எனவே திருத்தத்திற்குப் பிறகு சுரங்கப்பாதையை மீண்டும் நிறுவுங்கள். 10:00-க்கு மாற்றப்பட்ட தேர்வி 09:40-க்கு எழுந்த SA-க்கு எதிராகச் சோதிக்கப்பட்டாலும் தோல்வியடைகிறது, அதே நேரம் உள்ளமைவுக் கோப்பு எல்லா நேரமும் சரியாகத் தெரிகிறது.

பிறகு கடைசி ஹாப்பைச் சரிபார்க்கவும். தொலை முனையில் ip route get 10.80.0.25 சுரங்கப்பாதைக்குள் காட்ட வேண்டும். சேவை LAN திசைவியை அதன் இயல்புநிலை நுழைவாயிலாகப் பயன்படுத்தினால், அந்தத் திசைவிக்கும் திரும்பும் பாதை தேவை, இல்லையேல் பதில் அங்கேயே இறக்கிறது. அந்தப் பிரிவில் tcpdump -ni eth1 host 10.80.0.25 இயக்குவது பதில் முனையிலிருந்து வெளியேறியதா எனக் காட்டுகிறது.

ஹப்பில் ஓட்டத்தை அனுமதியுங்கள்

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

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

திருப்புப் பாதை வடிகட்டுதல் அதன் அருகிலுள்ள அமைதியான தோல்வி: இரண்டு பகுதிகளும் வெவ்வேறு இடைமுகங்களில் இருந்தால், rp_filter=1 பதிலை வீசக்கூடும், அதே நேரம் ஏற்பு விதியின் கவுண்டர் அசையாது. ஒரு முயற்சிக்கு முன்பும் பின்பும் iptables -vnL FORWARD-ஐ ஒப்பிடுங்கள். ஒருபோதும் அதிகரிக்காத விதி அடையப்படுவதில்லை, எனவே அதை மீண்டும் எழுதுவதற்குப் பதிலாக ஒரு அடுக்குக் கீழே பாருங்கள்.

ஒரு குழுவுக்கு மட்டும் செல்ல வேண்டுமெனில், உலகளாவிய push-ஐ விரிவாக்குவதற்குப் பதிலாக client-config-dir-இன் கீழ் ஒவ்வொரு கிளையண்ட் கோப்பிலும் பாதையை வையுங்கள். ஹப்பில் Source NAT உம் தொலைப் பக்கத்தின் திரும்பும் பாதைத் தேவையை நீக்குகிறது, ஆனால் அது பயனரின் முகவரியை மறைக்கிறது, எனவே தொலைத் தளத்தின் பதிவுகளும் முகவரி அடிப்படையிலான விதிகளும் பயனர்களை வேறுபடுத்துவதை நிறுத்துகின்றன.

கிளையண்டிலிருந்து சரிபார்த்து, பிறகு தலைகீழ் வரிசையில் பின்னிழுக்கவும்

ICMP மட்டுமல்ல, TCP துறையைச் சோதியுங்கள், ஏனெனில் சேவை தடுக்கப்பட்டிருக்கும்போது பிங் கடக்கக்கூடும். கிளையண்டிலிருந்து nc -vz 10.20.0.50 445 மற்றும் traceroute -n 10.20.0.50 இரண்டாவது ஹாப் ஹப்பின் சுரங்கப்பாதை முகவரியா எனக் காட்டுகின்றன. ஹப்பில், tcpdump -ni tun0 host 10.20.0.50 மற்றும் தளம்-க்கு-தளம் இடைமுகத்தில் அதே வடிகட்டி: இரண்டிலும் கோரிக்கை ஆனால் எதிலும் பதில் இல்லையெனில் சிக்கல் தொலைப் பக்கத்திற்கு நகர்கிறது.

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

பின்னிழுப்புப் பட்டியலை வைத்திருங்கள், ஏனெனில் நான்கு பொருள்கள் மாறின, மூன்றை மறப்பது எளிது: தள்ளப்பட்ட பாதை, ஹப்பின் பாதை, தேர்விகள் மற்றும் தீச்சுவர் விதிகள். அவற்றைத் தலைகீழ் வரிசையில் ரத்துசெய்து, SA-ஐ மீண்டும் நிறுவி, ஒரு பயனர் மீண்டும் இணைய அனுமதியுங்கள். பகுதி பின்னிழுப்பு இனி பொருந்தாத சுரங்கப்பாதையைக் காட்டும் பாதையை விட்டுச் செல்கிறது, அதைப் படிப்பது மூல மௌனத்தை விடக் கடினம். OpenVPN 2.6 கையேடு உங்கள் பதிப்பிற்கான push, route மற்றும் iroute-ஐ ஆவணப்படுத்துகிறது.