ಹಾನಿಗೊಳಗಾದ ಹೋಸ್ಟ್ನಲ್ಲಿ ಕಿಲ್ ಸ್ವಿಚ್ ಏನನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ ಎಂದು ಪರೀಕ್ಷಿಸುವುದು ಹೇಗೆ
ಅಡಚಣೆ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿ, ಪ್ರತಿ ಪದರದ ಫಲಿತಾಂಶವನ್ನು ಓದಿ ಮತ್ತು ಕಿಲ್ ಸ್ವಿಚ್ ಎಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ ಎಂದು ನೋಡಿ: ಅದು ಮಾರ್ಗಗಳನ್ನು ತಡೆಯುತ್ತದೆ, ಎನ್ಕ್ರಿಪ್ಷನ್ ಮೊದಲು ಡೇಟಾ ಓದುವ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನಲ್ಲ।
ಕಿಲ್ ಸ್ವಿಚ್ ಆನ್ ಮಾಡಿ, ಟನೆಲ್ ಸರ್ವರ್ ಆಫ್ಲೈನ್ ಮಾಡಿ ಮತ್ತು ಯಂತ್ರ ಇನ್ನೂ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಗಮನಿಸಿ। ಈ ಪರೀಕ್ಷೆ ನಡೆಸಲು ಯೋಗ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಅದು ಫೈರ್ವಾಲ್ ನಿಜವಾಗಿ ಜಾರಿಗೊಳಿಸುವುದನ್ನು ನೀವು ಊಹಿಸಿದ್ದರಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಫಲಿತಾಂಶಗಳು ಹೆಚ್ಚಿನ ಉತ್ಪನ್ನ ಪುಟಗಳು ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಸಣ್ಣವಾಗಿವೆ। ಕಿಲ್ ಸ್ವಿಚ್ ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ; ಸಾಧನದಲ್ಲಿ ಈಗಾಗಲೇ ಚಾಲನೆಯಲ್ಲಿರುವ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಅದು ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲ। ಕ್ಲೈಂಟ್ fail-closed ಎಂದು ಹೇಳುವ ಪ್ರತಿಯೊಂದು ಯಂತ್ರದಲ್ಲೂ ನಾನು ಈ ಕ್ರಮವನ್ನು ನಡೆಸುತ್ತೇನೆ ಮತ್ತು ಇದು ಸುಮಾರು ಹತ್ತು ನಿಮಿಷ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ।
ಸರ್ವರ್ನಿಂದ ಅಲ್ಲ, ಕ್ಲೈಂಟ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ
ಜಾರಿಗೊಳಿಸುವ ಸ್ಥಳವು ನೀವು ಕುಳಿತಿರುವ ಹೋಸ್ಟ್: ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಫೈರ್ವಾಲ್, ಸಹಾಯಕ ಸೇವೆ ಅಥವಾ VPN ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಡ್ರೈವರ್। ಇದು ಮುಖ್ಯ ಏಕೆಂದರೆ ಸ್ವಿಚ್ ಮಾಡಬಹುದಾದ ಎಲ್ಲವೂ ಆ ಪದರ ನೋಡುವುದಕ್ಕೆ ಸೀಮಿತವಾಗಿದೆ। ಕ್ಲೈಂಟ್ ರೂಟಿಂಗ್ ನಿಯಮ ಮತ್ತು ಮಾರ್ಕ್ನಿಂದ ಬ್ಲಾಕ್ ಜಾರಿಗೊಳಿಸಿದರೆ, ಸಾಕಷ್ಟು ಸವಲತ್ತು ಇರುವ ಯಾವುದೇ ವಸ್ತು ತನ್ನದೇ ನಿಯಮ ಸೇರಿಸಬಹುದು; ಕರ್ನಲ್ ಫೈರ್ವಾಲ್ ಟೇಬಲ್ ಬಳಸಿದರೆ, ಅದೇ ಸವಲತ್ತು ಟೇಬಲ್ ಸಂಪಾದಿಸಬಹುದು। ಸೈಫರ್ನ ಶಕ್ತಿ ಈ ಪ್ರಶ್ನೆಗೆ ಎಂದಿಗೂ ಬರುವುದಿಲ್ಲ।
ಆದ್ದರಿಂದ ಮೊದಲು ನಿರ್ಧರಿಸಬೇಕಾದದ್ದು ಈ ಸಾಧನದ ನೀತಿ ಯಾರದ್ದು ಮತ್ತು ಅದು ಏನನ್ನು ಮೀರಿಸಲು ಅನುಮತಿಸಲಾಗಿದೆ। ನಿರ್ವಹಿತ ಕೆಲಸದ ಯಂತ್ರದಲ್ಲಿ ಉತ್ತರ ಸಾಮಾನ್ಯವಾಗಿ ಸಂಸ್ಥೆಯ ಎಂಡ್ಪಾಯಿಂಟ್ ಏಜೆಂಟ್, ಮತ್ತು ವೈಯಕ್ತಿಕ VPN ಆ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ, ಟನೆಲ್ ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಆಗಿದ್ದರೂ।
ಮೊದಲ ಹಂತ: ಅದು ಒಳಗೊಳ್ಳುತ್ತದೆ ಎಂದು ನೀವು ನಂಬುವ ಮಾರ್ಗಗಳಲ್ಲಿ ಬ್ಲಾಕ್ ದೃಢೀಕರಿಸಿ
ಟನೆಲ್ ಅನ್ನು ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಅಲ್ಲ, ದೂರದ ತುದಿಯಲ್ಲಿ ಇಳಿಸಿ, ಇದರಿಂದ ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಸಂಪರ್ಕ ಹೊಂದಿರಬೇಕು ಎಂದು ನಂಬುತ್ತದೆ। ನಂತರ ವ್ಯಕ್ತಿ ನಿಜವಾಗಿ ಪ್ರಯತ್ನಿಸುವುದನ್ನು ಪ್ರಯತ್ನಿಸಿ:
curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset # or: iptables -S
ನೀವು ಬೇಗ ಮತ್ತು ಸ್ವಚ್ಛವಾಗಿ ವಿಫಲವಾಗುವ ಕ್ಲೈಂಟ್ ಬಯಸುತ್ತೀರಿ, ಬ್ರೌಸರ್ ಟೈಮೌಟ್ವರೆಗೆ ನೇತಾಡುವ ಕ್ಲೈಂಟ್ ಅಲ್ಲ। ನೇತಾಡುವುದು ಸಾಮಾನ್ಯವಾಗಿ ನಿರಾಕರಣೆ ಇಲ್ಲದ ನಿಯಮದಿಂದ ಪ್ಯಾಕೆಟ್ಗಳು ಮೌನವಾಗಿ ಬೀಳುವುದನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಅದು ಸ್ವೀಕಾರಾರ್ಹ, ಆದರೆ ಕ್ಲೈಂಟ್ ಸತ್ತ ಇಂಟರ್ಫೇಸ್ಗೆ ತೋರಿಸುವ ಹಳೆಯ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಬಿಟ್ಟಿರಬಹುದು ಎಂದೂ ಅರ್ಥ। ಟನೆಲ್ ಕೆಳಗಿರುವಾಗ ರೂಟಿಂಗ್ ಟೇಬಲ್ ಓದಿ: ಇನ್ನೂ ಟನೆಲ್ ಸಾಧನಕ್ಕೆ ತೋರಿಸುವ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಮತ್ತು ಹೊಸ ಹೊರಹೋಗುವ ಸಂಪರ್ಕಗಳನ್ನು ಮಾತ್ರ ತಡೆಯುವ ಫೈರ್ವಾಲ್ ನಿಯಮ ಎರಡು ವಿಭಿನ್ನ ಸ್ಥಿತಿಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ fail-closed।
ಕ್ಲೈಂಟ್ನ allow-LAN ಆಯ್ಕೆ ಆನ್ ಮತ್ತು ಆಫ್ ಇರುವಾಗ ಅದೇ ಆದೇಶಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ। ಆ ಟಾಗಲ್ ಅತಿ ಹೆಚ್ಚು ಆಶ್ಚರ್ಯದ ಸ್ಥಳ, ಏಕೆಂದರೆ ಉಳಿದ ನೀತಿ ಮುಚ್ಚಲು ಬರೆದಿದ್ದ ಮಾರ್ಗವನ್ನು ಅದು ಮತ್ತೆ ತೆರೆಯುತ್ತದೆ।
ಎರಡನೇ ಹಂತ: DNS ಮತ್ತು IPv6 ಅನ್ನು ಪ್ರತ್ಯೇಕ ಮಾರ್ಗಗಳಾಗಿ ಪರಿಶೀಲಿಸಿ
ಹೆಸರಿನ ವಿಭಜನೆ ಬಹುಪಾಲು ಅನುಷ್ಠಾನಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ಅಂತರ, ಏಕೆಂದರೆ ಪ್ರಶ್ನೆ ಸಿಸ್ಟಂ ರಿಜಾಲ್ವರ್ ಹೊರತುಪಡಿಸಿ ಬೇರೆ ಯಾವುದಾದರೂ ಮೂಲಕ ಹೊರಹೋಗಬಹುದು। ನಿಮ್ಮ ರಿಜಾಲ್ವರ್ ಸಂರಚನೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಸಾಧನದಿಂದ ಕೇಳಿ, ಮತ್ತು ಅಲ್ಲಿಯೇ v6 ಬದಿಯನ್ನು ಪರಿಶೀಲಿಸಿ:
dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route
ಟನೆಲ್ ಕೆಳಗಿರುವಾಗ ಎರಡೂ ಹೆಸರಿನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಖಾಲಿ ಉತ್ತರಗಳೇ ನೀವು ಬಯಸುವ ಫಲಿತಾಂಶ। ಎರಡನೇ ಪ್ರಶ್ನೆ ಉತ್ತರಿಸಿದರೆ, ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡಿದ ರಿಜಾಲ್ವರ್ ವಿಳಾಸ ತಲುಪಬಲ್ಲದು ಮತ್ತು ಟನೆಲ್ ಯಂತ್ರದಿಂದ ಹೊರಹೋಗುವ ಏಕೈಕ ಮಾರ್ಗವಲ್ಲ। ಕೇವಲ v6 ವಿನಂತಿ ಯಶಸ್ವಿಯಾದರೆ, ನೀತಿ IPv4 ಅನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು IPv6 ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ, ಅದು ಬೇರೆ ವಿಳಾಸ ಕುಟುಂಬದಲ್ಲಿ ಅದೇ ಸೋರಿಕೆ।
ಬ್ರೌಸರ್ಗಳು ಇದನ್ನು ಹೊರಗಿನಿಂದ ಓದಲು ಕಷ್ಟವಾಗಿಸುತ್ತವೆ, ಏಕೆಂದರೆ DNS over HTTPS ಗಾಗಿ ಸಂರಚಿಸಿದ ಬ್ರೌಸರ್ ಪ್ರಶ್ನೆಯನ್ನು HTTPS ವಿನಂತಿಯ ಮೂಲಕ ಪರಿಹರಿಸುತ್ತದೆ: ಆ ಅಂತ್ಯ ಬಿಂದುವಿಗೆ ಪೋರ್ಟ್ 443 ಎಷ್ಟು ತಡೆಯಲ್ಪಟ್ಟಿದೆಯೋ ಅಷ್ಟೇ ಪ್ರಶ್ನೆ ತಡೆಯಲ್ಪಡುತ್ತದೆ। ಸ್ಥಳೀಯ ಸಬ್ನೆಟ್ ಅನ್ನು ನೀತಿ ಅನುಮತಿಸುವ ಹೋಸ್ಟ್ನಲ್ಲಿ, ಆ ವಿನಂತಿ ಇನ್ನೂ LAN ನಲ್ಲಿನ ರಿಜಾಲ್ವರ್ಗೆ ತಲುಪಬಹುದು।
ಮೂರನೇ ಹಂತ: ನೆಟ್ವರ್ಕ್ ಒಡ್ಡುವಿಕೆಯನ್ನು ಎಂಡ್ಪಾಯಿಂಟ್ ಒಡ್ಡುವಿಕೆಯಿಂದ ಬೇರ್ಪಡಿಸಿ
ಈಗ ಯಾವುದೇ ಫೈರ್ವಾಲ್ ನಿಯಮ ತಲುಪದ ಭಾಗ। ಕಿಲ್ ಸ್ವಿಚ್ ಯಂತ್ರದಿಂದ ಹೊರಹೋಗುವ ಮಾರ್ಗಗಳನ್ನು ತಡೆಯುತ್ತದೆ; ಯಂತ್ರದಲ್ಲಿನ ಸಾಫ್ಟ್ವೇರ್ ಎನ್ಕ್ರಿಪ್ಷನ್ ಮೊದಲು ಡೇಟಾ ಓದುವುದನ್ನು ಅದು ನಿಲ್ಲಿಸುವುದಿಲ್ಲ ಮತ್ತು ಆ ಸಾಫ್ಟ್ವೇರ್ ಟನೆಲ್ ಅನ್ನು ಕಾನೂನುಬದ್ಧವಾಗಿ ಬಳಸುವುದನ್ನೂ ನಿಲ್ಲಿಸುವುದಿಲ್ಲ। ಕೀಲಾಗರ್, ದುರುದ್ದೇಶಪೂರಿತ ಎಕ್ಸ್ಟೆನ್ಶನ್, ತೆರೆದಿಟ್ಟ ಪರದೆ, ವಿಶಾಲ ಅನುಮತಿಗಳ ಸಿಂಕ್ ಕ್ಲೈಂಟ್: ಇವೆಲ್ಲವೂ ಸ್ವಿಚ್ ಸಂತೋಷದಿಂದ ಅನುಮತಿಸುವ ಸಂಪರ್ಕದ ಮೂಲಕ ಮಾಹಿತಿ ಸಾಗಿಸುತ್ತವೆ।
ಉದ್ಯೋಗದಾತರು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸ್ಥಾಪಿಸಿದ ಮೇಲ್ವಿಚಾರಣಾ ಸಾಫ್ಟ್ವೇರ್ಗೂ ಇದೇ ಅನ್ವಯಿಸುತ್ತದೆ। ಮಾರ್ಗಗಳನ್ನು ತಡೆಯುವುದು ಅದನ್ನು ತೆಗೆಯುವುದಿಲ್ಲ, ಮತ್ತು ಹೊಸ VPN ಸರ್ವರ್ ಖರೀದಿಸುವುದು ಪರಿಹಾರವಲ್ಲ, ಏಕೆಂದರೆ ಒಡ್ಡುವಿಕೆ ಟನೆಲ್ಗಿಂತ ಮೇಲಿದೆ।
ಕ್ಲೌಡ್ ಖಾತೆಗೆ ಅಪ್ಲೋಡ್ ಮಾಡುವ ಕ್ಲಿಪ್ಬೋರ್ಡ್ ಮ್ಯಾನೇಜರ್ ಇದನ್ನು ತೀಕ್ಷ್ಣವಾಗಿ ತೋರಿಸುತ್ತದೆ। ಸಂಚಾರ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿದೆ, ಗಮ್ಯಸ್ಥಾನ ಅನುಮತಿಸಲಾಗಿದೆ, ಮತ್ತು ಕಿಲ್ ಸ್ವಿಚ್ ಸಾರ್ವಕಾಲಿಕ ಆರೋಗ್ಯಕರ ಸ್ಥಿತಿ ವರದಿ ಮಾಡುತ್ತದೆ।
ನಾಲ್ಕನೇ ಹಂತ: ನಿಮ್ಮ ಪರೀಕ್ಷೆ ಬೆಂಬಲಿಸುವ ಹೇಳಿಕೆಯನ್ನು ಬರೆಯಿರಿ
ಅಡಚಣೆ ಪರೀಕ್ಷೆಯ ನಂತರ ನೀವು ನಿರ್ದಿಷ್ಟ ಸತ್ಯಗಳನ್ನು ಹೇಳಬಹುದು: ಯಾವ ಅಪ್ಲಿಕೇಶನ್ಗಳು ವಿಫಲವಾದವು, ಯಾವ ಮಾರ್ಗಗಳು ನಿಂತವು, DNS ಮತ್ತು IPv6 ಹೇಗೆ ವರ್ತಿಸಿದವು ಮತ್ತು ಟನೆಲ್ ಬಿದ್ದಾಗ ಬ್ಲಾಕ್ ತಡೆದುಕೊಂಡಿತೇ। ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂ ಸ್ವಚ್ಛವಾಗಿದೆ ಎಂದು ನೀವು ಹೇಳಲಾಗದು, ಮತ್ತು ದೂರದ ತುದಿಯ ಸೇವೆ ನಿಮ್ಮ ಲಾಗಿನ್ ಅನ್ನು ಖಾಸಗಿಯಾಗಿ ಇಡುತ್ತದೆ ಎಂದೂ ಹೇಳಲಾಗದು।
ಎರಡು ಸಮಸ್ಯೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿಡಿ ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಅದರದೇ ನಿಯಂತ್ರಣ ನೀಡಿ:
- ಕಿಲ್ ಸ್ವಿಚ್: ನಿಗದಿತ ವೈಫಲ್ಯ ಅಗತ್ಯ, ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಅಪ್ಗ್ರೇಡ್ ನಂತರ ನೀವು ಪುನರಾವರ್ತಿಸುವ ಅಡಚಣೆ ಪರೀಕ್ಷೆಯಿಂದ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ।
- ಸಾಧನ ವಿಶ್ವಾಸ: ಬೆಂಬಲಿತ ನವೀಕರಣಗಳು, ವಿಶ್ವಾಸಾರ್ಹ ಮೂಲದಿಂದ ಎಂಡ್ಪಾಯಿಂಟ್ ರಕ್ಷಣೆ, ವಿವರಿಸದ ಅನುಮತಿಗಳು ಮತ್ತು ದೃಢೀಕರಣ ವಿನಂತಿಗಳ ಪರಿಶೀಲನೆ।
- ಘಟನೆ: ಒಳನುಗ್ಗುವಿಕೆಯ ಶಂಕೆ ಇದ್ದಾಗ ವೇದಿಕೆ ಅಥವಾ ಸಂಸ್ಥೆಯ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅನುಸರಿಸಿ; ಹೊಸ ಸರ್ವರ್ ಸ್ವಚ್ಛಗೊಳಿಸುವ ಹಂತವಲ್ಲ।
- ಬಹಿರಂಗಪಡಿಸುವಿಕೆ: ಸಹಾಯ ಕೇಳುವಾಗ ಖಾಸಗಿ ಕೀಗಳನ್ನು ಅಥವಾ ಸಂಪೂರ್ಣ ರೋಗನಿರ್ಣಯ ಆರ್ಕೈವ್ಗಳನ್ನು ಅಂಟಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಲಾಗ್ಗಳು ಮತ್ತು ಸ್ಕ್ರೀನ್ಶಾಟ್ಗಳು ಸಂಪರ್ಕದಂತೆಯೇ ಅದೇ ರಹಸ್ಯಗಳನ್ನು ಹೊತ್ತಿರುತ್ತವೆ।
ಮುಂದಿನ ನವೀಕರಣದ ನಂತರ ಕ್ರಮವನ್ನು ಮತ್ತೆ ನಡೆಸಿ, ಏಕೆಂದರೆ ಕಿಲ್ ಸ್ವಿಚ್ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಚಲಿಸುವ ಸಂರಚನೆ। ನೀವು ಅವಲಂಬಿಸಿರುವ ವರ್ತನೆ ಇನ್ನೂ ನೀವು ಪಡೆಯುವ ವರ್ತನೆಯೇ ಎಂಬುದಕ್ಕೆ ಪರೀಕ್ಷೆಯೇ ಏಕೈಕ ಸಾಕ್ಷ್ಯ।