VPN ಮಾತ್ರ ಇರುವ iptables ಹೋಸ್ಟ್: tun ಸಾಧನವನ್ನು ಹೆಸರಿಸಿ, tun+ ಅಲ್ಲ
tun+ ಯಂತ್ರದ ಪ್ರತಿಯೊಂದು ಸುರಂಗಕ್ಕೂ ಹೊಂದುತ್ತದೆ. ಒಂದು ಸಾಧನ ಹೆಸರನ್ನು ಸ್ಥಿರಗೊಳಿಸಿ, endpoint ಅಪವಾದವನ್ನು ಮೊದಲು ಇರಿಸಿ ಮತ್ತು ನೀತಿಯನ್ನು ಪರೀಕ್ಷಿಸುವಾಗ ಮರುಸ್ಥಾಪನೆ ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ.
-o tun+ ಬರೆಯುವುದು ನಿಖರವಾದ ಸೂಚನೆಯಂತೆ ತೋರುತ್ತದೆ ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಇದು ಕರ್ನೆಲ್ ಹೊಂದಿರುವ ಪ್ರತಿಯೊಂದು ಸುರಂಗಕ್ಕೂ ಹೊಂದುವ ವೈಲ್ಡ್ಕಾರ್ಡ್ ಆಗಿದೆ. ಎರಡನೇ VPN ಕ್ಲೈಂಟ್, ಒಂದು ಕಂಟೇನರ್ ಸೇತುವೆ ಅಥವಾ ಕ್ರ್ಯಾಶ್ ಆದ ಅವಧಿಯಿಂದ ಉಳಿದ ಇಂಟರ್ಫೇಸ್ — ಎಲ್ಲವೂ ಅದನ್ನು ಪೂರೈಸುತ್ತವೆ, ಮತ್ತು ಹೋಸ್ಟ್ ನಂತರ ನೀತಿ ತಡೆಯಬೇಕಿದ್ದ ಸಂಚಾರಕ್ಕೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ. ಕೆಳಗಿನ ಕಾರ್ಯವಿಧಾನ ಒಂದು ಸಾಧನ ಹೆಸರನ್ನು ಸ್ಥಿರಗೊಳಿಸುತ್ತದೆ, ಸುರಂಗ ನಿಜವಾಗಿಯೂ ರೂಪುಗೊಳ್ಳುವಂತೆ ಅಪವಾದಗಳನ್ನು ಜೋಡಿಸುತ್ತದೆ ಮತ್ತು ನಿಯಮಗಳು ಕೆಟ್ಟದಾಗಿ ಬಿದ್ದರೆ ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಬಿಡುತ್ತದೆ. ಪ್ರತಿ ಹಂತವೂ ಸ್ವತಂತ್ರವಾಗಿ ರದ್ದುಮಾಡಬಹುದಾದಷ್ಟು ಚಿಕ್ಕದಾಗಿದೆ.
ಹಂತ 1: ಈಗ ಇರುವ ನಿಯಮಗಳನ್ನು ದಾಖಲಿಸಿ
ಡೀಫಾಲ್ಟ್ ನೀತಿಯನ್ನು ಬದಲಿಸುವ ಮೊದಲು ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಉಳಿಸಿ, ಇದರಿಂದ ರೋಲ್ಬ್ಯಾಕ್ ನೆನಪಲ್ಲ ಬದಲು ಆದೇಶವಾಗುತ್ತದೆ. iptables-save > /root/iptables.pre ಪ್ರತಿ ಕೋಷ್ಟಕವನ್ನು ನೀವು ಮರುಸ್ಥಾಪಿಸಬಹುದಾದ ಫೈಲ್ಗೆ ಬರೆಯುತ್ತದೆ, ಮತ್ತು ನೀವು ಹೊಂದಿಸಲಿರುವ ನೀತಿಯು ಅದನ್ನು ಹೊತ್ತೊಯ್ಯುವ ಸಂಪರ್ಕವನ್ನು ಕಡಿತಗೊಳಿಸಿದಾಗ root ಅವಧಿ ತೆರೆದಿರುವ ಎರಡನೇ ಟರ್ಮಿನಲ್ ಅತಿಯಾದ ಭಯವಲ್ಲ. ನೀವು ದೂರದಿಂದ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ಡೆಡ್ ಮ್ಯಾನ್ ಸ್ವಿಚ್ ಆಗಿ flush ಕೂಡ ನಿಗದಿಪಡಿಸಿ.
ನಂತರ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ, ಏಕೆಂದರೆ ನೀವು ಊಹಿಸಿದ ಹೆಸರು ನೀವು ಓದಬೇಕಾಗಿದ್ದ ಹೆಸರು: ip -br link ಈಗ ಏನಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಸುರಂಗ ಮೇಲೇಳುವವರೆಗೆ ಕಾಣಿಸುವುದಿಲ್ಲ. ಓದುವಾಗಲೇ ಸಾಧನಗಳ ಹೆಸರುಗಳನ್ನು ಬರೆದಿಟ್ಟುಕೊಳ್ಳಿ.
ಹಂತ 2: ಸುರಂಗಕ್ಕೆ ಅದರದೇ ಹೆಸರು ಕೊಡಿ
OpenVPN ಕ್ಲೈಂಟ್ ಸಂರಚನೆಯಲ್ಲಿ dev tun_work ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ನಂತರ Linux tun0 ಹಂಚಿಕೆ ಮಾಡುವ ಬದಲು ಅದೇ ಹೆಸರಿನ ಇಂಟರ್ಫೇಸ್ ರಚಿಸುತ್ತದೆ. ಬೇರೆ ಯಾವುದೂ ಅದನ್ನು ಕೇಳದಿರುವವರೆಗೆ ಹೆಸರು ಮರುಸಂಪರ್ಕಗಳ ನಡುವೆ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ, ಮತ್ತು ಸಾಧನವನ್ನು ಹೆಸರಿಸುವ ನಿಯಮವನ್ನು ಅರ್ಥಪೂರ್ಣವಾಗಿಸುವುದು ಅದೇ.
ಹೆಸರನ್ನು ನಿಯಂತ್ರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದಲ್ಲಿ, ಬದಲಿಗೆ ಸುರಂಗದ ವಿಳಾಸ ಅಥವಾ ಪ್ಯಾಕೆಟ್ ಗುರುತಿಗೆ ಹೊಂದಿಸಿ. ಎರಡೂ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಎರಡೂ ಓದಲು ಕಷ್ಟ, ಮತ್ತು ಸುರಂಗ ಮರುಸಂಖ್ಯೆಯಾದಾಗ ಎರಡೂ ಹೆಚ್ಚು ನಿಶ್ಶಬ್ದವಾಗಿ ವಿಫಲವಾಗುತ್ತವೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಒಂದೇ ವಿಷಯಕ್ಕೆ ಹೊಂದಿಸಿ ಮತ್ತು ಯಾವುದು ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಿ.
ಹಂತ 3: endpoint ಅಪವಾದವನ್ನು ಮೊದಲು ಇರಿಸಿ ನೀತಿ ಬರೆಯಿರಿ
VPN ಮಾತ್ರ ಇರುವ ಹೋಸ್ಟ್ ಎಂದರೆ ಸಣ್ಣ ಅಪವಾದ ಪಟ್ಟಿಯೊಂದಿಗೆ ಡೀಫಾಲ್ಟ್-ನಿರಾಕರಣೆ ಹೋಸ್ಟ್, ಮತ್ತು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ಅಪವಾದ ಸುರಂಗವನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರಲು ಬಿಡುವುದು. ಸುರಂಗ-ಸಾಧನದ ನಿಯಮಕ್ಕಿಂತ ಮೊದಲು endpoint ನಿಯಮವನ್ನು ಇರಿಸಿ, ಈ ಕ್ರಮದಲ್ಲಿ ಅದನ್ನು ನಿರ್ಮಿಸಿ, ಇದರಿಂದ ಕೈಕುಲುಕು ಹೋಗಲು ಸ್ಥಳ ಸಿಗುತ್ತದೆ:
# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT -i tun_work -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTendpoint ನ ಅಕ್ಷರಶಃ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ನಿಮ್ಮ ಪೂರೈಕೆದಾರರಿಗೆ ಸೇರಿದ್ದು, ಈ ಪುಟಕ್ಕಲ್ಲ. endpoint ಹೋಸ್ಟ್ಹೆಸರಾಗಿದ್ದರೆ, ಒಮ್ಮೆ ಅದನ್ನು ಪರಿಹರಿಸಿ ಫಲಿತಾಂಶವನ್ನು ಸ್ಥಿರಗೊಳಿಸಿ, ಏಕೆಂದರೆ ನಿಯಮವು ಹೆಸರನ್ನು ಹುಡುಕಲಾರದು ಮತ್ತು ತಿರುಗುವ ಉತ್ತರವು ಮುಂದಿನ DNS ಬದಲಾವಣೆಯ ನಂತರ ನೀತಿಯನ್ನು ನಿಶ್ಶಬ್ದವಾಗಿ ಮುರಿಯುತ್ತದೆ. ಪೋರ್ಟ್ ಕೂಡ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ನಿಮ್ಮನ್ನು TCP 443 ಗೆ ಸ್ಥಳಾಂತರಿಸುವ ಪೂರೈಕೆದಾರರಿಗೆ ಇಲ್ಲದಿದ್ದರೆ ಯಾರೂ ಬರೆಯದ ನಿಯಮ ಬೇಕಾಗುತ್ತದೆ. ಒಂದೇ ಪ್ರೋಟೋಕಾಲ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಸುರಂಗ ಸಾಮಾನ್ಯವಾಗಿ ಈ ಕೊರತೆಯೇ, ಫೈರ್ವಾಲ್ ದೋಷವಲ್ಲ.
ರೌಟರ್ನಲ್ಲಿ ಅದೇ ಆಕಾರ ಅದರ ಹಿಂದಿನ ಕ್ಲೈಂಟ್ಗಳಿಗಾಗಿ FORWARD ಸರಪಳಿಗೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು ರೌಟರ್ನ ಸ್ವಂತ ಸಂಚಾರಕ್ಕೆ ಸ್ವಂತ ನಿಯಮಗಳು ಬೇಕು. ಕೇವಲ ಮುಂದಕ್ಕೆ ರವಾನೆಯಾದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಆವರಿಸುವ ನಿಯಮಸಮೂಹ SSH ಮತ್ತು DNS ಅನ್ನು ಹಳೆಯ ಮಾರ್ಗದಲ್ಲೇ ಬಿಡುತ್ತದೆ, ಮತ್ತು ಸುರಂಗ ಮೇಲೇಳುವ ಕ್ಷಣದಲ್ಲಿ ರೌಟರ್ ತಲುಪಲಾಗದಂತಾಗುವುದು ಹೀಗೇ.
ಹಂತ 4: ಕ್ರಮವನ್ನು ಪರಿಶೀಲಿಸಿ, ಕೇವಲ ಇರುವಿಕೆಯನ್ನಲ್ಲ
ನಿಯಮಗಳನ್ನು ಅನುಕ್ರಮವಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೊದಲು ಬರುವ ACCEPT ನಂತರ ಸೇರಿಸಿದ REJECT ಅನ್ನು ಸುಮ್ಮನೆ ಮರೆಮಾಡುತ್ತದೆ. established ಮತ್ತು related ಹೊಂದಾಣಿಕೆಯೇ ಸಾಮಾನ್ಯ ಒಳಬರುವ ಮಾರ್ಗ ತೆರೆಯದೆ ನಿಮ್ಮ ಸ್ವಂತ ಹೊರಹೋಗುವ ವಿನಂತಿಗಳಿಗೆ ಉತ್ತರಗಳು ಹಿಂತಿರುಗಲು ಬಿಡುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ಸುರಂಗದ ಸ್ವೀಕೃತಿಯ ನಂತರ ಇರಿಸಿದರೆ ಬಿದ್ದ ಸುರಂಗವೂ ತನ್ನ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಹಿಂತಿರುಗುವ ಸಂಚಾರವನ್ನು ಇನ್ನೂ ದಾಟಿಸುತ್ತದೆ.
ನಿಯಮಗಳ ಸಂಖ್ಯೆಯನ್ನು ಒಂದು ಪರದೆಯಲ್ಲಿ ಓದಬಹುದಾದಷ್ಟು ಚಿಕ್ಕದಾಗಿ ಇಡಿ. ನೀವು ಆಡಿಟ್ ಮಾಡಲಾಗದ ನಿಯಮಸಮೂಹವೇ ನೀವು ಮೇಲೆ ಅಪವಾದ ಸೇರಿಸಿ ಪ್ಯಾಚ್ ಮಾಡುವಂಥದ್ದು, ಮತ್ತು ಡೀಫಾಲ್ಟ್-ನಿರಾಕರಣೆ ನೀತಿಗಳು ನಿಧಾನವಾಗಿ ಡೀಫಾಲ್ಟ್-ಅನುಮತಿಯ ಅಂಚನ್ನು ಪಡೆಯುವುದು ಹೀಗೇ. ಬದಲಾವಣೆಯ ಮೊದಲು ಮತ್ತು ನಂತರ ACCEPT ಎಣಿಸಿ.
ಹಂತ 5: ಬೂಟ್ ಮತ್ತು ವಿಳಾಸ ಕುಟುಂಬ ಎರಡನ್ನೂ ದಾಟಿ ಉಳಿಯುವಂತೆ ಮಾಡಿ
ಕೈಯಿಂದ ನಮೂದಿಸಿದ ನಿಯಮಗಳು ಮರುಬೂಟ್ನಲ್ಲಿ ಮಾಯವಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವನ್ನು ವಿತರಣೆಯ ಫೈರ್ವಾಲ್ ಸೇವೆ ಅಥವಾ ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ ಇದ್ದ ನಂತರ ಚಲಿಸುವ unit ನಿಂದ ಲೋಡ್ ಮಾಡಿ. OpenVPN ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಚಲಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್ನಲ್ಲಿ tun_work ಅನ್ನು ಉಲ್ಲೇಖಿಸುವುದು ಬಿದ್ದ ಸಂಚಾರದ ಬೂಟ್ ಲೂಪ್ ರಚಿಸುವ ಸಾಮಾನ್ಯ ಮಾರ್ಗ.
ನಂತರ IPv6 ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ IPv4 ಗೆ ಉತ್ತಮ ಡೀಫಾಲ್ಟ್-ನಿರಾಕರಣೆ ನೀತಿ ಇನ್ನೊಂದು ಕುಟುಂಬದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ip -6 route ಕೇವಲ IPv4 ನಿರ್ವಹಿಸುವ ಸುರಂಗವನ್ನು ಸುತ್ತಿಕೊಂಡು ಸಂಚಾರ ಸಾಗಿಸಬಲ್ಲ ಮಾರ್ಗ ಹೋಸ್ಟ್ಗೆ ಇದೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ip6tables ಅಥವಾ nftables ಗೆ ತನ್ನದೇ ಸಮಾನ ನಿಯಮಗಳು ಬೇಕು. ನಿಯಮಸಮೂಹದ ಸಮಮಿತಿಯನ್ನು ನಂಬುವ ಬದಲು IPv6-only ಗಮ್ಯಸ್ಥಾನದೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ.
ಹಂತ 6: ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಮರುಸ್ಥಾಪಿಸಲು ಸಿದ್ಧರಾಗಿರಿ
ಸುರಂಗವನ್ನು ಮೇಲೆತ್ತಿ, ನೀವು ಉದ್ದೇಶಿಸಿದ ಸೇವೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ನೀತಿ ನಿರಾಕರಿಸಬೇಕಾದ ಯಾವುದನ್ನಾದರೂ ಪ್ರಯತ್ನಿಸಿ. ಉತ್ತರ ನಿಮ್ಮನ್ನು ಬೆಚ್ಚಿಬೀಳಿಸಿದರೆ iptables-restore < /root/iptables.pre ನಿಂದ ಮರುಸ್ಥಾಪಿಸಿ, ಮತ್ತು ಆಮೇಲೆಯೇ ನಿಯಮಗಳನ್ನು ಸಂಪಾದಿಸಲು ಪ್ರಾರಂಭಿಸಿ. ಸ್ಥಿರತೆ ಜೊತೆಗೆ ಪರೀಕ್ಷಿಸಿದ ಮರುಸ್ಥಾಪನೆ ಮಾರ್ಗವೇ ಇದನ್ನು ನೀವು ಎರಡು ಬಾರಿ ಮಾಡಬಹುದಾದ ಬದಲಾವಣೆಯಾಗಿಸುತ್ತದೆ.