VPN ಕಿಲ್ ಸ್ವಿಚ್ ರೀಬೂಟ್ ನಂತರ ಉಳಿಯುತ್ತದೆಯೇ? ಅದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಹೇಗೆ

ರೀಬೂಟ್ ಮಾಡುವುದು ಜನರು ಕಿಲ್ ಸ್ವಿಚ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಮಾರ್ಗ, ಮತ್ತು ಅದೇ ಅತಿ ಹೆಚ್ಚು ಸುಳ್ಳು ಹೇಳುವ ಪರೀಕ್ಷೆ. ಕ್ಲೈಂಟ್‌ನಲ್ಲಿನ ಚೆಕ್ಬಾಕ್ಸ್ ಕೇವಲ ಒಂದು ಆದ್ಯತೆ; ಮುಖ್ಯವಾದುದು ನೆಟ್ವರ್ಕ್ ಸ್ಟ್ಯಾಕ್ ಮೇಲೇರುವ ಕ್ಷಣ ಮತ್ತು ಟನಲ್ ನಿಜವಾಗಿ ಸ್ಥಾಪಿತವಾಗುವ ಕ್ಷಣದ ನಡುವೆ ಏನಾದರೂ ಬ್ಲಾಕ್ ಅನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆಯೇ ಎಂಬುದು. Windows ನಲ್ಲಿ ಆ ಏನೋ ಸಾಮಾನ್ಯವಾಗಿ Windows Filtering Platform ನಲ್ಲಿನ ಒಂದು ಫಿಲ್ಟರ್, Linux ನಲ್ಲಿ ಒಂದು ಯುನಿಟ್ ಲೋಡ್ ಮಾಡುವ ನಿಯಮಗಳ ಗುಂಪು, macOS ನಲ್ಲಿ pf ಆಂಕರ್, Android ನಲ್ಲಿ ಸಿಸ್ಟಮ್‌ನ ಸ್ವಂತ always-on ಮತ್ತು ಲಾಕ್‌ಡೌನ್ ಧ್ವಜಗಳು. ಈ ವ್ಯವಸ್ಥೆಗಳು ರೀಬೂಟ್ ಉದ್ದಕ್ಕೂ ಬಹಳ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತವೆ, ಮತ್ತು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮಟ್ಟದವು ಮಾತ್ರ ಯಾರಾದರೂ ಸೈನ್ ಇನ್ ಮಾಡುವ ಮೊದಲು ತಮ್ಮ ಸ್ಥಾನದಲ್ಲಿರುತ್ತವೆ.

ರೀಬೂಟ್ ಮೂರು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತದೆ

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

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

ಬ್ಲಾಕ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸುವ ವಸ್ತುವನ್ನು ಹುಡುಕಿ

Linux ನಲ್ಲಿ netfilter ನಿಯಮಗಳು ಕರ್ನೆಲ್‌ನಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ. ನೀವು ವ್ಯವಸ್ಥೆ ಮಾಡದಿದ್ದರೆ ಬೂಟ್ ಸಮಯದಲ್ಲಿ ಯಾವುದೂ ಅವನ್ನು ಮತ್ತೆ ಬರೆಯುವುದಿಲ್ಲ: iptables-save ಜೊತೆಗೆ netfilter-persistent, nftables.service ಲೋಡ್ ಮಾಡುತ್ತದೆ /etc/nftables.conf, ಅಥವಾ ನಿಮ್ಮ ಸ್ವಂತ ಸ್ಕ್ರಿಪ್ಟ್ ಚಲಾಯಿಸುವ systemd ಯುನಿಟ್. ಏನು ಸಕ್ರಿಯವಾಗಿದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ, ನೀವು ಏನು ಸಂರಚಿಸಿದ್ದೀರಿ ಎಂದು ನೆನಪಿರುವುದನ್ನು ಅಲ್ಲ.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

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

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

