ಡೌನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅಥವಾ ಫೈರ್‌ವಾಲ್ ನಿಯಮ: ಸೋರಿಕೆಯನ್ನು ಯಾವುದು ನಿಲ್ಲಿಸುತ್ತದೆ?
ಸಂಪರ್ಕ ಕಡಿತದಲ್ಲಿ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಕೆಳಗಿಳಿಸುವುದು ಒರಟು ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಅನುಮತಿಗಳಿಲ್ಲದೆ ಚಲಿಸುತ್ತದೆ. ಕಡಿತದ ನಂತರವೂ ಉಳಿಯುವ ಮತ್ತು ಕಂದರವನ್ನು ಮುಚ್ಚುವ ಫೈರ್‌ವಾಲ್ ನಿಯಮದೊಂದಿಗೆ ಅದನ್ನು ಹೋಲಿಸಿ.
ಎರಡು ವಿನ್ಯಾಸಗಳು ಒಂದೇ ವಿಷಯವನ್ನು ಭರವಸೆ ನೀಡುತ್ತವೆ: ಸುರಂಗ ಬಿದ್ದಾಗ, ಏನೂ ತೆರೆದ ರೂಪದಲ್ಲಿ ಹೊರಕ್ಕೆ ಹೋಗುವುದಿಲ್ಲ. ಒಂದು ಟಿಯರ್‌ಡೌನ್ ಸಮಯದಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್ ಚಲಾಯಿಸಿ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಕತ್ತರಿಸುತ್ತದೆ. ಇನ್ನೊಂದು ಫೈರ್‌ವಾಲ್ ನಿಯಮವನ್ನು ಜಾರಿಯಲ್ಲಿಡುತ್ತದೆ ಮತ್ತು VPN ಕ್ಲೈಂಟ್‌ನಿಂದ ಏನನ್ನೂ ಕೇಳುವುದಿಲ್ಲ. ಅವು ಯಾರಿಗೆ ಕ್ರಮಕ್ಕೆ ಅನುಮತಿ ಇದೆ, ಕಂದರದ ಸಮಯದಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಯಂತ್ರವು ಹೇಗೆ ಮತ್ತೆ ಆನ್‌ಲೈನ್ ಆಗುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನವಾಗಿವೆ. ಈ ಮೂರು ಅಂಶಗಳಲ್ಲಿ ಅವನ್ನು ಹೋಲಿಸುವುದು ಯಾವುದು ಕಠಿಣ ಎಂದು ವಾದಿಸುವುದಕ್ಕಿಂತ ಉಪಯುಕ್ತ.
ಒಂದೇ ಕೆಲಸ, ಎರಡು ವಿಧಾನ
ಪ್ರೊಫೈಲ್ ಸ್ಕ್ರಿಪ್ಟ್ ಚಲಾಯಿಸಲು ಅನುಮತಿಸಿದರೆ, ಕ್ಲೈಂಟ್ ಸುರಂಗ ಏರಿದಾಗ ಮತ್ತು ಟಿಯರ್‌ಡೌನ್ ಆದಾಗ ಕೊಕ್ಕೆಗಳನ್ನು ಚಲಾಯಿಸಬಹುದು. ಆ ಕೊಕ್ಕೆ ಕ್ಲೈಂಟ್‌ನ ಜೀವನಚಕ್ರದ ಒಳಗೆ, ಸಂಪರ್ಕ ಮುಚ್ಚುತ್ತಿರುವ ಕ್ಷಣದಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಫೈರ್‌ವಾಲ್ ನಿಯಮವಾದರೋ ವ್ಯವಸ್ಥೆಗೆ ಸೇರಿದ್ದು, ಕ್ಲೈಂಟ್ ಚಲಿಸುತ್ತಿದೆಯೇ, ಕುಸಿದಿದೆಯೇ ಅಥವಾ ಕೊಲ್ಲಲ್ಪಟ್ಟಿದೆಯೇ ಎಂದು ಅದು ಲೆಕ್ಕಿಸುವುದಿಲ್ಲ.
| Property | Teardown script | Firewall unit |
|---|---|---|
| Runs when the client is killed | No | Yes |
| Needs privilege at teardown time | Usually yes | Configured once, at boot |
| Acts on the whole machine | Often, including recovery paths | Only on the flows it matches |
ಆ ಕೋಷ್ಟಕವೇ ಇಡೀ ವಾದ. ಸ್ವಚ್ಛ ಮುಚ್ಚುವಿಕೆಯಲ್ಲಿ ಮಾತ್ರ ಚಲಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್ ನಿಮಗೆ ಕಡಿಮೆ ಚಿಂತೆ ಇದ್ದ ಪ್ರಕರಣವನ್ನು ಆವರಿಸುತ್ತದೆ; ಮುಖ್ಯವಾದ ಪ್ರಕರಣ ಕ್ರ್ಯಾಶ್ ಅಥವಾ ಜಾಲದ ನಾಶ, ಮತ್ತು ಎರಡೂ ಸ್ವಚ್ಛ ಟಿಯರ್‌ಡೌನ್ ನೀಡುವುದಿಲ್ಲ.
ಟಿಯರ್‌ಡೌನ್ ಕೊಕ್ಕೆ ಏನು ಮಾಡಬಹುದು ಮತ್ತು ಏನು ಮಾಡಲಾರದು
ದಾಖಲಿತ ಮಾದರಿ ಜಾಲ ಇಂಟರ್ಫೇಸ್‌ಗಳ ಮೂಲಕ ಸಾಗಿ loopback ಹೊರತುಪಡಿಸಿ ಎಲ್ಲವನ್ನೂ ಕೆಳಗಿಳಿಸುತ್ತದೆ. ಭೌತಿಕ ಸಾಧನ ಕೆಳಗಿದ್ದಾಗ ಸುರಂಗದ ಹೊರಗೆ ಏನೂ ತಪ್ಪಿಸಿಕೊಳ್ಳಲಾರದು, ಅದೇ ನಿಖರ ಉದ್ದೇಶ.
#!/bin/sh
for dev in /sys/class/net/*; do
name=$(basename "$dev")
[ "$name" = lo ] || ip link set dev "$name" down
doneಇದು ಸ್ಥಳೀಯ ಜಾಲ, ಯಂತ್ರವು ಆತಿಥ್ಯ ನೀಡುವ ಪ್ರತಿಯೊಂದು ಸೇವೆ ಮತ್ತು ಸಮಸ್ಯೆ ಸರಿಪಡಿಸಲು ನೀವು ಬಳಸುವ ಮಾರ್ಗವನ್ನೂ ಕೆಳಗಿಳಿಸುತ್ತದೆ. ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ನಿಸ್ತಂತು ಸಾಧನಕ್ಕೆ ನಂತರ ಕೈಯಿಂದ ಬದಲಾವಣೆ ಬೇಕಾಗಬಹುದು, ಹೀಗಾಗಿ ಸಣ್ಣ ಅಡಚಣೆ ದುರಸ್ತಿ ಅವಧಿಯಾಗುತ್ತದೆ. ಇನ್ನೂ ಕೆಟ್ಟದ್ದೆಂದರೆ, ಕೊಕ್ಕೆಗೆ ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಮಾಡಲು ಅನುಮತಿ ಇಲ್ಲದಿರಬಹುದು: ಕ್ಲೈಂಟ್ ಸವಲತ್ತುಗಳನ್ನು ಬಿಟ್ಟಾಗ, ಟಿಯರ್‌ಡೌನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಸವಲತ್ತಿಲ್ಲದ ಖಾತೆಯಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ ಬದಲಾವಣೆಯೂ ಅನುಮತಿ ದೋಷದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ, ಆ ದೋಷ ಯಾರೂ ಲಾಗ್ ಓದದ ಕ್ಷಣದಲ್ಲಿ ಬರೆಯಲ್ಪಡುತ್ತದೆ.
ಕೊಕ್ಕೆಯನ್ನು ನಂಬುವ ಮೊದಲು ಕ್ಲೈಂಟ್ ಹೇಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. root ಆಗಿ ಕೈಯಿಂದ ಚಲಾಯಿಸಿದಾಗ ಕೆಲಸ ಮಾಡುವ ಸ್ಕ್ರಿಪ್ಟ್, ಬೂಟ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುವ ಸೇವೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಏನನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಮಾಡುತ್ತದೆ
ಸುರಂಗದ ಸಂಚಾರಕ್ಕೆ ಮಾತ್ರ ಅನುಮತಿಸುವ ನಿಯಮ, ಕ್ಲೈಂಟ್ ಪ್ರಕ್ರಿಯೆ ಹೋದಾಗಲೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಕರ್ನಲ್ ಆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅವಲಂಬಿಸಿಲ್ಲ. ನಿಯಮ ಹೆಚ್ಚು ಸಂಕುಚಿತವೂ ಆಗಿದೆ: ಅದು ಹೊಂದಿಕೆಯಾಗುವ ಹರಿವುಗಳನ್ನೇ ತಡೆಯುತ್ತದೆ ಮತ್ತು loopback, ಸ್ಥಳೀಯ ಉಪಜಾಲ ಮತ್ತು ಚೇತರಿಕೆ ಮಾರ್ಗವನ್ನು ಒಂಟಿಯಾಗಿ ಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಂತ್ರವನ್ನು ಸಿಕ್ಕಿಹಾಕಿಸುವುದಿಲ್ಲ.
ಬೆಲೆಯೆಂದರೆ ನಿಯಮವನ್ನು ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್‌ನ ಮಾಲೀಕರೇ ಬರೆಯಬೇಕು ಮತ್ತು ನಿರ್ವಹಿಸಬೇಕು, ಮತ್ತು ಅದು ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ರಚಿಸುವ ಸುರಂಗ ಸಾಧನವನ್ನು ಹೆಸರಿಸಬೇಕು. ಅಂದರೆ ನಿಯಮ ಮತ್ತು ಪ್ರೊಫೈಲ್ ಜೊತೆಯಾಗಿ ನಿರ್ವಹಿಸಬೇಕು; ಹೆಸರು ಬದಲಾದ ಇಂಟರ್ಫೇಸ್ ಎಲ್ಲವನ್ನೂ ತಡೆದು ಏನನ್ನೂ ವಿವರಿಸದ ಫೈರ್‌ವಾಲ್ ಬಿಟ್ಟು ಹೋಗುತ್ತದೆ.
ಯಾವ ವಿಧಾನವೂ ಇನ್ನೊಂದನ್ನು ಅನಗತ್ಯಗೊಳಿಸುವುದಿಲ್ಲ. ಸಂಪಾದನೆಯ ನಂತರ ಎಂದಿಗೂ ಮರುಲೋಡ್ ಆಗದ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಎಂದಿಗೂ ಚಲಿಸದ ಸ್ಕ್ರಿಪ್ಟ್‌ನಷ್ಟೇ ಕಾಲ್ಪನಿಕ.
ಕಂದರ ಇದೆಯೇ ಎಂದು persist-tun ನಿರ್ಧರಿಸುತ್ತದೆ
ಸುರಂಗ ಸಾಧನವು ಸಂಪರ್ಕ ಕಡಿತವನ್ನು ದಾಟಿ ಉಳಿದರೆ, ಅದರೊಳಗೆ ತೋರುವ ಮಾರ್ಗಗಳೂ ಉಳಿಯುತ್ತವೆ. ಆಗ ಸಂಚಾರವನ್ನು ಮರುನಿರ್ದೇಶಿಸುವ ಬದಲು ಬಿಟ್ಟುಬಿಡಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಭೌತಿಕ ಗೇಟ್‌ವೇಗೆ ಹಿಂತಿರುಗುವುದಿಲ್ಲ. ಯಾವುದೇ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಸೇರುವ ಮೊದಲೇ ಈ ವರ್ತನೆ ಸೋರಿಕೆಯನ್ನು ಅಸಂಭವವಾಗಿಸುತ್ತದೆ.
ಈ ಸೆಟ್ಟಿಂಗ್ ಇಲ್ಲದೆ ಸಾಧನ ಮತ್ತು ಅದರೊಂದಿಗೆ ಮಾರ್ಗಗಳು ತೆಗೆದುಹಾಕಲ್ಪಡುತ್ತವೆ, ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಮತ್ತೆ ಭೌತಿಕ ಗೇಟ್‌ವೇಗೆ ತೋರಬಹುದು. ಹಾಗೆ ಮಾಡುತ್ತದೆಯೇ ಎಂಬುದು ವೇದಿಕೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ, ಮತ್ತು ಅದಕ್ಕೇ ಸ್ಥಿತಿಯನ್ನು ಊಹಿಸದೆ ಗಮನಿಸಬೇಕು. ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು kill switch ನ ಭಾಗವೆಂದು ಪರಿಗಣಿಸಿ, ಕಾರ್ಯಕ್ಷಮತೆ ಆಯ್ಕೆಯಲ್ಲ.
ಮರುಸಂಪರ್ಕ ಮಾರ್ಗವನ್ನು ಜೀವಂತವಾಗಿಡಿ, ನಂತರ ನಾಲ್ಕು ಸ್ಥಿತಿಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ
ಕಠಿಣ ತಡೆ ಕ್ಲೈಂಟ್ ಮರುಸಂಪರ್ಕವನ್ನೂ ತಡೆಯಬಹುದು, ಏಕೆಂದರೆ ಉಳಿದೆಲ್ಲವೂ ನಿರಾಕರಿಸಲ್ಪಟ್ಟಾಗಲೂ ಕ್ಲೈಂಟ್‌ಗೆ ಭೌತಿಕ ಗೇಟ್‌ವೇ ಮೂಲಕ ಸರ್ವರ್‌ಗೆ ಮಾರ್ಗ ಬೇಕು. ಸುರಂಗ ಏರುವ ಮೊದಲು ಆ ಒಂದು ವಿಳಾಸಕ್ಕೆ ಹೋಸ್ಟ್ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸಿ, ಮತ್ತು ಮೊದಲು ಹೆಸರನ್ನು ಬಿಡಿಸಿ, ಏಕೆಂದರೆ ನಿಮಗೆ ಅದು ಬೇಕಾದ ಹೊತ್ತಿಗೆ DNS ತಡೆಯಲ್ಪಟ್ಟಿರಬಹುದು.
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0ನಂತರ ಲೇಬಲ್ ಅಲ್ಲ, ಸ್ಥಿತಿಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ನಾಲ್ಕು ಕ್ಷಣಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅನುಭವಿಸಿ: ಸುರಂಗವಿಲ್ಲದ ತಣ್ಣನೆಯ ಪ್ರಾರಂಭ, ಆರೋಗ್ಯಕರ ಅವಧಿ, ಯಾರೂ ಕೇಳದ ಕಡಿತ, ಮತ್ತು ಚೇತರಿಸಿಕೊಂಡ ನಂತರದ ಅವಧಿ. ಪ್ರತಿ ಕ್ಷಣದಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಓದಿ ಮತ್ತು ನಿರ್ಗಮನ ವಿಳಾಸ ಕಾಣುವ ಒಂದು ವಿನಂತಿ ಮಾಡಿ. ಸುರಂಗ ಕೆಳಗಿರುವಾಗ ಸೋಲೊಪ್ಪಿಕೊಳ್ಳುವ ಅಪ್ಲಿಕೇಶನ್ ಮೇಲ್ ಕ್ಲೈಂಟ್ ಅಥವಾ ಅಪ್‌ಡೇಟರ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕೊನೆಯ ಪರಿಶೀಲನೆಯನ್ನು ಒಂದು ಹಿನ್ನೆಲೆ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಪುನರಾವರ್ತಿಸಿ. ನಿಯಮ, ಇಂಟರ್ಫೇಸ್ ಹೆಸರುಗಳು ಮತ್ತು ಚೇತರಿಕೆ ಹಂತಗಳನ್ನು ಬರೆದಿಡಿ, ಏಕೆಂದರೆ ಯಾರೂ ಪರಿಶೀಲಿಸಲಾಗದ kill switch ಒಂದು ವದಂತಿ.