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

முன்னொட்டு முதலில் உங்களை நோக்கி வழிமாற்றப்பட வேண்டும்

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

வழங்குநர் 198.51.100.64/28 ஐ உங்கள் நுழைவு சேவையகத்திற்கு வழிமாற்றினால், அந்த வரம்பின் பொதிகள் சேவையகத்தை அடைந்து, நீங்கள் அவற்றை முன்னனுப்பாத வரை அங்கேயே நிற்கும். வழங்குநர் அதற்குப் பதிலாக வரம்பை உங்கள் மேல்நோக்கு இணைப்பில் பாலமாக இணைத்தால், சேவையகம் அதற்கு ARP பதிலளிக்க வேண்டும், அது வேறு சிக்கல்.

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

இரண்டு வழிமாற்று நிலைகள்: கர்னல் பாதை மற்றும் iroute

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

சேவையகப் பக்கப் பாதை இப்படி இருக்கும், முன்னொட்டும் முகமூடியும் ஒதுக்கீட்டுடன் பொருந்த வேண்டும்:

ip route add 198.51.100.64/28 dev tun0

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

iroute 198.51.100.64 255.255.255.240

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

சேவை முகவரி எங்கே வாழ்கிறது

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

சேவையை உள்நாட்டில் முடிக்கும் Linux கிளையனில் ஒரு ஹோஸ்ட் முகவரி போதும்:

ip address add 198.51.100.70/32 dev lo

முன்னொட்டு மேலும் ஒரு VM ஹோஸ்ட் அல்லது மற்றொரு LAN க்கு வழிமாற்றப்பட்டால், அதற்குப் பதிலாக அந்தக் கீழ்நோக்குப் பாதையையும் அதன் திரும்பும் பாதையையும் உள்ளமைக்கவும். தொகுதியில் உள்ள ஒவ்வொரு முகவரியையும் VPN கிளையனுக்கு ஒதுக்கத் தேவையில்லை, அது பின்னர் முரண்பாடுகளை உருவாக்கும்.

திரும்பும் பாதையில் பொது மூலத்தை வைத்திருங்கள்

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

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

iptables -t nat -S POSTROUTING

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

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

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

ஒப்படைக்கப்பட்ட முகவரி எந்தப் பாதையை எடுக்கிறது என்று கர்னலிடம் கேளுங்கள், கோரிக்கை இயங்கும் போது சுரங்கத்தைக் கவனியுங்கள்:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

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

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

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

தொடர்புடைய கட்டுரைகள்