VPN ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡ ನಂತರವೂ ರಕ್ಷಣಾ ಸ್ವಿಚ್ ಸಂಚಾರವನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ

ರಕ್ಷಣಾ ಸ್ವಿಚ್‌ನ ಫಿಲ್ಟರ್‌ಗಳು ಮತ್ತು drop ನಿಯಮಗಳು ಕ್ಲೈಂಟ್‌ಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುತ್ತವೆ. Windows ನ WFP ಸ್ಥಿತಿ ಮತ್ತು Linux ನ iptables ನಿಯಮಗಳನ್ನು ಓದಿ, ಅತ್ಯಂತ ಸಣ್ಣ ವಸ್ತುವನ್ನು ಅಳಿಸಿ, ನಂತರ ಅದನ್ನು ಮತ್ತೆ ಹಾಕುವ ಮಾಲೀಕರನ್ನು ಹುಡುಕಿ.

ಟನೆಲ್ ಹೋಗಿದೆ, ನೆಟ್‌ವರ್ಕ್ ಐಕಾನ್ ಸಾಮಾನ್ಯವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಏನೂ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ. ನೀವು VPN ಅನ್ನು ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿದ್ದೀರಿ, ಅನ್‌ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿದ್ದೀರಿ ಅಥವಾ ಮರುಬೂಟ್ ಮಾಡಿದ್ದೀರಿ, ಮತ್ತು ಕಡಿತದ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮನ್ನು ರಕ್ಷಿಸಬೇಕಿದ್ದ ಬ್ಲಾಕ್ ಇನ್ನೂ ನಿಂತಿದೆ. ಕ್ಲೈಂಟ್ ವಿಂಡೋ ಇದನ್ನು ವಿವರಿಸಲಾರದು, ಏಕೆಂದರೆ ನಿಮ್ಮನ್ನು ತಡೆಯುತ್ತಿರುವುದು ಕ್ಲೈಂಟ್ ಅಲ್ಲ: ನಿರ್ಧಾರವು ನಿಮ್ಮ ಹೆಸರಿನಲ್ಲಿ ಕರ್ನಲ್‌ಗೆ ಬರೆಯಲ್ಪಟ್ಟಿದೆ, ಮತ್ತು ಅದನ್ನು ತೆಗೆಯಲು ಏನೂ ಉಳಿದಿಲ್ಲ. Windows ನಲ್ಲಿ ಆ ಸ್ಥಿತಿ Windows Filtering Platform ನಲ್ಲಿದೆ; Linux ನಲ್ಲಿ ಅದು iptables ಅಥವಾ nftables ನಲ್ಲಿನ ನಿಯಮಗಳ ಗುಂಪು, ಹೆಚ್ಚಾಗಿ ಬೂಟ್‌ನಲ್ಲಿ ಮತ್ತೆ ಜಾರಿಗೊಳಿಸುವ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ನೊಂದಿಗೆ. ಮುಂದಿನದು ನಾನು ಬಳಸುವ ಕ್ರಮ: ಸ್ಥಿತಿಯನ್ನು ಓದಿ, ವೈಫಲ್ಯವನ್ನು ವಿವರಿಸುವ ಅತ್ಯಂತ ಸಣ್ಣ ವಸ್ತುವನ್ನು ಅಳಿಸಿ, ನಂತರ ಅದನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಹಾಕುವುದನ್ನು ಹುಡುಕಿ.

ರಕ್ಷಣಾ ಸ್ವಿಚ್ ಒಂದು ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ, ಕರ್ನಲ್ ಸ್ಥಿತಿ

ಡೆಸ್ಕ್‌ಟಾಪ್ ಕ್ಲೈಂಟ್‌ಗಳು ಟನೆಲ್‌ನ ಹೊರಗಿನ ಸಂಚಾರವನ್ನು ನಿರಾಕರಿಸುವ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಬ್ಲಾಕಿಂಗ್ ಅನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತವೆ. Windows ನಲ್ಲಿ ಅವು connect-redirect ಮತ್ತು transport ಪದರಗಳಲ್ಲಿನ WFP ಫಿಲ್ಟರ್‌ಗಳು, ಮತ್ತು ಕೆಲವು ಶಾಶ್ವತ: ಅವು Base Filtering Engine ನೀತಿ ಸಂಗ್ರಹದಲ್ಲಿ ದಾಖಲಾಗಿ, ಯಾವುದೇ VPN ಸಾಫ್ಟ್‌ವೇರ್ ಚಾಲನೆಯಾಗುವ ಮೊದಲು ಯಂತ್ರ ಬೂಟ್ ಆದಾಗ ಮರುಸ್ಥಾಪಿಸಲ್ಪಡುತ್ತವೆ. ಯಾವಾಗ ಸ್ವಚ್ಛಗೊಳಿಸುತ್ತವೆ ಎಂಬುದರಲ್ಲಿ ಕ್ಲೈಂಟ್‌ಗಳು ಭಿನ್ನ. ಕೆಲವು ಸಂಪರ್ಕ ಕಡಿತದಲ್ಲಿ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ತೆಗೆಯುತ್ತವೆ, ಕೆಲವು ಸ್ವಚ್ಛ ನಿರ್ಗಮನದಲ್ಲಿ ಮಾತ್ರ, ಇನ್ನು ಕೆಲವು ಮೊದಲು ಸ್ವಿಚ್ ಆಫ್ ಮಾಡಿದಾಗ ಮಾತ್ರ. ಬ್ಲಾಕ್ ಸಕ್ರಿಯವಾಗಿರುವಾಗ ಅನ್‌ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿ, ಅಥವಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊಲ್ಲಿರಿ, ಫಿಲ್ಟರ್‌ಗಳು ಉಳಿಯುತ್ತವೆ.

Linux ನಲ್ಲಿ ಸಮಾನಾಂತರವಾದದ್ದು ಔಟ್‌ಪುಟ್ ಮಾರ್ಗದಲ್ಲಿನ drop ಅಥವಾ reject ನಿಯಮ, ಕೆಲವೊಮ್ಮೆ forwarding ನಿಯಮ, ಕೆಲವೊಮ್ಮೆ ಬದಲಾದ chain ನೀತಿ. ಆ ನಿಯಮಗಳು ಅವನ್ನು ಸೇರಿಸಿದ ಪ್ರಕ್ರಿಯೆಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕುತ್ತವೆ ಏಕೆಂದರೆ ಅವು ಕರ್ನಲ್ ಸ್ಥಿತಿ: ಕ್ಲೈಂಟ್ ಅನ್ನು ಕೊಲ್ಲಿರಿ, ಕ್ರ್ಯಾಶ್ ಮಾಡಿಸಿ, ಅಥವಾ ವಿದ್ಯುತ್ ಕಡಿಯಿರಿ — ಕರ್ನಲ್ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಬೀಳಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ, ರದ್ದು ಮಾಡಲು ಏನೂ ಉಳಿಯುವುದಿಲ್ಲ. ಪರ್ಸಿಸ್ಟೆನ್ಸ್ ಪ್ಯಾಕೇಜ್ ಪ್ರಸ್ತುತ ನಿಯಮಗಳ ಗುಂಪಿನ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ತೆಗೆದು ಬೂಟ್‌ನಲ್ಲಿ ಮರುಸ್ಥಾಪಿಸುವ ಮೂಲಕ ಎರಡನೇ ಶಾಶ್ವತ ಪದರವನ್ನು ಸೇರಿಸುತ್ತದೆ, ಹಾಗಾಗಿ ಮುಂದಿನ ಆರಂಭವು ಬ್ಲಾಕ್ ಈಗಾಗಲೇ ಸ್ಥಾಪಿತವಾಗಿರುವ ಸ್ಥಿತಿಯಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಏನನ್ನಾದರೂ ಅಳಿಸುವ ಮೊದಲು WFP ಸ್ಥಿತಿಯನ್ನು ಓದಿ

Windows ನಿಮಗೆ ಬೇಕಾದ ಪರಿಕರಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆಡಳಿತಾತ್ಮಕ ಪ್ರಾಂಪ್ಟ್ ತೆರೆದು ವೇದಿಕೆಯ ಸ್ಥಿತಿಯನ್ನು ಡಂಪ್ ಮಾಡಿ; ಡಂಪ್ ಕೆಲಸದ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ wfpstate.xml ಆಗಿ ಇಳಿಯುತ್ತದೆ.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

XML ನಲ್ಲಿ ಹೋದ ಪೂರೈಕೆದಾರರ ಹೆಸರು, Block ಕ್ರಿಯೆ ಮತ್ತು ಪದರವನ್ನು ಹುಡುಕಿ. ಸಾಮಾನ್ಯ ಸಂಚಾರವನ್ನು ಮುರಿಯುವುದು connect-redirect ಮತ್ತು transport ಫಿಲ್ಟರ್‌ಗಳು; receive-accept ಪದರದ ಫಿಲ್ಟರ್ ಸಾಮಾನ್ಯವಾಗಿ ನಿಮ್ಮ ಕಾರಣವಲ್ಲ. Base Filtering Engine ಚಾಲನೆಯಲ್ಲೇ ಇಲ್ಲದಿದ್ದರೆ ಬೇರೆಡೆ ನೋಡಿ, ಏಕೆಂದರೆ ಆ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಜಾರಿಗೊಳಿಸಲು ಬೇರೆ ಯಾವುದೂ ಸಾಧ್ಯವಿಲ್ಲ.

ಸಾಮಾನ್ಯ ಫೈರ್‌ವಾಲ್ ನೋಟವನ್ನೂ ಅಡ್ಡಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಬಹುಪಾಲು ಜನರು ಎರಡರಲ್ಲಿ ಒಂದನ್ನಷ್ಟೇ ಪರಿಶೀಲಿಸುತ್ತಾರೆ:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

ಒಳಗೊಂಡ ಪ್ರೊಫೈಲ್‌ಗಳು ಆನ್ ಆಗಿದ್ದು ವಿಫಲವಾದ ಸಂಚಾರಕ್ಕೆ ಯಾವುದೇ ನಿಯಮ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಬ್ಲಾಕ್ Windows Firewall ನಿಂದ ಅಲ್ಲ, ಮೂರನೇ ಪಕ್ಷದ ಪೂರೈಕೆದಾರರಿಂದ ಬರುತ್ತದೆ. ಆ ವ್ಯತ್ಯಾಸವೇ ದುರಸ್ತಿಗೆ ಯಾವ ಪರಿಕರ ಬಳಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ನೀವು ಅಳಿಸುವ ವಾಕ್ಯರಚನೆಯಲ್ಲೇ Linux ನಿಯಮಗಳನ್ನು ಓದಿ

iptables -S ನಿಯಮಗಳನ್ನು ಸೇರಿಸಿದ ಅದೇ ರೂಪದಲ್ಲಿ ಮುದ್ರಿಸುತ್ತದೆ, ಹಾಗಾಗಿ ಔಟ್‌ಪುಟ್ ಅಳಿಸುವಿಕೆಗೆ ನೇರವಾಗಿ ಮರುಬಳಕೆ ಮಾಡಬಹುದು. iptables -L -v -n ಪ್ಯಾಕೆಟ್ ಕೌಂಟರ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಕೌಂಟರ್‌ಗಳು ನಿಯಮವು ನಿಮ್ಮ ವಿಫಲ ವಿನಂತಿಗಳಿಗೆ ನಿಜವಾಗಿ ಹೊಂದಿಕೆಯಾಗುತ್ತಿದೆಯೇ ಅಥವಾ ಸುಮ್ಮನೆ chain ನಲ್ಲಿ ಕೂತಿದೆಯೇ ಎಂದು ಹೇಳುತ್ತವೆ.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

