ಪಿಂಗ್ ಒಂದೇ ದಿಕ್ಕಿನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ: 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

ಜಾರಿಗೆ ಬಂದ ನಿಯಮವನ್ನು ಮುದ್ರಿಸುವುದು ಅದನ್ನು ರಚಿಸಿದ ಆದೇಶವನ್ನು ನಂಬುವುದಕ್ಕಿಂತ ಉಪಯುಕ್ತ, ಏಕೆಂದರೆ ಮುನ್ನೋಟ ಮತ್ತು ಅನ್ವಯಿಸಿದ ನಿಯಮ ಬೇರೆ ಬೇರೆ ಸ್ಥಿತಿಗಳು. ವಿಳಾಸ ಫಿಲ್ಟರ್ ನೀವು ಉದ್ದೇಶಿಸಿದ ಮೂಲವನ್ನು ತೋರಿಸಿ, ಹೊರಗಿಟ್ಟ ಮೂಲ ಇನ್ನೂ ಸಮಯ ಮೀರಿದರೆ, ನಿಯಮ ಅದರ ವ್ಯಾಪ್ತಿ ಹೇಳಿದಂತೆಯೇ ನಡೆಯುತ್ತದೆ. ಕ್ಲೈಂಟ್ನಿಂದ ಪ್ರಾರಂಭವಾದ ಯಶಸ್ವಿ ಪಿಂಗ್ ಅದನ್ನು ಎಂದಿಗೂ ತೋರಿಸುತ್ತಿರಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಪರೀಕ್ಷೆಯ ದಿಕ್ಕು ಅದರ ಫಲಿತಾಂಶದ ಪಕ್ಕದ ದಾಖಲೆಗೆ ಸೇರುತ್ತದೆ. ಟಿಕೆಟ್ನಲ್ಲಿ ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಇರಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ಓದುಗ ವಿಫಲವಾಗಲು ಸಾಧ್ಯವಿಲ್ಲದ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತಾನೆ.