பிங் ஒரு திசையில் மட்டுமே வேலை செய்கிறது: Windows சேவையகத்தின் எதிரொலியை ஏன் விட்டுவிடுகிறது

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

இரு திசைகள், இரு வெவ்வேறு முடிவுகள்

வாடிக்கையாளர் எதிரொலிக் கோரிக்கையை அனுப்பும்போது, Windows ஃபயர்வால் அனுமதிக்க முடிவு செய்த வெளிச்செல் இணைப்பைக் காண்கிறது. பதில் அந்த நிறுவப்பட்ட ஓட்டத்திற்குள்ளேயே திரும்பி வருகிறது, எனவே நிலையைப் பின்தொடரும் இயந்திரம் ICMP-க்கான எந்த உள்வரும் விதியையும் கேட்காமல் அதை அனுமதிக்கிறது. நடைமுறையில் நிலை அடிப்படையிலான வடிகட்டுதல் என்பது இதுவே, யாரும் எழுதாத விதி இதில் ஈடுபடவில்லை. எனவே வாடிக்கையாளரின் வெற்றி உள்வரும் கொள்கையைப் பற்றி எதுவும் கூறவில்லை.

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

ஆகவே வாடிக்கையாளரின் வெற்றி வெளிச்செல் ICMP-யும் திரும்பும் பாதையும் வேலை செய்வதை நிரூபித்தது. அது உள்வரும் முடிவை ஒருபோதும் சோதிக்கவில்லை, ஃபயர்வால் சரியாக உள்ளது என்ற இயல்பான முடிவு நியாயமானது ஆனால் தவறானது. அதனால்தான் ஆதாரம் ஏற்கனவே உள்ள டிக்கெட்டுகளிலும் இந்தத் தவறு திரும்பத் திரும்ப நிகழ்கிறது.

பாக்கெட் மறையும் வரை பின்தொடருங்கள்

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

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

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

ICMP திறப்பதற்குப் பதிலாக ஒரு விதியை வரம்பிடுங்கள்

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

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

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

விதி எதை உள்ளடக்கவில்லை

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

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

முடிவை சரியான திசையில் படியுங்கள்

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

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

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