OpenVPN வழியாக LAN அணுகல் உடைந்ததா? மண்டலங்கள், வழித்தடங்கள் மற்றும் திரும்பும் பாதையைச் சரிபார்க்கவும்

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

LAN நோக்கிச் செல்லும் பாக்கெட்டை எந்த வடிகட்டி பார்க்கிறது

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

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

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

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

பிளவுபட்ட சுரங்கப்பாதைக்கு தள்ளப்பட்ட முன்னொட்டு ஏன் தேவை

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

push "route 192.168.50.0 255.255.255.0"

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

ip route show | grep 192.168.50

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

பதிலுக்கு அது அடையக்கூடிய முகவரி தேவை

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

tcpdump -ni tun0 host 192.168.50.20

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

சரியான இடத்தில் முடியும் படிக்கட்டு

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

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

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

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