ನಿಯಮಗಳಷ್ಟೇ ಅಲ್ಲ, chain ನೀತಿಗಳನ್ನೂ ಓದಿ: -P OUTPUT DROP ಯಾವುದೇ ನಿಯಮ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೂ ಸಂಚಾರವನ್ನು ತಡೆಯುತ್ತದೆ. IPv6 ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಎರಡೂ ಕುಟುಂಬಗಳನ್ನು ಸ್ಥಾಪಿಸುವ ಕ್ಲೈಂಟ್ IPv4 ನಿಯಮಗಳು ಹೋದ ನಂತರವೂ IPv6 ಬ್ಲಾಕ್ ಅನ್ನು ಉಳಿಸಬಹುದು, ಮತ್ತು ಲಕ್ಷಣವು ಅಪ್ಲಿಕೇಶನ್ ಯಾವ ಕುಟುಂಬಕ್ಕೆ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗುತ್ತದೆ. nftables ಬಳಸುವಲ್ಲಿ nft list ruleset ಅನ್ನೂ ಚಲಾಯಿಸಿ; ಎರಡು ಪರಿಕರಗಳು ಹೊಂದಾಣಿಕೆ ಪದರದ ಮೂಲಕ ಜೊತೆಯಾಗಿ ಇರುತ್ತವೆ, ಮತ್ತು ಒಂದು ಪಟ್ಟಿ ಪ್ಯಾಕೆಟ್ ಬೀಳಿಸಬಲ್ಲ ಎಲ್ಲಾ ನಿಯಮಗಳನ್ನು ತೋರಿಸಬೇಕೆಂದಿಲ್ಲ.

ವೈಫಲ್ಯವನ್ನು ವಿವರಿಸುವ ಅತ್ಯಂತ ಸಣ್ಣ ವಸ್ತುವನ್ನು ಅಳಿಸಿ

Windows ನಲ್ಲಿ ಮೊದಲ ಹೆಜ್ಜೆ ಇನ್ನೂ ಪೂರೈಕೆದಾರರ ಸ್ವಂತ ತೆಗೆಯುವ ಮಾರ್ಗ: ಇನ್‌ಸ್ಟಾಲರ್ ಅನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ repair ಅಥವಾ uninstall ಬಳಸಿ, ಅಥವಾ ಪೂರೈಕೆದಾರರು ಪ್ರಕಟಿಸಿದರೆ ಸ್ವಚ್ಛಗೊಳಿಸುವ ಪರಿಕರವನ್ನು ಚಲಾಯಿಸಿ. ಉಳಿದ ಸೇವೆಗಳು ಮತ್ತು ನಿಗದಿತ ಕಾರ್ಯಗಳು ಸಾಮಾನ್ಯ, ಮತ್ತು ಲಾಗಿನ್‌ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ಪ್ರಾರಂಭಿಸುವ ಕಾರ್ಯವು ಮುಂದಿನ ಬೂಟ್‌ನಲ್ಲಿ ಅದರ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಮತ್ತೆ ಸ್ಥಾಪಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ನ ರಿಜಿಸ್ಟ್ರಿ ಕೀಯನ್ನು ಓದುವಾಗ ವಿಫಲವಾಗುವ ಅನ್‌ಇನ್‌ಸ್ಟಾಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಸೇವೆ ಅಥವಾ ಕಾರ್ಯವು ಅದನ್ನು ಇನ್ನೂ ಹಿಡಿದಿಟ್ಟುಕೊಂಡಿದೆ ಎಂದರ್ಥ, ರಿಜಿಸ್ಟ್ರಿ ಹಾಳಾಗಿದೆ ಎಂದಲ್ಲ.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

