VPN ಸ್ಥಿತಿಗೆ ಬದ್ಧವಾದ ಫೈರ್‌ವಾಲ್ ಗೇಟ್ ಕೇವಲ ping ನಿಯಮ ಏಕೆ ಅಲ್ಲ

ಹೆಸರಿಸಿದ VPN ಪ್ರೊಫೈಲ್ ಸಂಪರ್ಕಗೊಂಡಾಗಲೆಲ್ಲಾ ಸರ್ವರ್‌ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ICMP echo ಅನ್ನು ಆನ್ ಮಾಡುವ ಫೈರ್‌ವಾಲ್ ನಿಯಮವನ್ನು ಊಹಿಸಿ. ಅದು «ಟನೆಲ್ ಮೂಲಕ ಮಾತ್ರ ping» ಎಂದು ಓದುತ್ತದೆ, ಮತ್ತು ಆ ಓದುವಿಕೆ ಮುಖ್ಯವಾದ ರೀತಿಯಲ್ಲಿ ತಪ್ಪು. ನಿಯಮವು ಯಾರು ಹೋಸ್ಟ್ ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ಸೀಮಿತಗೊಳಿಸುವುದಿಲ್ಲ; ಬೇರೆ ಸಂಪರ್ಕ ಆಕಸ್ಮಿಕವಾಗಿ ಸಕ್ರಿಯವಾಗಿರುವಾಗ ಸಾರ್ವಜನಿಕ ಇಂಟರ್ಫೇಸ್ ಯಾವುದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಇವು ಎರಡು ವಿಭಿನ್ನ ನೀತಿಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಮೌನವಾಗಿ ಒಡ್ಡುವಿಕೆಯನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ.

ನೀವು ಬರೆದಿದ್ದೀರಿ ಎಂದು ನೀವು ಭಾವಿಸುವ ನಿಯಮ

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

ಷರತ್ತು ಮೂಲ ವಿಳಾಸದ ಬದಲು ಸಂಪರ್ಕ ಸ್ಥಿತಿಯಾದ ಕ್ಷಣ, ಅನುಮತಿಸಿದ ಕಳುಹಿಸುವವರ ಗುಂಪು ಇನ್ನು VPN ಸಹಚರರ ಗುಂಪಲ್ಲ. ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ತಲುಪಬಲ್ಲ ಯಾರಾದರೂ ಗೇಟ್ ತೆರೆದಿರುವಾಗ echo ವಿನಂತಿ ಕಳುಹಿಸಬಹುದು. ಟನೆಲ್ ಮಾರ್ಗವಾಗಲಿಲ್ಲ; ಟನೆಲ್ ಸ್ವಿಚ್ ಆಯಿತು.

ಈ ಕಲ್ಪನೆಯನ್ನು ಪ್ರಚಾರ ಮಾಡುವವರು ಸಾಮಾನ್ಯವಾಗಿ ತಾವು ಬಯಸಿದ ಪರಿಣಾಮದ ಬಗ್ಗೆ ಸುಳ್ಳು ಹೇಳುವುದಿಲ್ಲ. ಕೊಂಡಿ ಆರೋಗ್ಯವಾಗಿದ್ದಾಗ ಮಾತ್ರ ಉತ್ತರಿಸುವ ಪರಿಶೀಲನೆ ಅವರಿಗೆ ಬೇಕಿತ್ತು, ಮತ್ತು ಕೊಂಡಿಯ ಆರೋಗ್ಯವನ್ನು VPN ಮೂಲಕ ಗಮನಿಸುವುದು ಸುಲಭವಾಗಿತ್ತು. ಲಭ್ಯತೆಯ ಸಂಜ್ಞೆಯನ್ನು ಪ್ರವೇಶ ನಿರ್ಣಯವೆಂದು ಪರಿಗಣಿಸಿ ನಂತರ ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದು ತಪ್ಪು.

ಗೇಟ್ ನಿಜವಾಗಿ ಏನನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ

ಈ ವಿನ್ಯಾಸವು ಎರಡು ಸ್ವತಂತ್ರ ವಿಷಯಗಳನ್ನು ಬೆಸೆಯುತ್ತದೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸುವುದೇ ಸರಿಪಡಿಸುವಿಕೆಯ ಬಹುಪಾಲು. ಮೊದಲನೆಯದು ವ್ಯಾಪ್ತಿ: ಯಾವ ಸ್ಥಳೀಯ ವಿಳಾಸ, ಯಾವ ದೂರದ ವಿಳಾಸಗಳು, ಯಾವ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಯಾವ ICMP ಪ್ರಕಾರ. ಎರಡನೆಯದು ಷರತ್ತು: ನಿಯಮದ ಆಬ್ಜೆಕ್ಟ್ ಈ ಕ್ಷಣ ಸಕ್ರಿಯವಾಗಿದೆಯೇ. ವ್ಯಾಪ್ತಿಯನ್ನು ಫೈರ್‌ವಾಲ್ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್‌ಗೂ ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ; ಷರತ್ತನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ ನೀತಿ ಭಂಡಾರಕ್ಕೆ ಬರೆಯುತ್ತದೆ, ಮತ್ತು ಎರಡೂ ಸಂಪೂರ್ಣ ಬೇರೆ ಗಡಿಯಾರಗಳಲ್ಲಿ ಹೊಂದಿಸಲಾಗುತ್ತವೆ.

ಅಗತ್ಯ ನಿಜವಾಗಿಯೂ ಕೇವಲ VPN ಸಹಚರರಾದರೆ, ವ್ಯಾಪ್ತಿಯೇ ಯಾವುದೇ ಸಂಪರ್ಕ-ಸ್ಥಿತಿ ತರ್ಕವಿಲ್ಲದೆ ಅದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ: ನಿಯಮವನ್ನು ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಅಥವಾ ಟನೆಲ್ ವಿಳಾಸ ಶ್ರೇಣಿಗೆ ಬಂಧಿಸಿ, ದೂರದ ವಿಳಾಸಗಳನ್ನು ಕ್ಲೈಂಟ್ ಪೂಲ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ಮತ್ತು «ICMP» ಬದಲು echo ಪ್ರಕಾರವನ್ನು ಸೂಚಿಸಿ. ಯಾವುದೇ VPN ಆನ್ ಆಗಿಲ್ಲದಿದ್ದಾಗಲೂ ಆ ನಿಯಮ ಸರಿಯಾಗಿರುತ್ತದೆ ಮತ್ತು ಸಂಬಂಧವಿಲ್ಲದ ಪ್ರೊಫೈಲ್ ಅದನ್ನು ತೆರೆಯಲಾರದು.

ಅಗತ್ಯ ನಿಜವಾಗಿಯೂ ಸಾರ್ವಜನಿಕ ಗೇಟ್ ಆದರೆ, ಅದನ್ನು ನೀತಿಯ ಪಠ್ಯದಲ್ಲಿ ಹೇಳಿ, ಏಕೆಂದರೆ ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳು ಬದಲಾಗುತ್ತವೆ. ಸಾರ್ವಜನಿಕ ಗೇಟ್ ನಿಖರ ಪ್ರೊಫೈಲ್ ಹೆಸರಿಸಬೇಕು, «ಸಂಪರ್ಕಗೊಂಡಿದೆ» ಎಂದರೇನು ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬೇಕು, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಕಳುಹಿಸುವವರು ವಿನ್ಯಾಸದ ಪ್ರಕಾರ ವ್ಯಾಪ್ತಿಯಲ್ಲಿದ್ದಾರೆ ಎಂದು ಘೋಷಿಸಬೇಕು. ಯಾರಾದರೂ ಆ ವಾಕ್ಯವನ್ನು ಬರೆಯಲು ಒತ್ತಾಯಿಸಲ್ಪಟ್ಟ ಕ್ಷಣದಲ್ಲಿ ಬಹುಪಾಲು ಗೊಂದಲ ಮಾಯವಾಗುತ್ತದೆ.

ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಒಮ್ಮೆ ನಿರ್ಮಿಸಿ, ನಂತರ ಅದನ್ನು ಟಾಗಲ್ ಮಾಡಿ