ಎರಡನೆಯ ಆದೇಶವು wfpstate.xml ಅನ್ನು ಪ್ರಸ್ತುತ ಡೈರೆಕ್ಟರಿಗೆ ಬರೆಯುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಳ್ಳುವ ಮೊದಲು ಈಗಾಗಲೇ ಇರುವ ಬ್ಲಾಕ್ ಕ್ರಿಯೆಯ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಹುಡುಕಿ. Base Filtering Engine ಬೂಟ್‌ನ ಆರಂಭದಲ್ಲೇ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಶಾಶ್ವತ ಧ್ವಜದೊಂದಿಗೆ ಸೇರಿಸಿದ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೆಲವು ಕಿಲ್ ಸ್ವಿಚ್‌ಗಳು ಯಾವುದೇ ಕ್ಲೈಂಟ್ ವಿಂಡೋ ಇರುವ ಮೊದಲೇ ಸಂಚಾರವನ್ನು ತಡೆಯುತ್ತವೆ ಮತ್ತು ಇನ್ನು ಕೆಲವು ತಡೆಯುವುದಿಲ್ಲ. macOS ನಲ್ಲಿ sudo pfctl -s info pf ಸಕ್ರಿಯವಾಗಿದೆಯೇ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, sudo pfctl -s rules ಏನು ಲೋಡ್ ಆಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು VPN ಕ್ಲೈಂಟ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ತಮ್ಮ ನಿಯಮಗಳನ್ನು ಮುಖ್ಯ ಗುಂಪಿಗೆ ಅಲ್ಲದೆ ಆಂಕರ್‌ಗೆ ಜೋಡಿಸುತ್ತವೆ. utun3 ಎಂದು ಹೆಸರಿಸುವ ನಿಯಮವು ಮುಂದಿನ ಬೂಟ್ ನಂತರ ಬೇರೆ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ತೋರಿಸಬಹುದು, ಏಕೆಂದರೆ ಆ ಸಂಖ್ಯೆಯನ್ನು ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ನೀಡಲಾಗುತ್ತದೆ.

ನೆಟ್‌ವರ್ಕ್ ಏರುವ ಮತ್ತು ಟನಲ್ ಏರುವ ನಡುವಿನ ಅಂತರವನ್ನು ಗಮನಿಸಿ

ಅಪಾಯಕಾರಿ ಮಧ್ಯಂತರವು ಇಡೀ ರೀಬೂಟ್ ಅಲ್ಲ, ಅದು ಅಂತರ. ಇಂಟರ್‌ಫೇಸ್ ಒಂದು ಕ್ಷಣದಲ್ಲಿ ಲೀಜ್ ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಪಡೆಯುತ್ತದೆ, VPN ಸೇವೆ ಇನ್ನೊಂದು ಕ್ಷಣದಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಮತ್ತು ಟನಲ್ ಇನ್ನೂ ನಂತರ ದೃಢೀಕರಿಸುತ್ತದೆ, ಕೆಲವೊಮ್ಮೆ ಬಳಕೆದಾರರು ಸೈನ್ ಇನ್ ಮಾಡಿ ರುಜುವಾತು ಏಜೆಂಟ್ ಚಲಿಸಿದ ನಂತರವೇ. ಬ್ಲಾಕ್ ಅನ್ನು ಕೊನೆಯದಾಗಿ ಅನ್ವಯಿಸಿದರೆ, ಅಂತರದಲ್ಲಿರುವ ಎಲ್ಲವೂ ಬಯಲಾಗಿ ಹೊರಹೋಗುತ್ತದೆ.

