OpenVPN ಗೆ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಆದರೆ ಏನೂ ಲೋಡ್ ಆಗುತ್ತಿಲ್ಲ: ಕ್ಲೈಂಟ್ನಿಂದ ಹೊರಕ್ಕೆ ಒಂದು ನಡಿಗೆ

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

ಕ್ಲೈಂಟ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಹೊರಕ್ಕೆ ಸಾಗಿ

ಈ ಕ್ರಮದಲ್ಲಿ ಮೂರು ಪರೀಕ್ಷೆ ಮಾಡಿ ಮತ್ತು ಮೊದಲನೆಯದು ಎಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ. ಸರ್ವರ್ನ ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ping ಮಾಡಿ, ಅದು ಟನೆಲ್ ಸ್ವತಃ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಸಂಖ್ಯೆಯಿಂದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ping ಮಾಡಿ, ಅದು ಹೆಸರು ವಿಭಜನೆ ಇಲ್ಲದೆ ಮುಂದುಗಡೆ ಕಳುಹಿಸುವಿಕೆ ಮತ್ತು ಅನುವಾದವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ನಂತರ ಹೋಸ್ಟ್ನ ಹೆಸರನ್ನು ಬಿಡಿಸಲು ಪ್ರಯತ್ನಿಸಿ, ಅದು DNS ಬಳಸುವ ಏಕೈಕ ಪರೀಕ್ಷೆ. ಪ್ರತಿ ಫಲಿತಾಂಶವೂ ಸಂಶಯದಿಂದ ಒಂದು ಪೂರ್ಣ ಪದರವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

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

ಎರಡು ಕ್ಯಾಪ್ಚರ್ ಪ್ಯಾಕೆಟ್ಗಳು ಎಲ್ಲಿ ನಿಲ್ಲುತ್ತವೆ ಎಂದು ತೋರಿಸುತ್ತವೆ

ಕ್ಲೈಂಟ್ನಿಂದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ping ನಡೆಯುತ್ತಿರುವಾಗ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಒಂದು ಕ್ಯಾಪ್ಚರ್ ಮತ್ತು ಇಂಟರ್ನೆಟ್ ತಲುಪಬೇಕಾದ ಅಪ್ಲಿಂಕ್ನಲ್ಲಿ ಇನ್ನೊಂದು ಕ್ಯಾಪ್ಚರ್ ತೆಗೆದುಕೊಳ್ಳಿ. ಸಮಯದ ಮುದ್ರೆಗಳು ಹೊಂದಿಕೆಯಾಗಲು ಎರಡನ್ನೂ ಒಟ್ಟಿಗೆ ಓಡಿಸಿ.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

ಅಪ್ಲಿಂಕ್ನ ಹೆಸರನ್ನು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಿಂದ ತೆಗೆದುಕೊಳ್ಳಿ, ಟ್ಯುಟೋರಿಯಲ್ನಿಂದ ಅಲ್ಲ. ಕ್ಲೌಡ್ ಇಮೇಜ್ಗಳು ಮತ್ತು ಮರುನಾಮಕರಣಗೊಂಡ ಅಡಾಪ್ಟರ್ಗಳು ಮಾರ್ಗದರ್ಶಿಯ ಉದಾಹರಣೆ ಇಂಟರ್ಫೇಸ್ಗೆ ಅಪರೂಪವಾಗಿ ಹೊಂದುತ್ತವೆ, ಮತ್ತು ತಪ್ಪು ಸಾಧನದಲ್ಲಿ ತೆಗೆದ ಕ್ಯಾಪ್ಚರ್ ಫಾರ್ವರ್ಡ್ ಮಾಡದ ಸರ್ವರ್ನಂತೆಯೇ ಕಾಣುತ್ತದೆ:

ip -4 route get 9.9.9.9