ಸ್ಥಿರ ಗುರುತಿನ ಒಂದು ನಿಯಮವನ್ನು ಮೊದಲೇ, ನಿಷ್ಕ್ರಿಯವಾಗಿ ಒದಗಿಸಿ, ಮತ್ತು ನಿಯಂತ್ರಕವು ಅದರ ಸಕ್ರಿಯ ಸ್ಥಿತಿಯನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸಲಿ. ಪ್ರತಿ ರನ್‌ನಲ್ಲಿ ಪ್ರದರ್ಶನ ನಾಮದಿಂದ ನಿಯಮಗಳನ್ನು ರಚಿಸುವುದೇ ನೀತಿ ಭಂಡಾರವು ಐದು ಬಹುತೇಕ ಒಂದೇ ರೀತಿಯ ಆಬ್ಜೆಕ್ಟ್‌ಗಳೊಂದಿಗೆ ಮತ್ತು ಅವುಗಳನ್ನು ತೆಗೆಯುವ ನಂಬಲರ್ಹ ದಾರಿಯಿಲ್ಲದೆ ಕೊನೆಗೊಳ್ಳುವ ಮಾರ್ಗ.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

ಹೆಸರು ಶಾಶ್ವತ ಗುರುತಿಸುವಿಕೆ; ಪ್ರದರ್ಶನ ನಾಮವು ಮನುಷ್ಯ ಸಂಪಾದಿಸಬಹುದಾದ ದಸ್ತಾವೇಜು. -Name ಮೇಲೆ ಹೊಂದಿಸಿ ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್ ನಕಲುಗಳನ್ನು ತಯಾರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಅದೇ ಆದೇಶ ರೂಪವು IPv6 ಪ್ರಕರಣವನ್ನು -Protocol ICMPv6 -IcmpType 128 ನೊಂದಿಗೆ ಒಳಗೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಅದು ಪ್ರತ್ಯೇಕ ನಿಯಮ ಏಕೆಂದರೆ echo ಪ್ರಕಾರದ ಸಂಖ್ಯೆಗಳು ಎರಡು ಕುಟುಂಬಗಳ ನಡುವೆ ಭಿನ್ನವಾಗಿವೆ.

ವಿಳಾಸ ಕುಟುಂಬ ಮತ್ತು ICMP ಪ್ರಕಾರವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಇರಿಸಿ, ಎರಡನೆಯ ಕಾರಣವೂ ಇದೆ: -Protocol ICMPv4 ಪ್ರಕಾರವಿಲ್ಲದೆ ಪ್ರೊಫೈಲ್ ಅನುಮತಿಸುವ ಪ್ರತಿ ICMPv4 ಸಂದೇಶವನ್ನೂ ಅನುಮತಿಸುತ್ತದೆ, ನೀವು ಎಂದೂ ಸ್ವೀಕರಿಸಲು ಉದ್ದೇಶಿಸದಿದ್ದವುಗಳೂ ಸೇರಿ. ಪ್ರಕಾರ 8 ಅನ್ನು ಹೆಸರಿಸುವುದು ನಿಯಮವನ್ನು echo ವಿನಂತಿಗೆ ಸಂಕುಚಿತಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ತಲುಪುವಿಕೆ ಪರಿಶೀಲನೆ ಕಳುಹಿಸುವುದು ಅದನ್ನೇ.

ಸ್ವಯಂಚಾಲನೆ ಉದ್ದೇಶಕ್ಕೆ ವಿರುದ್ಧವಾಗುವ ಸ್ಥಳ

ಪ್ರತಿ ಕೆಲವು ನಿಮಿಷಗಳಿಗೊಮ್ಮೆ ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ ಅನ್ನು ವಿಚಾರಿಸುವುದು ತಕ್ಷಣದ ಗಡಿಯನ್ನು ಉಂಟುಮಾಡಲಾರದು. ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡದ್ದರಿಂದ ಮುಂದಿನ ವಿಚಾರಣೆಯವರೆಗೆ ನಿಯಮವು ಸಾರ್ವಜನಿಕ ವಿಳಾಸದಲ್ಲಿ ಉತ್ತರಿಸುತ್ತಲೇ ಇರುತ್ತದೆ; ಸಂಪರ್ಕ ಏರಿದ್ದರಿಂದ ಮುಂದಿನ ವಿಚಾರಣೆಯವರೆಗೆ ಉತ್ತರಿಸುವುದಿಲ್ಲ. ಆ ವಿಳಂಬವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವುದು ಪ್ರಾಮಾಣಿಕ, ಮತ್ತು ವಿನ್ಯಾಸವು ಕಟ್ಟುನಿಟ್ಟಿನ ಅಪರಿವರ್ತನೆಯನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ ಎಂದು ಹೇಳುವುದು ಪ್ರಾಮಾಣಿಕವಲ್ಲ.