systemd ಆತಿಥೇಯರಲ್ಲಿ ಊಹಿಸುವ ಬದಲು ಕ್ರಮವನ್ನು ಓದಿ. VPN ಮತ್ತು ಫೈರ್‌ವಾಲ್ ಯುನಿಟ್‌ಗಳಲ್ಲಿ systemctl cat ಅನ್ನು ಚಲಾಯಿಸಿ ಮತ್ತು After= ಅಥವಾ Before= ಅನ್ನು network-pre.target ಮತ್ತು network-online.target ಗೆ ಹೋಲಿಸಿ ನೋಡಿ. network-online.target ನಂತರ ಕ್ರಮಗೊಳಿಸಿದ ಫೈರ್‌ವಾಲ್ ಯುನಿಟ್ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಸೋಲುತ್ತದೆ; network-pre.target ಬೇಡಿಕೆ ಇಟ್ಟು ಅದಕ್ಕಿಂತ ಮೊದಲು ಕ್ರಮಗೊಳಿಸಿದ ಯುನಿಟ್ ಗೆಲ್ಲುತ್ತದೆ. Windows ನಲ್ಲಿ ಸಮಾನ ಪ್ರಶ್ನೆಗಳು ಸೇವೆಯ ಪ್ರಾರಂಭ ಪ್ರಕಾರ ಮತ್ತು ಅದರ ಅವಲಂಬನೆಗಳು, ಏಕೆಂದರೆ Manual ಗೆ ಹೊಂದಿಸಿದ ಸೇವೆ ಬೂಟ್-ಸಮಯದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ತಡೆಯಲಾರದು. ನಿಮ್ಮ ಅಗತ್ಯವು ಸೈನ್-ಇನ್ ಮೊದಲಿನ ಸಂಚಾರವನ್ನು ಒಳಗೊಂಡಿದ್ದರೆ, ಸಾಧನ ಮಟ್ಟದ ವ್ಯವಸ್ಥೆ ಮಾತ್ರ ಅದನ್ನು ಪೂರೈಸುತ್ತದೆ: Always On VPN ಸಾಧನ ಟನಲ್ ಯಂತ್ರ ಪ್ರಮಾಣಪತ್ರದೊಂದಿಗೆ ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರು ಲಾಗ್ ಇನ್ ಮಾಡುವ ಮೊದಲೇ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು Microsoft ಸಾಧನ ಟನಲ್‌ನ ಸಂರಚನೆಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ ಬಳಕೆದಾರ ಟನಲ್‌ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ. Android ಬೇರೆ ದಾರಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, always-on VPN ಅನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅದಿಲ್ಲದ ಸಂಪರ್ಕಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಅಲ್ಲ, ಸಿಸ್ಟಮ್‌ನಿಂದ ತಡೆಯುತ್ತದೆ.

ಪರೀಕ್ಷೆಯನ್ನು ಚಲಾಯಿಸಿ, ನಂತರ ಎರಡು ಸಮಯ ರೇಖೆಗಳನ್ನು ಹೋಲಿಸಿ

ರೀಬೂಟ್ ಮಾಡಿ ಸೋರಿಕೆಯಾದರೆ ಏನೂ ವೆಚ್ಚವಾಗದ ಗಮ್ಯಸ್ಥಾನದೊಂದಿಗೆ, ಮತ್ತು ಸ್ಥಿತಿಯನ್ನು ಅಂತರದ ನಂತರವಲ್ಲ, ಅಂತರದ ಸಮಯದಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ. ಅತ್ಯಂತ ಸ್ವಚ್ಛ ವಿಧಾನ ಬೂಟ್-ಸಮಯದ ಪ್ರೋಬ್: ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನುಮತಿಸಿದಷ್ಟು ಬೇಗ ಪ್ರಾರಂಭವಾಗುವ, ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಮತ್ತು ಫೈರ್‌ವಾಲ್ ಸ್ಥಿತಿಯನ್ನು ದಾಖಲಿಸುವ, ಸಣ್ಣ ಟೈಮೌಟ್‌ನೊಂದಿಗೆ ಒಂದು ವಿನಂತಿಯನ್ನು ಪ್ರಯತ್ನಿಸುವ ಮತ್ತು ಸ್ಥಳೀಯ ಕಡತಕ್ಕೆ ಒಂದು ಸಾಲು ಸೇರಿಸುವ oneshot ಯುನಿಟ್ ಅಥವಾ ನಿಗದಿತ ಕಾರ್ಯ. ಆ ದಾಖಲೆಯನ್ನು journalctl -b -u ಅಥವಾ ಸಿಸ್ಟಮ್ ಲಾಗ್‌ನಿಂದ ಬರುವ VPN ಸೇವೆಯ ಪ್ರಾರಂಭ ಸಮಯದೊಂದಿಗೆ ಹೋಲಿಸಿ.

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

ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಮುರಿಯದೆ ಅಂತರವನ್ನು ಮುಚ್ಚಿ

