OpenVPN உடன் இணைக்கப்பட்டது ஆனால் எதுவும் ஏற்றப்படவில்லை: வாடிக்கையாளரிடமிருந்து வெளிநோக்கி ஒரு பயணம்

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

வாடிக்கையாளரில் தொடங்கி வெளிநோக்கிச் செல்லுங்கள்

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

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

இரண்டு பதிவுகள் பாக்கெட்டுகள் எங்கே நிற்கின்றன என்பதைக் காட்டுகின்றன

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

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

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

ip -4 route get 9.9.9.9

அந்த வெளியீட்டில் உள்ள dev புலம் NAT விதிக்குப் பின்னர் தேவைப்படும் பெயர், எனவே அதை வைத்திருங்கள்.

அனுப்புதல் என்பது kernel-இல் ஒரு சுவிட்ச் மற்றும் தீச்சுவர் கொள்கை

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

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

அனுப்புதல் பாதி மட்டுமே. UFW உள்ள புரவலனில் அனுப்புதல் கொள்கை /etc/default/ufw இல் அமைக்கப்படுகிறது, மீள்ஏற்றுதல் நடைமுறைக்கு வருவதற்கு முன் அது ACCEPT ஆக இருக்க வேண்டும். அனுப்புதல் பாதையில் இயல்புநிலை நீக்கம் கைக்குலுக்கலை முழுமையாக ஆரோக்கியமாக வைத்துக்கொண்டு டன்னலில் இருந்து வெளியேற முயலும் ஒவ்வொரு பாக்கெட்டையும் அமைதியாகத் தூக்கி எறிகிறது, அதுவே நீங்கள் தொடங்கிய அறிகுறி.

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

NAT விதியில் உண்மையான வெளியேற்ற இடைமுகத்தைப் பெயரிடுங்கள்

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

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

வழக்கமான தோல்வி என்பது வழிகாட்டியிலிருந்து நகலெடுக்கப்பட்ட விதி, அது -o eth0 என்று கூறுகிறது, ஆனால் அந்த இயந்திரத்தின் அடாப்டர் வேறு பெயரில் உள்ளது. விதி எச்சரிக்கையின்றி நிறுவப்படுகிறது, எதனுடனும் பொருந்தவில்லை, வாடிக்கையாளருக்கு இன்னும் இணையம் இல்லை. தொகுப்பு அதே தவறின் மறுபாதி: சேவையகம் 10.44.0.0/24 ஐப் பங்கிட்டு விதி 10.8.0.0/24 ஐ மூடினால், எதுவும் ஒருபோதும் பொருந்தாது.

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

iptables -t nat -L POSTROUTING -v -n

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

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

DNS என்பது முதல் தோல்விக்குப் பின்னால் உள்ள இரண்டாவது தோல்வி

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

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

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows வாடிக்கையாளர்கள் பின்னர் உள்ளூர் தீர்விக்குத் திரும்பலாம், block-outside-dns அதைத் தடுக்கவே உள்ளது, ஆனால் உள்ளூர் வலையமைப்பால் மட்டுமே தீர்க்கக்கூடிய பெயர்களை இழக்கும் விலையில். systemd-resolved பயன்படுத்தும் Linux வாடிக்கையாளர்கள் ஸ்கிரிப்ட் நிறுவாத வரை தள்ளப்பட்ட தீர்வியைப் பெரும்பாலும் புறக்கணிக்கிறார்கள், எனவே தள்ளுதல் புறக்கணிக்கப்பட்டது என்று முடிவெடுப்பதற்கு முன் டன்னல் சாதனத்திற்கான resolvectl status ஐச் சரிபாருங்கள்.

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