ಆ ಔಟ್ಪುಟ್ನ dev ಕ್ಷೇತ್ರವು NAT ನಿಯಮಕ್ಕೆ ನಂತರ ಬೇಕಾಗುವ ಹೆಸರು, ಆದ್ದರಿಂದ ಅದನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ.

ಮುಂದುಗಡೆ ಕಳುಹಿಸುವಿಕೆ ಕರ್ನೆಲ್ನ ಸ್ವಿಚ್ ಮತ್ತು ಫೈರ್ವಾಲ್ ನೀತಿ

ಕರ್ನೆಲ್ ಮೊದಲು ಮುಂದುಗಡೆ ಕಳುಹಿಸಲು ಒಪ್ಪಬೇಕು. ಪ್ರಸ್ತುತ ಮೌಲ್ಯವನ್ನು ಓದಿ, ನಂತರ ಚಾಲನೆಯಲ್ಲಿರುವ ಕರ್ನೆಲ್ಗೆ ಮಾತ್ರ ಬರೆಯುವ ಬದಲು ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಶಾಶ್ವತ ಮಾಡಿ:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

ಮುಂದುಗಡೆ ಕಳುಹಿಸುವಿಕೆ ಅರ್ಧದಷ್ಟೇ. UFW ಬಳಸುವ ಹೋಸ್ಟ್ನಲ್ಲಿ ಫಾರ್ವರ್ಡ್ ನೀತಿ /etc/default/ufw ನಲ್ಲಿ ಸೆಟ್ ಆಗುತ್ತದೆ ಮತ್ತು ಮರುಲೋಡ್ ಜಾರಿಗೆ ಬರುವ ಮೊದಲು ಅದು ACCEPT ಆಗಿರಬೇಕು. ಫಾರ್ವರ್ಡ್ ಮಾರ್ಗದಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಡ್ರಾಪ್ ಹ್ಯಾಂಡ್ಶೇಕ್ ಅನ್ನು ಸಂಪೂರ್ಣ ಆರೋಗ್ಯವಾಗಿ ಬಿಟ್ಟು ಟನೆಲ್ನಿಂದ ಹೊರಬರಲು ಪ್ರಯತ್ನಿಸುವ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಸಾಡುತ್ತದೆ, ಮತ್ತು ಅದು ನೀವು ಪ್ರಾರಂಭಿಸಿದ ನಿಖರ ಲಕ್ಷಣ.

nftables ಅನ್ನು ನೇರವಾಗಿ ನಿರ್ವಹಿಸುವ ಹೋಸ್ಟ್ಗಳಿಗೆ ಅದೇ ಪ್ರಶ್ನೆ ಬೇರೆ ವಾಕ್ಯರಚನೆಯಲ್ಲಿ ಬರುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಪರೀಕ್ಷೆ ನಡೆಯುತ್ತಿರುವಾಗ ಫಾರ್ವರ್ಡ್ ಸರಪಳಿಯ ಕೌಂಟರ್ಗಳನ್ನು ನೋಡಿ, ಏಕೆಂದರೆ ಕೇಳಲ್ಪಡುವ ಸರಪಳಿ ಮತ್ತು ಬಿಸಾಡುವ ಸರಪಳಿ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ.

NAT ನಿಯಮದಲ್ಲಿ ನಿಜವಾದ ಎಗ್ರೆಸ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೆಸರಿಸಿ

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

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

