SMB பங்கீடு VPN வழியாக மட்டுமே தோல்வியடைகிறது: கையொப்பமா அல்லது சப்நெட் மோதலா?
LAN-இல் வேலை செய்யும் பங்கீடு டன்னல் வழியாக மட்டுமே தோல்வியடையலாம். கையொப்ப மறுப்பு, மேற்பொருந்தும் சப்நெட் மற்றும் பழைய SMB அமர்வைப் பிரிக்கவும்.
அலுவலகத்தில் வேலை செய்து வீட்டில் நேரம் முடிந்துவிடும் மாப்பு செய்யப்பட்ட இயக்ககம் தனியாக எந்தப் பயனுள்ள தகவலையும் தருவதில்லை. டன்னல் வெளிப்படையாகப் பாக்கெட்டுகளை எடுத்துச் செல்கிறது, இல்லையெனில் சேவையகத்தை எதுவும் அடையாது. தோல்வியடைந்தது மூன்று அடுக்குகளில் ஒன்று: பெயர் தவறான முகவரிக்குத் தீர்க்கப்பட்டது, வாடிக்கையாளர் அமர்வைக் கையொப்பமிட மறுத்தார், அல்லது பழைய அமர்வு அதைச் சுமந்த இணைப்பைவிட நீடித்தது. ஒவ்வொன்றுக்கும் வெவ்வேறு பழுதுநீக்கம் உண்டு, மூன்றில் இரண்டு வாடிக்கையாளர் பக்கத்தில் உள்ளன.
மூன்று தோல்விகள் ஒரே பிழையை அணிகின்றன
இயக்கக எழுத்து எந்த அடுக்கு உடைந்தது என்பதைச் சொல்லாது, பிழை உரை பொதுவாக மூன்றுக்கும் பொருந்தும் அளவுக்குப் பொதுவானது. இரண்டு விரைவான கேள்விகளால் அவற்றைப் பிரிக்கவும்: சேவையகம் தன் IP முகவரியில் பதிலளிக்கிறதா, 445 துறைமுகம் இணைப்பை ஏற்கிறதா?
அந்தப் பதில்கள் ஊகத்திற்குப் பதிலாக முடிவு அட்டவணையை உருவாக்குகின்றன. IP வேலை செய்து பெயர் செய்யவில்லை என்றால் அது பெயர் தீர்வைச் சுட்டுகிறது. இரண்டும் வேலை செய்து உள்நுழைவு மறுக்கப்பட்டால் அது கையொப்பத்தைச் சுட்டுகிறது. இரண்டும் வேலை செய்து டன்னல் தடங்கலுக்குப் பின் கோப்பு வாசிப்பு நிற்கிறது என்றால் அது பழைய அமர்வைச் சுட்டுகிறது.
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
அதே வரிசையில் அவற்றை முடிக்கவும், ஏனெனில் தவறான புரவலனுக்குத் தீர்க்கப்படும் பெயர் பின்னர் செய்யும் ஒவ்வொரு சோதனையையும் அர்த்தமற்றதாக்குகிறது.
பங்கீட்டைத் தொடுவதற்கு முன் பெயரைத் தீர்க்கவும்
சேவையகம் தன் முகவரியில் பதிலளித்து பங்கீட்டின் பெயர் நேரம் முடிந்தால், டன்னல் தன் வேலையைச் செய்கிறது, வாடிக்கையாளர் தவறான இடத்தில் தேடுகிறது. தொலை அணுகலில் இதில் பெரும்பாலானதை இரண்டு காரணங்கள் விளக்குகின்றன.
முதலாவது முகவரி மேற்பொருந்தல். அலுவலகம் 192.168.70.0/24 பயன்படுத்தும்போது வீட்டு ரவுட்டர் அதே வரம்பை வழங்கினால், 192.168.70.20-ஆகத் தீர்க்கப்படும் புரவலன் பெயர் டன்னலுக்குப் பின்னுள்ள சேவையகத்திற்குப் பதிலாக உள்ளூர் சாதனத்தைச் சுட்டலாம். பின்னர் Windows கோரிக்கையை உள்ளூராக அனுப்பலாம், பாதையை மறுக்கலாம், அல்லது தற்செயலாக அந்த முகவரி உள்ள அச்சுப்பொறிக்குத் தீர்க்கலாம். பழுதுநீக்கம் ஒரு பக்கத்தை மறுஎண்ணிடுவது, மற்றொரு பாதையைச் சேர்ப்பது அல்ல.
இரண்டாவது DNS எல்லை. உள்ளக DNS சேவையகம் இல்லாத, அல்லது டன்னல் வழியாக அணுக முடியாத சேவையகம் கொண்ட VPN அடாப்டர் குறுகிய பெயர்களைப் பொது ரிசால்வருக்கு விட்டுவிடுகிறது. அடாப்டரின் DNS உள்ளீடுகளைப் படித்து, பங்கீட்டைத் தொடுவதற்கு முன் உள்ளகப் பெயரை நேரடியாகக் கேளுங்கள்:
> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15அந்த வினவல் எதிர்பார்க்கப்பட்ட முகவரியைத் திருப்பித் தந்தால், பெயர் தீர்வு தெளிவாகிவிட்டது, சிக்கல் ஸ்டாக்கில் மேலே உள்ளது.
இரு முனைகளிலும் கையொப்பத் தேவையைப் படிக்கவும்
ஒவ்வொரு உள்நுழைவையும் மறுக்கும் அணுகக்கூடிய சேவையகம் வலைப்பிழை அல்ல, கொள்கை முரண்பாட்டின் அறிகுறி. Windows வாடிக்கையாளரில் SMB கையொப்பத்தைக் கட்டாயமாக்கலாம், கையொப்பமிடாத சேவையகம் அல்லது NAS எவ்வளவு ஆரோக்கியமான டன்னலாக இருந்தாலும் அமர்வை முடிக்க முடியாது.
கொள்கை திருத்தியில் தேடாமல் வாடிக்கையாளர் அமைப்பைப் படிக்கலாம்:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionசேவையகப் பக்கத்தின் தொடர்புடைய மதிப்பு சேவையகத்தின் SMB உள்ளமைவில் உள்ளது, இரண்டும் ஒத்துப்போக வேண்டும். பதிவான ஒரு சம்பவத்தில் வாடிக்கையாளரில் தேவை உள்ளூர் கொள்கையால் இயக்கப்பட்டிருந்தது, சேவையகம் அறவே கையொப்பமிடவில்லை; அதை முடக்கி gpupdate /force இயக்கியதும் பங்கீடு உடனே மீண்டது. இது காரணத்தை உறுதிப்படுத்தும் கண்டறியும் படி, நிரந்தரத் திருத்தம் அல்ல.
சேவையகம் ஆதரிக்கும் இடங்களில் இரு முனைகளிலும் கையொப்பத்தை இயக்குவதை விரும்புங்கள். ஒரு பங்கீடு வேலை செய்ய பாதுகாப்பு அமைப்பை மாற்றுவது அதன் முந்தைய மதிப்பு மற்றும் காரணத்துடன் பதிவு செய்யப்பட வேண்டும், அடுத்த தணிக்கையில் யாரும் அதை மீண்டும் கண்டுபிடிக்க வேண்டியிருக்காது.
நேரங்காட்டிகளை சரிசெய்வதற்கு முன் பழைய அமர்வை அழிக்கவும்
VPN விழுந்து மீண்டும் இணைந்த பிறகு மட்டுமே நிற்கும் பங்கீடு பொதுவாக சேவையகம் ஏற்கனவே தள்ளிவிட்ட அமர்வை வைத்திருக்கிறது. சேவையகம் செயலற்ற SMB அமர்வுகளை LanmanServer\Parameters-இல் உள்ள Autodisconnect நேரங்காட்டியின்படி மூடுகிறது, இயல்புநிலை 15 நிமிடங்கள், வாடிக்கையாளருக்கு LanmanWorkstation\Parameters-இல் அதன் சொந்த SessTimeout உள்ளது. இந்த மதிப்புகளைவிட நீண்ட தடங்கல் இரு முனைகளையும் அமர்வு பற்றி வெவ்வேறு கருத்துடன் விடுகிறது.
பலன் அர்த்தமுள்ளதாக இருக்க ஒரு நிலையான வரிசையில் அதை மீண்டும் உருவாக்கவும்: டன்னலை இணைக்கவும், பங்கீட்டைத் திறக்கவும், டன்னலை இரண்டு நிமிடங்கள் துண்டிக்கவும், மீட்டெடுக்கவும், பின்னர் ஒரு கோப்பைப் படிக்க முயலவும். மாப்பு தானாகவே சரியானால் நேரங்காட்டிகளை விட்டுவிடுங்கள். மீண்டும் மாப்பு செய்யும் வரை நின்றால், டன்னல் எழுந்த பிறகு பங்கீட்டை மீண்டும் இணைக்கவும், அது இருப்பதற்கு முன்பே மாப்பு செய்வதற்குப் பதிலாக, மேலும் மாப்பு உதவியாளர் மீண்டும் முயல்கிறதா எனப் பாருங்கள்.
நேர வரம்புகளை உயர்த்துவது நிலையற்ற இணைப்புக்கு நியாயமான இறுதிப் படி, ஆனால் அது அறிகுறிக்குச் சிகிச்சை. சேவையகம் மறந்த அமர்வுக்காக அதிகம் காத்திருக்கும் வாடிக்கையாளர் இன்னும் காத்திருக்கிறார்.
மாப்பு வழியாக ஒரு கோப்பைப் படித்து, பின்னர் மீண்டும் ஒரு முறை டன்னலைத் துண்டித்து மீட்டெடுத்து முடிக்கவும். அந்த ஏற்புச் சோதனை மூன்று அடுக்குகளையும் ஒரே நேரத்தில் அளக்கிறது, பயனர் உண்மையில் செய்வதற்குப் பொருந்தும் ஒரே சோதனை அதுவே.