PiVPN ಹ್ಯಾಂಡ್ಶೇಕ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಪುಟಗಳು ನಿಲ್ಲುತ್ತವೆ: MASQUERADE ಪರಿಶೀಲಿಸಿ

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

ಕ್ಲೈಂಟ್ ಏನನ್ನು ತಲುಪಬಲ್ಲದು ಮತ್ತು ಏನನ್ನು ತಲುಪಲಾರದು ಎಂಬುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ನಿಂದ, ಸಾರ್ವಜನಿಕ ಇಂಟರ್ನೆಟ್ನಲ್ಲಿರುವ ಪುಟವನ್ನು ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಅದು ತಕ್ಷಣ ವಿಫಲವಾಗುತ್ತದೆಯೇ ಅಥವಾ ಮಧ್ಯದಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆಯೇ ಎಂದು ಗಮನಿಸಿ. ನಂತರ VPN ಸರ್ವರ್ನ ಸ್ವಂತ ಖಾಸಗಿ ವಿಳಾಸದಲ್ಲಿ ಸಂಪನ್ಮೂಲವನ್ನು ತೆರೆದು ಎರಡು ಫಲಿತಾಂಶಗಳನ್ನು ಹೋಲಿಸಿ.

ಸಾರ್ವಜನಿಕ ಸೈಟ್ಗಳು ಸಮಯ ಮೀರಿದಾಗಲೂ ping-ಗೆ ಉತ್ತರಿಸುವ ಟನೆಲ್ ವಿಳಾಸವು ಫಾರ್ವರ್ಡಿಂಗ್ ಅಥವಾ ಅನುವಾದದ ಸಮಸ್ಯೆಯ ಲಕ್ಷಣವೇ ಹೊರತು ಮುರಿದ ಹ್ಯಾಂಡ್ಶೇಕ್ನದ್ದಲ್ಲ. ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಸ್ಥಿತಿ ಪ್ಯಾನೆಲ್ ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸಲಾರದು, ಏಕೆಂದರೆ ನಿಯಂತ್ರಣ ಚಾನೆಲ್ ಮೇಲಿದೆ ಎಂದಷ್ಟೇ ಅದಕ್ಕೆ ಗೊತ್ತು. ಸರ್ವರ್ನಲ್ಲಿ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಇದರಿಂದ ಪರಿಶೀಲಿಸಿ: ip -br addr show tun0 ಮತ್ತು ಕ್ಲೈಂಟ್ಗೆ ನೀಡಿದ ವಿಳಾಸವು ನೀವು ಸಂರಚಿಸಿದ ಪೂಲ್ನೊಳಗೆ ಬರುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಪೂಲ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ವಿಳಾಸ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಮೊದಲು ಅದನ್ನು ಸರಿಪಡಿಸಿ, ಏಕೆಂದರೆ ಕೆಳಗಿನ ಪ್ರತಿ ನಿಯಮವೂ ಪೂಲ್ಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ.

ಮುಂದೆ, ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ತಲುಪಲು ಸರ್ವರ್ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಬಳಸುತ್ತದೆ ಎಂದು ಕೇಳಿ. ip route get 203.0.113.9 ತನ್ನ ಮೊದಲ ಸಾಲಿನಲ್ಲಿ ಆಯ್ಕೆಯಾದ ಸಾಧನ ಮತ್ತು ಮೂಲವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. ಆ ಸಾಧನದ ಹೆಸರನ್ನು ಬರೆದಿಡಿ, ಏಕೆಂದರೆ NAT ನಿಯಮದಲ್ಲಿ ಇರಬೇಕಾದ ಮೌಲ್ಯ ಅದೇ.

ಪ್ಯಾಕೆಟ್ಗಳು ಹೊರಗೆ ಹೋಗುತ್ತವೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುವ ನಿಯಮವನ್ನು ಓದಿ

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

ಜೀವಂತ ಕೋಷ್ಟಕವನ್ನು ಪಟ್ಟಿ ಮಾಡಿ ಮತ್ತು ಕೇವಲ MASQUERADE ಪದವನ್ನು ಹುಡುಕುವ ಬದಲು ಔಟ್-ಇಂಟರ್ಫೇಸ್ ಕಾಲಮ್ ಓದಿ. ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಿದ ಪಟ್ಟಿಗಿಂತ ಸೇರಿಸುವ ರೂಪದ ಔಟ್ಪುಟ್ ಹೋಲಿಸಲು ಸುಲಭ:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

ಒಮ್ಮೆ Ethernet ಬಳಸಿ ಈಗ Wi-Fi ಬಳಸುವ Raspberry Pi ಯಲ್ಲಿ, ಹಳೆಯ ಹೆಸರೇ ಬಹುತೇಕ ಯಾವಾಗಲೂ ಇಡೀ ಕಥೆ. ಸ್ಥಾಪಕನು ಸೆಟಪ್ ಸಮಯದಲ್ಲಿ ಯಾವ ಸಾಧನ ಇತ್ತು ಎಂದು ದಾಖಲಿಸಿದ್ದನು, ಮತ್ತು ಸಂಗ್ರಹಿಸಿದ ನಿಯಮಸಮೂಹ ಪ್ರತಿ ಬೂಟ್ನಲ್ಲಿ ಅದನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸುತ್ತದೆ. ಬೇರೆ ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ರೂಟ್ ಹುಡುಕಾಟದಿಂದ ಬಂದ ಸಾಧನವನ್ನು ನಿಯಮದಲ್ಲಿರುವ ಸಾಧನದೊಂದಿಗೆ ಹೋಲಿಸಿ. ಅವು ಹೊಂದಿಕೆಯಾದರೆ, ಇಂಟರ್ಫೇಸ್ ನಿಮ್ಮ ಸಮಸ್ಯೆಯಲ್ಲ ಮತ್ತು ಕೊನೆಯ ಭಾಗದ ಕೌಂಟರ್ಗಳಿಗೆ ಹೋಗಬೇಕು. ಅವು ಭಿನ್ನವಾಗಿದ್ದರೆ, ಪರಿಹಾರವೆಂದರೆ ಸ್ಥಿರತೆ ಕಡತದಲ್ಲಿ ಒಂದು ಪದದ ಸಂಪಾದನೆ.

ಸಂಗ್ರಹಿಸಿದ ನಿಯಮಸಮೂಹವನ್ನು ಸರಿಪಡಿಸಿ, ಕೇವಲ ಚಾಲನೆಯಲ್ಲಿರುವದನ್ನಲ್ಲ

ಕೇವಲ ಜೀವಂತ ಕೋಷ್ಟಕವನ್ನು ಸಂಪಾದಿಸುವುದು ಮುಂದಿನ ರೀಬೂಟ್ವರೆಗೆ ಇರುತ್ತದೆ, ಅದು ಸಮಸ್ಯೆ ಪರಿಹಾರವಾಗಿದೆ ಎಂದು ನಿಮಗೆ ಒಪ್ಪಿಸಲು ಸಾಕಷ್ಟು ಸಮಯ. ಬೂಟ್ನಲ್ಲಿ ಮರಳಿ ಬರುವ ನಿಯಮಗಳು ಫೈರ್ವಾಲ್ ಸ್ಥಿರತೆ ಪ್ಯಾಕೇಜ್ ಮತ್ತೆ ಲೋಡ್ ಮಾಡುವ ಕಡತದಲ್ಲಿರುತ್ತವೆ. Debian ಆಧಾರಿತ Pi ಚಿತ್ರಗಳಲ್ಲಿ ಆ ಕಡತ ಸಾಮಾನ್ಯವಾಗಿ /etc/iptables/rules.v4.

ಅದನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಪ್ರತಿ ತೆಗೆದುಕೊಳ್ಳಿ, ನಂತರ MASQUERADE ಸಾಲಿನ ಔಟ್-ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನೀವು ದಾಖಲಿಸಿದ ಸಾಧನದಿಂದ ಬದಲಿಸಿ, ಉದಾಹರಣೆಗೆ -o wlan0 ಬದಲು -o eth0. ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಪೂಲ್ ಬದಲಾಗದಿದ್ದರೆ ಮೂಲ ಶ್ರೇಣಿಯನ್ನು ಹಾಗೆಯೇ ಬಿಡಿ. ಮತ್ತೆ ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ನಿಯಮ ಈಗ ಸರಿಯಾದ ಸಾಧನವನ್ನು ಹೆಸರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

ಪಕ್ಕದ ಎರಡು ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಮರೆಯುವುದು ಸುಲಭ. sysctl net.ipv4.ip_forward 1 ಎಂದು ವರದಿ ಮಾಡಬೇಕು, ಮತ್ತು ಮೇಲಿನ ರೂಟರ್ ಖಾಸಗಿ ಮೂಲ ವಿಳಾಸಗಳನ್ನು ತಾನೇ ಫಿಲ್ಟರ್ ಮಾಡಬಾರದು.

ನಿಯಮ ಪ್ರಚೋದಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ, ನಂತರ ಇನ್ನೂ ಏನು ನಿಧಾನವಾಗಿದೆ ಎಂದು ಪ್ರತ್ಯೇಕಿಸಿ

ನಿಯಮ ಹೊಂದಿಕೆಯಾದುದಕ್ಕೆ ಕೌಂಟರ್ಗಳೇ ಏಕೈಕ ಪ್ರಾಮಾಣಿಕ ಸಾಕ್ಷಿ. ವಿವರವಾದ ಪಟ್ಟಿ ಚಲಾಯಿಸಿ, ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಡೌನ್ಲೋಡ್ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಮತ್ತೆ ಚಲಾಯಿಸಿ. ನಿಮ್ಮ ನಿಯಮದ ಪಕ್ಕದ ಪ್ಯಾಕೆಟ್ ಮತ್ತು ಬೈಟ್ ಕಾಲಮ್ಗಳು ಏರಬೇಕು, ಮತ್ತು ಶೂನ್ಯದಲ್ಲೇ ಉಳಿಯುವ ನಿಯಮ ಇನ್ನೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಕೌಂಟರ್ಗಳು ಚಲಿಸಿದರೂ ಪುಟಗಳು ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಮೂಲ ಶ್ರೇಣಿಯನ್ನು ನಿಜವಾದ ಪೂಲ್ನೊಂದಿಗೆ ಇದರಿಂದ ಹೋಲಿಸಿ grep -n "^server " /etc/openvpn/server.conf. ಅವು ಚಲಿಸಿ ಪುಟಗಳು ಲೋಡ್ ಆದರೂ ಥ್ರೂಪುಟ್ ಕಳಪೆಯಾಗಿದ್ದರೆ, ಅನುವಾದ ಮುಗಿದಿದೆ ಮತ್ತು ಉಳಿದ ಸಮಸ್ಯೆ ಬೇರೆಡೆ ಇದೆ.

ಒಂದೇ ಕ್ಲೈಂಟ್ನಿಂದ ಎರಡು ವರ್ಗಾವಣೆಗಳನ್ನು ಹೋಲಿಸಿ, ಒಂದು ಸ್ಥಳೀಯ ಜಾಲದ ಹೋಸ್ಟ್ಗೆ ಮತ್ತು ಇನ್ನೊಂದು ಟನೆಲ್ ಮೂಲಕ ಅದೇ ಹೋಸ್ಟ್ಗೆ. ಎರಡರಲ್ಲೂ ನಿಧಾನವಾದರೆ ಅದು VPN ಅಲ್ಲ, Pi ಯ ಮೇಲಿನ ಲಿಂಕ್ ಅಥವಾ Wi-Fi ಸಂಪರ್ಕದತ್ತ ಸೂಚಿಸುತ್ತದೆ. ಕೇವಲ ಟನೆಲ್ ಮೂಲಕ ನಿಧಾನವಾದರೆ ಅದು MTU ಮತ್ತು ಮರುಪ್ರಸಾರದತ್ತ ಸೂಚಿಸುತ್ತದೆ, ಅವುಗಳನ್ನು ಇದರಿಂದ ಪರಿಶೀಲಿಸಬಹುದು ip -s link show tun0 ಯಾವುದೇ ಕ್ರಿಪ್ಟೋ ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸುವ ಮೊದಲು.

ಪ್ರಯೋಗವನ್ನು ರದ್ದುಗೊಳಿಸಲು ಪ್ರತಿಯನ್ನು ಮರುಸ್ಥಾಪಿಸಿ ಮತ್ತು ಮತ್ತೆ ಲೋಡ್ ಮಾಡಿ, ನಂತರ ಮೂಲ ನಿಯಮ ಮತ್ತು ಅದರ ಕೌಂಟರ್ಗಳು ಮರಳಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ನಿರ್ಗಮನ ಸಾಧನ ಮತ್ತು ಮರುಲೋಡ್ ಆಜ್ಞೆಯನ್ನು ಸರ್ವರ್ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಅಪ್ಲಿಂಕ್ ಬದಲಾವಣೆ ಅದೇ ಅಸಂಗತಿಯನ್ನು ಮತ್ತೆ ಪತ್ತೆ ಮಾಡುತ್ತದೆ. ತಪ್ಪು ಸಾಧನವನ್ನು ಹೆಸರಿಸುವ ನಿಯಮ ಸಂಚಾರಕ್ಕೆ ಅದು ಬೇಕಾಗುವವರೆಗೆ ಅಗೋಚರವಾಗಿರುತ್ತದೆ.