ಸಾಂಪ್ರದಾಯಿಕ ವೈಫಲ್ಯ ಎಂದರೆ ಮಾರ್ಗದರ್ಶಿಯಿಂದ ನಕಲಿಸಿದ ನಿಯಮವು -o eth0 ಎನ್ನುತ್ತದೆ, ಆದರೆ ಆ ಯಂತ್ರದ ಅಡಾಪ್ಟರ್ ಬೇರೆ ಹೆಸರಿನಲ್ಲಿದೆ. ನಿಯಮ ಎಚ್ಚರಿಕೆ ಇಲ್ಲದೆ ಸ್ಥಾಪನೆಯಾಗುತ್ತದೆ, ಯಾವುದಕ್ಕೂ ಹೊಂದುವುದಿಲ್ಲ, ಮತ್ತು ಕ್ಲೈಂಟ್ಗೆ ಇನ್ನೂ ಇಂಟರ್ನೆಟ್ ಇಲ್ಲ. ಪೂಲ್ ಅದೇ ತಪ್ಪಿನ ಇನ್ನೊಂದು ಅರ್ಧ: ಸರ್ವರ್ 10.44.0.0/24 ನೀಡುತ್ತಿದ್ದರೆ ಮತ್ತು ನಿಯಮ 10.8.0.0/24 ಅನ್ನು ಆವರಿಸಿದರೆ, ಯಾವುದೂ ಎಂದೂ ಹೊಂದುವುದಿಲ್ಲ.

ನಿಯಮದ ಪಠ್ಯವನ್ನು ನಂಬುವ ಬದಲು ಕೌಂಟರ್ಗಳನ್ನು ನೋಡಿ. ಪಟ್ಟಿ ಪ್ರತಿ ನಿಯಮಕ್ಕೆ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಎಂದೂ ಹೊಂದದ ನಿಯಮ ಎಷ್ಟೇ ಸರಿಯಾಗಿ ಕಂಡರೂ ಶೂನ್ಯದಲ್ಲೇ ಉಳಿಯುತ್ತದೆ. ಆ ಸಂಖ್ಯೆಯಿಂದ ಏನನ್ನೂ ಓದುವ ಮೊದಲು ಅದಕ್ಕೆ ಒಂದು ನಿಮಿಷದ ನಿಜವಾದ ಕ್ಲೈಂಟ್ ಸಂಚಾರ ನೀಡಿ:

iptables -t nat -L POSTROUTING -v -n

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

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

DNS ಮೊದಲನೆಯದರ ಹಿಂದೆ ಎರಡನೆಯ ವೈಫಲ್ಯ

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

ಕ್ಲೈಂಟ್ ಎಲ್ಲಿ ಕೇಳಬೇಕೆಂದು ತಿಳಿಯಲು ಸರ್ವರ್ನಿಂದ ರಿಜಾಲ್ವರ್ ಕಳುಹಿಸಿ. ಎರಡು ನಮೂದುಗಳು ಮೊದಲನೆಯದು ತಲುಪದಿದ್ದರೆ ಕ್ಲೈಂಟ್ಗೆ ಪರ್ಯಾಯ ನೀಡುತ್ತವೆ, ಮತ್ತು ಎರಡೂ ಟನೆಲ್ ನಿಜವಾಗಿ ಅನುಮತಿಸುವ ರಿಜಾಲ್ವರ್ಗಳಾಗಿರಬೇಕು.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows ಕ್ಲೈಂಟ್ಗಳು ನಂತರವೂ ಸ್ಥಳೀಯ ರಿಜಾಲ್ವರ್ಗೆ ಮರಳಬಹುದು, ಮತ್ತು block-outside-dns ಅದನ್ನೇ ತಡೆಯಲು ಇದೆ, ಆದರೆ ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ ಮಾತ್ರ ಬಿಡಿಸಬಲ್ಲ ಹೆಸರುಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಬೆಲೆಗೆ. systemd-resolved ಬಳಸುವ Linux ಕ್ಲೈಂಟ್ಗಳು ಸ್ಕ್ರಿಪ್ಟ್ ಸ್ಥಾಪಿಸದಿದ್ದರೆ ಕಳುಹಿಸಿದ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಹೆಚ್ಚಾಗಿ ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಕಳುಹಿಸುವಿಕೆ ನಿರ್ಲಕ್ಷಿಸಲಾಗಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಟನೆಲ್ ಸಾಧನಕ್ಕಾಗಿ resolvectl status ಪರಿಶೀಲಿಸಿ.

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