ಶಾಶ್ವತ ಫಿಲ್ಟರ್‌ಗಳು ಕೊನೆಯ ಉಪಾಯ. ಅವು HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter ಅಡಿಯಲ್ಲಿವೆ, ಪ್ರತಿ ಫಿಲ್ಟರ್‌ಗೆ GUID ನಿಂದ ಕೀಲಿ ಹಾಕಿದ ಒಂದು ಮೌಲ್ಯ. ಮೊದಲು ಕೀಯನ್ನು ರಫ್ತು ಮಾಡಿ, ನೀವು ತೆಗೆಯುವ GUID ಗಳನ್ನು ದಾಖಲಿಸಿ, ಹೋದ ಕ್ಲೈಂಟ್‌ಗೆ ಸೇರಿದ ಮೌಲ್ಯಗಳನ್ನು ಮಾತ್ರ ಅಳಿಸಿ, ನಂತರ ಎಂಜಿನ್ ತನ್ನ ಸ್ಥಿತಿಯನ್ನು ಮರುನಿರ್ಮಿಸುವಂತೆ ಮರುಬೂಟ್ ಮಾಡಿ. ಇಡೀ ಕೀಯನ್ನು ಅಳಿಸಬೇಡಿ ಮತ್ತು Base Filtering Engine ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ: Windows Firewall ಮತ್ತು Defender ಅದನ್ನು ಅವಲಂಬಿಸಿವೆ, ಮತ್ತು ಒಂದು ಅಡಚಣೆಯನ್ನು ಇನ್ನೂ ಕೆಟ್ಟದಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತೀರಿ.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Linux ನಲ್ಲಿ iptables -S ಮುದ್ರಿಸಿದ ಸಾಲನ್ನು ತೆಗೆದುಕೊಂಡು -A ಬದಲಿಗೆ -D ಹಾಕಿ. ನೀವು ಗುರುತಿಸಿದ ಒಂದೇ ನಿಯಮವನ್ನು ಅಳಿಸುವುದು chain ಅನ್ನು ಖಾಲಿ ಮಾಡುವುದಕ್ಕಿಂತ ಉತ್ತಮ, ಏಕೆಂದರೆ ನಿಮ್ಮ ಸ್ವಂತ ನೀತಿ ಅಕ್ಷತವಾಗಿ ಉಳಿಯುತ್ತದೆ.

sudo iptables -D OUTPUT -p udp -j REJECT

drop ಬಳಕೆದಾರ-ವ್ಯಾಖ್ಯಾನಿತ chain ನಲ್ಲಿದ್ದರೆ, ಮೊದಲು ಆ chain ಗೆ ಇರುವ ಜಂಪ್ ಅನ್ನು ಅಳಿಸಿ, ನಂತರ -X ನಿಂದ chain ಅನ್ನು ತೆಗೆಯಿರಿ. drop ನಿಯಮಗಳು ಇನ್ನೂ ಇರುವಾಗ chain ನೀತಿಯನ್ನು ACCEPT ಗೆ ಹೊಂದಿಸುವುದು ನೀತಿ ನಿರ್ಧಾರವನ್ನು ತಲುಪುವ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಮಾತ್ರ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಪ್ರತಿ ಟೇಬಲ್ ಖಾಲಿ ಮಾಡುವುದು ಕೊನೆಯ ಉಪಾಯ: ಅದು ಬೇರೆ ಕಾರಣಗಳಿಗಾಗಿ ಸೇರಿಸಿದ ನಿಯಮಗಳನ್ನೂ ತೆಗೆಯುತ್ತದೆ, ಮತ್ತು ufw ಸಕ್ರಿಯವಾಗಿದ್ದರೆ ಸೇವೆಯು ಇನ್ನು ಇಲ್ಲದ chain ಗಳನ್ನು ತನ್ನದೆಂದು ಭಾವಿಸುವಂತೆ ಬಿಡುತ್ತದೆ.

ಅದನ್ನು ಮತ್ತೆ ಹಾಕುವ ಮಾಲೀಕರನ್ನು ಹುಡುಕಿ

ತಕ್ಷಣದ ದುರಸ್ತಿಯ ನಂತರ ಸ್ಥಿತಿಯನ್ನು ಮರುಸ್ಥಾಪಿಸುವುದನ್ನು ಹುಡುಕಿ. Linux ನಲ್ಲಿ ಪರ್ಸಿಸ್ಟೆನ್ಸ್ ಘಟಕ ಸಕ್ರಿಯವಾಗಿದೆಯೇ, ಕ್ಲೈಂಟ್‌ಗೆ ಲಾಗಿನ್‌ನಲ್ಲಿ ಫೈರ್‌ವಾಲ್ ಮರುಸ್ಥಾಪಿಸುವ ಸೆಟ್ಟಿಂಗ್ ಇದೆಯೇ, ಮತ್ತು /etc ಅಡಿಯಲ್ಲಿ ಉಳಿಸಿದ ನಿಯಮ ಫೈಲ್ ಇದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. Windows ನಲ್ಲಿ ಸ್ಟಾರ್ಟಪ್ ನಮೂದುಗಳು, ಸೇವೆಗಳು ಮತ್ತು ನಿಗದಿತ ಕಾರ್ಯಗಳನ್ನು ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಮರುಬೂಟ್ ಮಾಡಿ ಮತ್ತು ಮೊದಲಿನಂತೆಯೇ ಅದೇ ಆಜ್ಞೆಗಳಿಂದ ಸ್ಥಿತಿಯನ್ನು ಮತ್ತೆ ಓದಿ.

