VPN ಬಿದ್ದಾಗ ಏನೂ ಸೋರಿಕೆಯಾಗದಂತೆ Linux ನ ನಿರ್ಗಮನವನ್ನು ಹೇಗೆ ಲಾಕ್ ಮಾಡುವುದು

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

ಸ್ಥಳೀಯ ಔಟ್ಪುಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ಗಿಂತ ಬೇರೆ ಹುಕ್

ಯಂತ್ರದಲ್ಲಿನ ಅಪ್ಲಿಕೇಶನ್ನಿಂದ ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್ ಔಟ್ಪುಟ್ ಹುಕ್ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ; ಯಂತ್ರವು ಇನ್ನೊಂದು ಹೋಸ್ಟ್ಗಾಗಿ ರೂಟ್ ಮಾಡುವ ಪ್ಯಾಕೆಟ್ ಫಾರ್ವರ್ಡ್ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ. ಕೇವಲ forward ಅನ್ನು ಉಲ್ಲೇಖಿಸುವ ನೀತಿ ಎರಡನೆಯದನ್ನು ಮಿತಿಗೊಳಿಸಿ ಮೊದಲನೆಯದನ್ನು ಸಂಪೂರ್ಣ ತೆರೆದಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅನೇಕ ನಿರ್ಗಮನ ಲಾಕ್ಗಳು ಸರಿಯಾಗಿ ಕಾಣುತ್ತವೆ ಮತ್ತು ಏನೂ ಮಾಡುವುದಿಲ್ಲ. ಇಂಟರ್ಫೇಸ್ ಹೊಂದಾಣಿಕೆ ಅದೇ ನಿಯಮಕ್ಕೆ ಸೇರುತ್ತದೆ: oifname "tun0" accept ಈಗಾಗಲೇ ಟನೆಲ್ ಮೂಲಕ ರೂಟ್ ಆದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹಾದುಹೋಗಲು ಬಿಡುತ್ತದೆ. ರೂಟಿಂಗ್ ಮತ್ತು ಫಿಲ್ಟರಿಂಗ್ ಕೂಡ ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರಗಳಾಗಿ ಉಳಿಯುತ್ತವೆ, ಆದ್ದರಿಂದ ಫಿಲ್ಟರ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ನಿರಾಕರಿಸುತ್ತಿರುವಾಗಲೂ ಅಪ್ಲಿಂಕ್ ರೂಟ್ ಇರಬಹುದು. ನೀವು ಅವಲಂಬಿಸಿರುವುದು ಈ ಬೇರ್ಪಡಿಕೆಯನ್ನೇ.

ಇತರ ಸಾಧನಗಳಿಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಗೇಟ್ವೇಗೆ ಎರಡೂ ಹುಕ್ ಬೇಕು. ಕೇವಲ ಔಟ್ಪುಟ್ ಲಾಕ್ ಮಾಡುವುದು ಯಂತ್ರವನ್ನೇ ರಕ್ಷಿಸಿ, ಕೆಳಗಿನ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಸೋರಿಕೆಗೆ ಸ್ವತಂತ್ರವಾಗಿ ಬಿಡುತ್ತದೆ.

ವಿನಾಯಿತಿಗಳ ಪಟ್ಟಿಯನ್ನು ಎಂಡ್ಪಾಯಿಂಟ್ನಿಂದ ಹೊರಕ್ಕೆ ಬರೆಯಿರಿ

ಟನೆಲ್ನ ಎಂಡ್ಪಾಯಿಂಟ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ: ಒಂದು ಗಮ್ಯಸ್ಥಾನ ವಿಳಾಸ ಅಥವಾ ಸಣ್ಣ ಅನುಮೋದಿತ ಗುಂಪು, ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್, ಉದಾಹರಣೆಗೆ udp dport 1194 ip daddr 203.0.113.7 accept. ಕ್ಲೈಂಟ್ ಹೋಸ್ಟ್ಹೆಸರನ್ನು ಪರಿಹರಿಸಿದರೆ, ಆರಂಭಿಕ DNS ವಿನಿಮಯಕ್ಕೆ ತನ್ನದೇ ನಿಯಮ ಬೇಕು, ಅದು ರಿಸಾಲ್ವರ್ ಮತ್ತು ಪೋರ್ಟ್ 53 ಗೆ ಸೀಮಿತವಾಗಿರಬೇಕು, ಆ ರಿಸಾಲ್ವರ್ನ ವಿಳಾಸಕ್ಕೆ ಸಾರ್ವತ್ರಿಕ ಅನುಮತಿ ಅಲ್ಲ. ಪ್ರತಿ ವಿನಾಯಿತಿಯೂ ತಾನು ಇರುವ ಕಾರಣವನ್ನು ಹೇಳಬೇಕು. VPN ಪೋರ್ಟ್ಗೆ ಎಲ್ಲಾ UDP ಟ್ರಾಫಿಕ್ಗೆ ಅನುಮತಿ ನೀವು ಉದ್ದೇಶಿಸಿದ್ದ ಒಂದೇ ದೃಢೀಕೃತ ಸೇವೆಗಿಂತ ಬಹಳ ಹೆಚ್ಚಿನದನ್ನು ಆವರಿಸುತ್ತದೆ.

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

ಸ್ಥಳೀಯ ನಿರ್ವಹಣೆಗೂ ಅದೇ ನಡವಳಿಕೆ ಬೇಕು. ನಿರ್ವಹಣಾ ಸಬ್ನೆಟ್ ಕೇವಲ ಅದರ ವಿಳಾಸಗಳು ಖಾಸಗಿ ಎಂಬ ಕಾರಣಕ್ಕೆ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ, ಮತ್ತು ಅದನ್ನು ನಂಬುವ ನಿಯಮ ಲಾಕ್ನ ಸುತ್ತ ಎರಡನೇ ದಾರಿಯನ್ನು ಆಹ್ವಾನಿಸುತ್ತದೆ.

ಇಂಟರ್ಫೇಸ್ ಹೊಂದಾಣಿಕೆ ಆರೋಗ್ಯಕರ ಟನೆಲ್ನ ಸಾಕ್ಷ್ಯವಲ್ಲ

tun0 ನಿಂದ ಹೊರಬರುವ ಎಲ್ಲವನ್ನೂ ಸ್ವೀಕರಿಸುವ ನಿಯಮಗಳು ಆ ಇಂಟರ್ಫೇಸ್ನ ಪ್ಯಾಕೆಟ್ ಟನೆಲ್ನಿಂದ ಬಂದಿದೆ ಎಂದು ಊಹಿಸುತ್ತವೆ. ಇಂಟರ್ಫೇಸ್ ಹೆಸರುಗಳು ಮತ್ತೆ ಸೃಷ್ಟಿಯಾಗುತ್ತವೆ, ಮತ್ತು ಹೆಸರು ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಗುರುತಲ್ಲ. ಇಂಟರ್ಫೇಸ್ ಮೇಲಿರುವಾಗಲೇ ಪೀರ್ ಹೋಗಿರಬಹುದು, ಇದು ನಿಯಮವನ್ನು ಬಹಳ ನಂಬಿಕಾರ್ಹ ನಿಷ್ಕ್ರಿಯತೆಯಾಗಿಸುತ್ತದೆ.

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

ಡೀಮನ್ ಕ್ರ್ಯಾಶ್ನಿಂದ ಏನು ಉಳಿಯುತ್ತದೆ

ಟನೆಲ್ ಮೇಲೆ ಬಂದ ನಂತರ ಚಲಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್ ಸ್ಥಾಪಿಸುವ ಫಿಲ್ಟರ್ ಟನೆಲ್ನೊಂದಿಗೇ ಮಾಯವಾಗುತ್ತದೆ, ಅದು ಬೇಕಿದ್ದ ಕ್ಷಣದಲ್ಲೇ. ಲಾಕ್ ಅನ್ನು ಬೂಟ್ನಲ್ಲಿ ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಡೀಮನ್ಗೆ ಅದರ ವಿನಾಯಿತಿಗಳನ್ನಷ್ಟೇ ನಿರ್ವಹಿಸಲು ಬಿಡಿ.

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

ನಿಯೋಜನೆಗೆ ಮೊದಲು ಚೇತರಿಕೆಯ ದಾರಿ

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

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