OpenVPN உடன் இணைக்கப்பட்டது ஆனால் ping அல்லது SMB பங்கீடு இல்லையா? மூன்று வாயில்களைச் சரிபார்க்கவும்

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

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

ஒவ்வொரு வாயிலும் வெவ்வேறு அறிகுறியுடன் தோல்வியடைகிறது, முதலாவது மட்டுமே VPN சேவையகத்தில் உள்ளது.

ஃபார்வர்டிங் என்பது FORWARD சங்கிலியின் கொள்கை

OpenVPN கேட்பொலியின் ஏற்பு INPUT இல் நடைபெறுகிறது, எனவே LAN நோக்கிச் செல்லும் ஒவ்வொரு பொதியும் நிராகரிக்கப்பட்டாலும் சுரங்கப்பாதை இணைக்க முடியும். tun0 இலிருந்து வந்து LAN இடைமுகம் வழியாக வெளியேறும் போக்குவரத்து FORWARD வழியாகச் செல்கிறது, அங்கு இயல்புநிலை DROP கொள்கை உள்ள ஹோஸ்ட் அதை அமைதியாக நிராகரிக்கிறது. வேறு எதையும் தொடுவதற்கு முன் sysctl மற்றும் சங்கிலி இரண்டையும் சரிபார்க்கவும்: sysctl net.ipv4.ip_forward மற்றும் iptables -L FORWARD -v -n.

நீங்கள் விரும்பும் திசையும் அதற்குரிய பதில்களும் அனுமதிக்கவும், எடுத்துக்காட்டாக சுரங்கப்பாதை இடைமுகத்திலிருந்து LAN இடைமுகத்திற்கு accept விதி மற்றும் established, related போக்குவரத்திற்கான stateful விதி. LAN வேறு ரவுட்டருக்குப் பின்னால் இருந்தால், அந்த ரவுட்டருக்கு கிளையண்ட் குளத்திற்குத் திரும்பும் வழி அல்லது VPN சேவையகத்தில் source NAT தேவை. மேலும் விதிகளைச் சேர்ப்பதற்கு முன் ஒரு ping மூலம் அந்த வழியை உறுதிப்படுத்தவும், ஏனெனில் அடைய முடியாத விதி எப்போதும் கவுண்டரில் தோன்றாது.

SMB க்கு ஒன்றுக்கு மேற்பட்ட துறை தேவை

கோப்பு பங்கீடு ஒரு TCP 445 உரையாடல் அல்ல. கண்டறிதல் UDP 137 மற்றும் 138 ஐப் பயன்படுத்துகிறது, பழைய NetBIOS அமர்வுகள் TCP 139 ஐப் பயன்படுத்துகின்றன, நவீன SMB அமர்வுகள் TCP 445 ஐப் பயன்படுத்துகின்றன. 445 ஐ மட்டும் திறக்கும் விதி, மேப் செய்யப்பட்ட இயக்கி வேலை செய்து நெட்வொர்க் உலாவல் செயல்படாத, அல்லது அதற்கு நேர்மாறான எரிச்சலூட்டும் நிலையை உருவாக்குகிறது.

சுரங்கப்பாதை வழியாக பெரிய பரிமாற்றங்களும் உடைந்த பங்கீடு போலத் தோன்றும் MSS சிக்கல்களைச் சந்திக்கின்றன. LAN இன் முழு பிரிவு அளவை அறிவிக்கும் SYN சுரங்கப்பாதையின் சிறிய MTU ஆல் நிராகரிக்கப்படுகிறது, கைகுலுக்கலுக்குப் பிறகு இணைப்பு தொங்குகிறது. ஃபார்வர்டிங் பாதையில் MSS ஐக் கட்டுப்படுத்துவது, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, அந்த வகையான நிறுத்தத்தை நீக்குகிறது. அடைவு பட்டியலுக்குப் பதிலாக சில மெகாபைட்டுகளின் நகலால் சரிபார்க்கவும், ஏனெனில் பெரிய பரிமாற்றங்கள் செல்லாதபோதும் சிறிய பதில்கள் செல்கின்றன.

சுரங்கப்பாதை அடாப்டர் புதிய நெட்வொர்க் சுயவிவரமாக வருகிறது

Windows ஒவ்வொரு அடாப்டரையும் ஒரு நெட்வொர்க் சுயவிவரத்தில் வகைப்படுத்துகிறது, புதிய சுரங்கப்பாதை அடாப்டர் பொதுவாக Public இல் விழுகிறது, அங்கு கோப்பு மற்றும் அச்சுப்பொறி பங்கீட்டு விதிகள் தடுக்கப்படுகின்றன. அது கோப்பு சேவையகத்தில் உள்ள ஹோஸ்ட் ஃபயர்வாலின் முடிவு, VPN சேவையகத்தில் உள்ள ரவுட்டிங் சிக்கல் அல்ல. கொள்கை அனுமதிக்கிறதா என்பதை உறுதிப்படுத்திய பிறகு வேண்டுமென்றே வகையை மாற்றவும் Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private மூலம், ஏனெனில் வகை எந்த உள்வரும் விதிகள் பொருந்தும் என்பதையும் மாற்றுகிறது.

அதே சுயவிவரம் TCP 445 வெற்றிபெறும்போது ping தோல்வியடைவதை விளக்குகிறது: Public இல் எக்கோ கோரிக்கைகள் இயல்பாக நிராகரிக்கப்படுகின்றன.

பெயர்கள் ரவுட் செய்யப்பட்ட சுரங்கப்பாதையைத் தாமாகவே கடக்காது

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

வரிசைப்படுத்தல் இன்னும் WINS ஐச் சார்ந்திருந்தால், ஒளிபரப்பு போக்குவரத்து வரும் என்று எதிர்பார்க்காமல் கிளையண்டில் அதை உள்ளமைக்கவும். பெயர் தோல்வி ஃபயர்வால் தோல்வியாகக் கருதப்படாதபடி முதலில் முகவரியால் சோதிக்கவும்.

ஒரு நேரத்தில் ஒரு அடுக்கைச் சோதித்து முதல் தோல்வியைப் படிக்கவும்

மேல்நோக்கிச் செல்லுங்கள்: சுரங்கப்பாதை நுழைவாயிலுக்கு ping செய்யவும், முகவரியால் LAN ஹோஸ்டுக்கு ping செய்யவும், பிறகு Test-NetConnection -ComputerName 10.8.0.5 -Port 445 மூலம் சேவையின் துறையைத் திறக்கவும், அதன் பிறகே பங்கீட்டில் அங்கீகாரம் செய்யவும். முதலில் தோல்வியடையும் படி தான் சரிசெய்ய வேண்டிய அடுக்கு, அது கடக்கும் வரை ஒவ்வொரு அடுத்த படியும் இரைச்சல். துறை மூடியிருந்தும் ping பதிலளித்தால் அது கோப்பு சேவையகத்தின் சொந்த ஃபயர்வாலைக் குறிக்கிறது, ஆனால் அமைதியான ping இருந்தும் துறை திறந்தால் அது ICMP வடிகட்டலைக் குறிக்கிறது. எதையும் மாற்றுவதற்கு முன் முதல் தோல்விப் படியை எழுதி வைக்கவும், ஏனெனில் இரண்டாவது மாற்றம் முதல் மாற்றத்தின் முடிவை மறைக்கிறது.

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

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

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