ಸ್ಥಿತಿ ಪರಿಶೀಲನೆಯಲ್ಲೇ ವ್ಯಾಪ್ತಿಯ ಬಲೆ ಇದೆ. Get-VpnConnection ಯಂತ್ರದಲ್ಲಿ ಸಂರಚಿಸಲಾದ ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಪ್ರಾರಂಭಿಕವಾಗಿ ಪ್ರಸ್ತುತ ಬಳಕೆದಾರರಿಗೆ ಮತ್ತು -AllUserConnection ನೊಂದಿಗೆ ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ. ಅದು ಈಗ RRAS ಸರ್ವರ್‌ಗೆ ಡಯಲ್-ಇನ್ ಆಗಿರುವ ದೂರದ ಬಳಕೆದಾರರನ್ನು ವರದಿ ಮಾಡುವುದಿಲ್ಲ; ಅದು ಬೇರೆ ಕಮಾಂಡ್‌ನ ಬೇರೆ ವೀಕ್ಷಣೆ. ತಪ್ಪಾದದ್ದರ ಮೇಲೆ ನಿರ್ಮಿಸಿದ ಗೇಟ್ ಯಾವುದಕ್ಕೂ ಸಂಪರ್ಕಗೊಂಡಿಲ್ಲ.

ನಂತರ ಯಾರೂ ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡದ ಸ್ಥಿತಿಗಳನ್ನು ಆವರಿಸಿ: ಹಿಂದಿನ ರನ್‌ನಿಂದ ನಿಯಮ ಈಗಾಗಲೇ ಸಕ್ರಿಯವಾಗಿರುವ ಸ್ಥಿತಿಯಲ್ಲಿ ಪ್ರಾರಂಭ, ಗೇಟ್ ತೆರೆದಿರುವಾಗ ನಿಯಂತ್ರಕದ ಕ್ರ್ಯಾಶ್, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಅಳಿಸಲ್ಪಟ್ಟರೂ ಅದರ ನಿಯಮ ಜೀವಂತವಾಗಿರುವುದು. ಪ್ರತಿಯೊಂದಕ್ಕೂ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಡೀಫಾಲ್ಟ್ ಬೇಕು, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಅನುಮತಿಗೆ ಸುರಕ್ಷಿತ ಡೀಫಾಲ್ಟ್ ನಿಷ್ಕ್ರಿಯ. ಅಗತ್ಯವು ವಿಚಾರಣಾ ಕಿಟಕಿಯನ್ನು ನಿಜವಾಗಿಯೂ ಸಹಿಸದಿದ್ದರೆ, ಸ್ಥಿತಿ-ಬದ್ಧ ನಿಯಮವು ತಪ್ಪು ಸಾಧನ ಮತ್ತು ಜಾರಿ ಟನೆಲ್‌ನಲ್ಲಿ ಇರಬೇಕು, ಸಾರ್ವಜನಿಕ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಅಲ್ಲ.

ಕೊನೆಯದಾಗಿ, ಸಾರ್ವಜನಿಕ ವಿನಂತಿಯನ್ನು ಎರಡು ಬಾರಿ ಪರೀಕ್ಷಿಸಿ, ಒಮ್ಮೆ ಆಯ್ಕೆಮಾಡಿದ ಸಂಪರ್ಕ ಆನ್ ಆಗಿರುವಾಗ ಮತ್ತು ಒಮ್ಮೆ ಅದು ಆಫ್ ಆಗಿರುವಾಗ, VPN ನಲ್ಲಿಲ್ಲದ ಹೋಸ್ಟ್‌ನಿಂದ. ಟನೆಲ್ ಒಳಗಿನಿಂದ ಯಶಸ್ವಿ ping ಈ ನೀತಿಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದೇ ಅಳತೆಯನ್ನು ಬಹುಪಾಲು ನಿಯೋಜನೆಗಳು ಬಿಟ್ಟುಬಿಡುತ್ತವೆ.