ಬ್ಲಾಕ್ ಮತ್ತೆ ಬಂದರೆ, ಅಳಿಸುವಿಕೆ ಪರಿಹಾರವಾಗಿರಲಿಲ್ಲ; ಮಾಲೀಕರೇ ಪರಿಹಾರ. ಯಾವ ಕ್ಲೈಂಟ್ ಅಥವಾ ಸೇವೆ ಅದನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ ಎಂದು ದಾಖಲಿಸಿ ಮತ್ತು ಅಲ್ಲೇ ವೈಶಿಷ್ಟ್ಯವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ, ಪ್ರತಿ ಸಂಪರ್ಕ ಕಡಿತದ ನಂತರ ಫೈರ್‌ವಾಲ್ ಪದರದಲ್ಲಿ ಹೋರಾಡುವ ಬದಲು.

ಒಂದೇ ping ಅಲ್ಲ, ನಿಜವಾದ ಸಂಚಾರದಿಂದ ಪರಿಶೀಲಿಸಿ

ಹೆಸರು ನಿರ್ಣಯ, TCP ಸಂಪರ್ಕ ಮತ್ತು ಹೊಸ ಬ್ರೌಸರ್ ಅಧಿವೇಶನವನ್ನು ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಮರುಬೂಟ್ ಮಾಡಿ ಅದೇ ಮೂರು ಪರಿಶೀಲನೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ. HTTPS ವಿಫಲವಾಗುತ್ತಿರುವಾಗ ping ಕೆಲಸ ಮಾಡಿದರೆ ಅದು ನೆಟ್‌ವರ್ಕ್ ಅಲ್ಲ, transport ಪದರದ ಫಿಲ್ಟರ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ; ಮರುಬೂಟ್ ನಂತರವಷ್ಟೇ ಮತ್ತೆ ಕಾಣುವ ಬ್ಲಾಕ್ ನೀವು ಇನ್ನೂ ಕಂಡುಹಿಡಿಯದ ಮಾಲೀಕರನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ಸಾಕ್ಷ್ಯವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ: ರಫ್ತು ಮಾಡಿದ BFE ಕೀ, ಅಥವಾ ಬದಲಾವಣೆಗೆ ಮೊದಲು ಸೆರೆಹಿಡಿದ iptables -S ಔಟ್‌ಪುಟ್. ಸರಿಪಡಿಸಲಾಗಿದೆ ಎಂದು ಹೇಳುವ ಮೊದಲು, ವಸ್ತುವನ್ನು ಯಾವ ಪದರದಿಂದ ತೆಗೆದಿರಿ, ಅದನ್ನು ಮತ್ತೆ ಸ್ಥಾಪಿಸಬಲ್ಲ ಮಾಲೀಕರು ಯಾರು, ಒಂದು ಸ್ವಚ್ಛ ಮರುಬೂಟ್ ನಂತರದ ಸ್ಥಿತಿ, ಮತ್ತು VPN ಪ್ರಕ್ರಿಯೆ ಚಾಲನೆಯಲ್ಲಿಲ್ಲದೆ ಸಾಮಾನ್ಯ ಬ್ರೌಸಿಂಗ್ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ. iptables(8) ಕೈಪಿಡಿ ಪುಟದಲ್ಲಿ ನೀವು ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆಯನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದರೆ ನಿಖರವಾದ ಅಳಿಸುವಿಕೆ ಮತ್ತು ನೀತಿ ವಾಕ್ಯರಚನೆ ಇದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು