nginx ಒಡೆಯುವ ಮೊದಲು OpenVPN SNAT ನಿಯಮದ ವ್ಯಾಪ್ತಿಯನ್ನು ನಿರ್ಧರಿಸಿ

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

ಕಂಟೇನರ್ tun ಸಾಧನವನ್ನು ರಚಿಸಬಲ್ಲದು ಎಂದು ಖಚಿತಪಡಿಸಿ

ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ ಇರಲು ಸಾಧ್ಯವಿಲ್ಲದಿದ್ದರೆ ಬೇರೆ ಯಾವುದೂ ಮುಖ್ಯವಲ್ಲ. /dev/net/tun ಇದೆ ಎಂದು ಮತ್ತು ಪರೀಕ್ಷಾ ಸಾಧನದ ರಚನೆ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಅನೇಕ ಪೂರೈಕೆದಾರರು ಕಂಟೇನರ್ಗಳ ಒಳಗೆ tun ಅನ್ನು ಡಿಫಾಲ್ಟ್ ಆಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತಾರೆ. ಎಂದಿಗೂ ರಚಿಸದ ಸಾಧನವನ್ನು ಯಾವುದೇ firewall ಕೆಲಸ ಸರಿದೂಗಿಸುವುದಿಲ್ಲ.

ಸಾಧನ ಇಲ್ಲದಿದ್ದರೆ, ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು ಹೋಸ್ಟ್ ಅಥವಾ ಪೂರೈಕೆದಾರರಿಗೆ ಮಾತ್ರ. ಒಂದು ವಾರ ಇರುವ ತೆರೆದ ಬೆಂಬಲ ಥ್ರೆಡ್ಗಿಂತ ಬೇರೆ ಯೋಜನೆ ಹೆಚ್ಚಾಗಿ ಅಗ್ಗವಾಗಿರುತ್ತದೆ. OpenVPN ಲಾಗ್ನ ಒಂದು ಸಾಲನ್ನೂ ಓದುವ ಮೊದಲು ಇದನ್ನು ಖಚಿತಪಡಿಸಿ. ಇಲ್ಲದಿದ್ದರೆ ಎಂದಿಗೂ ಪ್ಯಾಕೆಟ್ ನೋಡದ ನಿಯಮಗಳನ್ನು ಟ್ಯೂನ್ ಮಾಡುವುದರಲ್ಲಿ ಸಂಜೆಯನ್ನು ಕಳೆಯುತ್ತೀರಿ.

ಈ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ MASQUERADE ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ

ಸಾಮಾನ್ಯ ವರ್ಚುವಲ್ ಯಂತ್ರದಲ್ಲಿ ಸಾಮಾನ್ಯ ಹೊರಹೋಗುವ ನಿಯಮ ಮುಖ್ಯ ಇಂಟರ್ಫೇಸ್ನಿಂದ POSTROUTING MASQUERADE ಆಗಿರುತ್ತದೆ. OpenVZ ಕಂಟೇನರ್ನಲ್ಲಿ ಕಾಣುವ ಸಾಧನ ಸಾಮಾನ್ಯವಾಗಿ venet0, ಅಂದರೆ ಹೋಸ್ಟ್ ನಿರ್ವಹಿಸುವ ವರ್ಚುವಲ್ ಇಂಟರ್ಫೇಸ್, ಮಾರ್ಗವಾದ NIC ಅಲ್ಲ, ಮತ್ತು MASQUERADE ಅಲ್ಲಿ ಟ್ಯುಟೋರಿಯಲ್ಗಳು ಊಹಿಸಿದಂತೆ ಯಾವಾಗಲೂ ವರ್ತಿಸುವುದಿಲ್ಲ.

ಕೆಲಸ ಮಾಡುವ ರೂಪವೆಂದರೆ ಕ್ಲೈಂಟ್ಗಳು ಈಗಾಗಲೇ ತಲುಪುವ ವಿಳಾಸಕ್ಕೆ ಸ್ಪಷ್ಟ ಭಾಷಾಂತರ, ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಮುಂದುವರಿಸುವಿಕೆಗೆ ಅನುಮತಿ ನೀಡುವುದು. ಸರ್ವರ್ ಸಂರಚನೆಯಿಂದ ಪೂಲ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು ವಿಳಾಸವನ್ನು ಬದಲಾಯಿಸುವಷ್ಟೇ ಮುಖ್ಯ. ಅಂಟಿಸುವ ಮೊದಲು ಪ್ರತಿ ಸಾಲನ್ನು ಓದಿ.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ಮುಂದುವರಿಸುವ ನಿಯಮಗಳಿಲ್ಲದೆ ಭಾಷಾಂತರ ಇನ್ನೂ ನಡೆಯುತ್ತದೆ ಮತ್ತು ಕರ್ಣಲ್ ಇನ್ನೂ ಮುಂದುವರಿಸಲು ನಿರಾಕರಿಸುತ್ತದೆ. ಈ ಸಂಯೋಜನೆಯು NAT ನಿಯಮದ ಕೌಂಟರ್ಗಳು ಏರುವಾಗ ಕ್ಲೈಂಟ್ಗೆ ಏನೂ ಸಿಗದ ಗೊಂದಲಮಯ ಸ್ಥಿತಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಎರಡೂ FORWARD ಸಾಲುಗಳು ಸಹ ಅದೇ ಸರಪಳಿಯಲ್ಲಿ ಯಾವುದೇ ವಿಶಾಲ drop ನಿಯಮಕ್ಕಿಂತ ಮೊದಲು ಇರಬೇಕು. ಕ್ರಮ ಸಂರಚನೆಯ ಭಾಗವೇ ಹೊರತು ಅನುಷ್ಠಾನದ ವಿವರವಲ್ಲ.

ನಿಯಮವನ್ನು ಒಂದು ಪೂಲ್ ಮತ್ತು ಒಂದು ಇಂಟರ್ಫೇಸ್ಗೆ ಸೀಮಿತಗೊಳಿಸಿ

ಎರಡನೆಯ ಲಕ್ಷಣಕ್ಕೆ ಬೇರೆ ಕಾರಣವಿದೆ: ಮೂಲ ಅಥವಾ ಔಟ್ಪುಟ್ ನಿರ್ಬಂಧವಿಲ್ಲದ POSTROUTING ನಿಯಮ. ಅಂತಹ ನಿಯಮ ಹೋಸ್ಟ್ ಬಿಡುವ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ.

ಮೂಲ ಮೂಲಾಧಾರವನ್ನು ಅವಲಂಬಿಸಿರುವ ಸೇವೆಗಳು ನಂತರ ತಪ್ಪಾಗಿ ವರ್ತಿಸುತ್ತವೆ. ಸ್ಥಳೀಯ ಪ್ರಾಕ್ಸಿಯ ಹಿಂದಿನ ವೆಬ್ ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಬಹುದು, ಮತ್ತು ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದರೂ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ ಏಕೆಂದರೆ ನಿಯಮ ಇನ್ನೂ ಮಾರ್ಗದಲ್ಲಿದೆ. ಹೋಸ್ಟ್ ತನ್ನದೇ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸುವ ಸಂಚಾರವೂ ಬಾಧಿತವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ವೈಫಲ್ಯ firewall ನ ಬದಲು DNS ಅಥವಾ ಪ್ರಮಾಣಪತ್ರದ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣಬಹುದು. ನಿಯಮವನ್ನು ಮೊದಲ ಲಕ್ಷಣವನ್ನು ಸರಿಪಡಿಸಲು ಸೇರಿಸಿರುವುದು ಬಹುತೇಕ ಖಚಿತ.

ಪರಿಹಾರವೆಂದರೆ ಹೊಂದಿಕೆಯನ್ನು ಸುರಂಗ ಪೂಲ್ ಮತ್ತು ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್ಗೆ ಸಂಕುಚಿತಗೊಳಿಸಿ, ನಂತರ ಹಲವನ್ನು ಆವರಿಸಲು ಒಂದು ನಿಯಮವನ್ನು ಅಗಲಿಸುವ ಬದಲು ಪ್ರತಿ ಪೂಲ್ಗೆ ಒಂದು ನಿಯಮ ಸೇರಿಸುವುದು.

ನಿಯಮಗಳನ್ನು ಶಾಶ್ವತಗೊಳಿಸಿ ಮತ್ತು ಅವುಗಳನ್ನು ಇನ್ನಾರು ಹೊಂದಿದ್ದಾರೆ ಎಂದು ತಿಳಿಯಿರಿ

ಕೈಯಿಂದ ಸೇರಿಸಿದ ನಿಯಮಗಳು ಮರುಬೂಟ್ನಲ್ಲಿ ಮಾಯವಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು iptables-save ನಿಂದ ಉಳಿಸಿ ಅಥವಾ ಅದು ಸ್ಥಾಪಿತವಾಗಿರುವಲ್ಲಿ netfilter-persistent ಮೂಲಕ ನಿರ್ವಹಿಸಿ. ಮರುಸ್ಥಾಪನೆ OpenVPN ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಚಲಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ನಂತರ ಘಟನೆಯ ಸಮಯದಲ್ಲಿ ಕೊರತೆಯನ್ನು ಕಂಡುಹಿಡಿಯುವ ಬದಲು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಒಮ್ಮೆ ಮರುಬೂಟ್ ಮಾಡಿ.

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

ಕೌಂಟರ್ಗಳು ಮತ್ತು ಒಂದು ಸೆರೆಹಿಡಿಯಲಾದ ಹರಿವಿನಿಂದ ಪರಿಶೀಲಿಸಿ

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

ಸರ್ವರ್ನಲ್ಲಿ iptables -t nat -L -v -n ನಿಂದ NAT ಮತ್ತು FORWARD ನಿಯಮಗಳ ಮೇಲಿನ ಪ್ಯಾಕೆಟ್ ಕೌಂಟರ್ಗಳನ್ನು ಓದಿ ಮತ್ತು ಸೆರೆಹಿಡಿಯುವಿಕೆಯಲ್ಲಿ ಒಂದು ಹರಿವನ್ನು ಗಮನಿಸಿ. ಸೆರೆಹಿಡಿಯುವಿಕೆಯಲ್ಲಿ ಕ್ಲೈಂಟ್ನ ವಿಳಾಸ ಕಾಣಿಸಿಕೊಂಡು ಪ್ರತಿಕ್ರಿಯೆ ಬರದಿದ್ದರೆ, ಕೊರತೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗದಲ್ಲಿ ಅಥವಾ ಪೂರೈಕೆದಾರರ ಫಿಲ್ಟರಿಂಗ್ನಲ್ಲಿದೆ, ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ನಲ್ಲಿಲ್ಲ. ಸೆರೆಹಿಡಿದ ಮೂಲವನ್ನು ನಿಯಮ ಭಾಷಾಂತರಿಸುವ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ, ಏಕೆಂದರೆ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲ ಎಂದರೆ ಬೇರೆ ನಿಯಮ ಮೊದಲು ಹೊಂದಿಕೆಯಾಯಿತು. ಗಮನಿಸಿದ ಒಂದು ಹರಿವು ಸಂರಚನೆಯ ಒಂದು ಪುಟ ಓದುವುದಕ್ಕಿಂತ ಹೆಚ್ಚನ್ನು ನಿರ್ಣಯಿಸುತ್ತದೆ.

ಪೂಲ್, ಭಾಷಾಂತರಿಸಿದ ವಿಳಾಸ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ನ ಹೆಸರನ್ನು ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ಒಟ್ಟಿಗೆ ಇರಿಸಿ. ಒಂದು ಪೂಲ್ಗೆ ಸರಿಯಾದ ನಿಯಮ ಮುಂದಿನದನ್ನು ತಪ್ಪಾಗಿ ಭಾಷಾಂತರಿಸುತ್ತದೆ.