ಬೂಟ್‌ನಲ್ಲಿ ಬ್ಲಾಕ್ ಇಲ್ಲದಿದ್ದರೆ, ಎರಡನೇ ಕ್ಲೈಂಟ್ ನಿಯಮ ಸೇರಿಸುವ ಬದಲು ಜಾರಿಯನ್ನು ಒಂದು ಪದರ ಕೆಳಗೆ ಸರಿಸಿ. ನಿಯಮಗಳ ಗುಂಪನ್ನು ಉಳಿಸಿ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಬಳಸಲು ಸಿದ್ಧವಾಗುವ ಮೊದಲು ಕ್ರಮಗೊಳಿಸಿದ ಯುನಿಟ್‌ನಿಂದ ಅದನ್ನು ಲೋಡ್ ಮಾಡಿ, ಮತ್ತು ಆ ಯುನಿಟ್‌ಗೆ ಅದು ರಕ್ಷಿಸಬೇಕಾದ DNS ಹುಡುಕಾಟ ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಮೌಂಟ್ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ವ್ಯಾಪ್ತಿಯು ಸಮಯದಷ್ಟೇ ಮುಖ್ಯ: ಬಳಕೆದಾರ ID ಅಥವಾ cgroup‌ಗೆ ಹೊಂದುವ ನಿಯಮಗಳು ಪ್ರತಿ ಸಿಸ್ಟಮ್ ಡೀಮನ್ ಅನ್ನು ಬ್ಲಾಕ್‌ನ ಹೊರಗೆ ಬಿಡುತ್ತವೆ, ಮತ್ತು IPv4 ಮಾತ್ರ ನಿರ್ವಹಿಸುವ ಗುಂಪು IPv6 ಮತ್ತು DNS ಅನ್ನು ತಲುಪಬಹುದಾದಂತೆ ಬಿಡುತ್ತದೆ.

ನಿಮಗಾಗಿ ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಬಿಡಿ. ಬೂಟ್‌ನಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ತಡೆದು ನಂತರ ದೃಢೀಕರಿಸಲಾಗದ ಯಂತ್ರಕ್ಕೆ ನೆಟ್‌ವರ್ಕ್ ಇಲ್ಲದೆ ಇರುತ್ತದೆ, ಮತ್ತು ಪರಿಹಾರ ಬ್ಲಾಕ್ ಅನ್ನು ಅಳಿಸುವುದಲ್ಲ, ರುಜುವಾತು ಅಥವಾ ಕ್ರಮವನ್ನು ಸರಿಪಡಿಸುವುದು. ಸ್ಥಳೀಯ ಕನ್ಸೋಲ್‌ನ ದಾಖಲಿತ ಕಾರ್ಯವಿಧಾನ ಮತ್ತು ಟನಲ್‌ಗೆ ನಿಜವಾಗಿ ಬೇಕಾದುದಕ್ಕೆ ಕಿರಿದಾದ, ಉದ್ದೇಶಪೂರ್ವಕ ವಿನಾಯಿತಿಯನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ, ಉದಾಹರಣೆಗೆ ಸರ್ವರ್ ವಿಳಾಸ ಮತ್ತು ಟನಲ್ ಇರುವ ಮೊದಲು ಬಳಸುವ ರಿಸಾಲ್ವರ್.

ವ್ಯವಸ್ಥೆಯನ್ನು ನಂಬುವ ಮೊದಲು ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ಕ್ರಮವಾಗಿ ದೃಢೀಕರಿಸಿ. ನೀತಿಯು ಬೂಟ್ ಓದುವ ಸ್ಥಳದಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿದೆ. ಆ ಓದುಗರು ಇಂಟರ್‌ಫೇಸ್ ಬಳಸಲು ಸಿದ್ಧವಾಗುವ ಮೊದಲು ಚಲಿಸುತ್ತದೆ. ಬ್ಲಾಕ್ ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳು ಮತ್ತು DNS ಅನ್ನು ಆವರಿಸುತ್ತದೆ. ಬ್ಲಾಕ್ ಸಕ್ರಿಯವಾಗಿರುವಾಗಲೂ VPN ದೃಢೀಕರಿಸಬಲ್ಲದು. ನಾಲ್ಕೂ ಇದ್ದಾಗ, ರೀಬೂಟ್ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ.