ಪೂರ್ಣ ಸುರಂಗ OpenVPN: ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನ ಸೇರಿಸಿ

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

ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಪುಶ್ ಮಾಡಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ಏನನ್ನು ಸ್ಥಾಪಿಸಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ

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

push "redirect-gateway def1"

ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಪ್ರೊಫೈಲ್ ಅನ್ನು ನಂಬುವ ಬದಲು ಕ್ಲೈಂಟ್ನ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ಓದಿ. Linux ನಲ್ಲಿ ಎರಡು /1 ನಮೂದುಗಳು ಮೂಲ ಡಿಫಾಲ್ಟ್ನ ಪಕ್ಕದಲ್ಲಿ ಕಾಣುತ್ತವೆ, ಮತ್ತು Windows ಅದೇ ಜೋಡಿಯನ್ನು 0.0.0.0/1 ಮತ್ತು 128.0.0.0/1 ಎಂದು ತೋರಿಸುತ್ತದೆ. ಪುಶ್ ಮಾಡಿದ ಆಯ್ಕೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಕ್ಲೈಂಟ್, ಅಥವಾ ಅವನ್ನು ನಿರಾಕರಿಸಲು ಸಂರಚಿಸಲಾದ ಕ್ಲೈಂಟ್, ತನ್ನ ಹಳೆಯ ಡಿಫಾಲ್ಟ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಇಂಟರ್ನೆಟ್ ಸಂಚಾರವನ್ನು ಸುರಂಗಕ್ಕೆ ಎಂದಿಗೂ ಕಳುಹಿಸುವುದಿಲ್ಲ. ಸರ್ವರ್ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಈ ಪ್ರಶ್ನೆಯನ್ನು ಬಗೆಹರಿಸಿ, ಏಕೆಂದರೆ ಸರ್ವರ್ ಬದಿಯ ಯಾವುದೇ ನಿಯಮವೂ ಅದನ್ನು ಸರಿದೂಗಿಸಲಾರದು.

ರವಾನೆ ಸರ್ವರ್ ಸೆಟ್ಟಿಂಗ್, VPN ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ

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

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

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

ನೀವು ಉದ್ದೇಶಿಸಿದ ಸಂಚಾರಕ್ಕೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡಿ, ಬೇರೆ ಯಾವುದಕ್ಕೂ ಅಲ್ಲ

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

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

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

ಉತ್ತರಗಳಿಗೆ ಹೋಗಲು ಒಂದು ಸ್ಥಳ ಕೊಡಿ

ಪೂಲ್ನ ವಿಳಾಸಗಳು ಖಾಸಗಿ, ಆದ್ದರಿಂದ ಸಾರ್ವಜನಿಕ ಸರ್ವರ್ ಅವಕ್ಕೆ ನೇರವಾಗಿ ಉತ್ತರವನ್ನು ತಲುಪಿಸಲಾರದು. ಒಂದೋ VPN ಹೋಸ್ಟ್ ಹೊರಹೋಗುವಾಗ ಮೂಲ ವಿಳಾಸವನ್ನು ಅನುವಾದಿಸುತ್ತದೆ, ಇಲ್ಲವೇ ಮೇಲ್ಮುಖ ಸಾಧನವು ಪೂಲ್ಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಹೊಂದಿರುತ್ತದೆ.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

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

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

ಅದನ್ನು ಸರ್ವರ್ ಶೆಲ್ನಿಂದ ಅಲ್ಲ, ಕ್ಲೈಂಟ್ನಿಂದ ಸಾಬೀತುಪಡಿಸಿ

ಸಂಖ್ಯಾತ್ಮಕ IPv4 ವಿನಂತಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಹೆಸರು ಹುಡುಕಾಟ, ನಂತರ ಅಪ್ಲಿಕೇಶನ್. ping ರವಾನೆ ಮತ್ತು ಅನುವಾದವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ;ಅದು ಹೆಸರು ವಿಭಜನೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ DNS ಆಯ್ಕೆಗಳು ಕ್ಲೈಂಟ್ ಸಂಯೋಜನೆ ಅವನ್ನು ಸ್ಥಾಪಿಸಿದಾಗ ಮಾತ್ರ ಜಾರಿಗೆ ಬರುತ್ತವೆ.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

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