OpenVPN ನ ಸಂಪೂರ್ಣ ಟನೆಲ್ ನಿಮ್ಮ SSH ಸೆಷನ್ ಕಡಿತಗೊಳಿಸುತ್ತದೆ: ಉತ್ತರದ ಮಾರ್ಗ ಸರಿಪಡಿಸಿ

ನೀವು SSH ಮೂಲಕ ತಲುಪುವ ಯಂತ್ರದಲ್ಲಿ ಪೂರ್ಣ-ಟನೆಲ್ OpenVPN ಕ್ಲೈಂಟ್ ಆನ್ ಮಾಡುವುದು ಒಂದು ಸೆಕೆಂಡಿನಲ್ಲಿ ಸೆಷನ್ ಕಡಿತಗೊಳಿಸಬಹುದು, ಮತ್ತು ಯಂತ್ರ ಏನೂ ತಪ್ಪು ಮಾಡುತ್ತಿಲ್ಲ. ಟನೆಲ್ ಪ್ಯಾಕೆಟ್ಗಳು ಸರ್ವರ್ಗೆ ತಲುಪುವ ರೀತಿಯನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ; ಉತ್ತರಗಳು ಹೇಗೆ ಹೊರಬರುತ್ತವೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. ಡೀಫಾಲ್ಟ್ ರೂಟ್ tun0 ಕಡೆ ತೋರಿಸಿದ ಕ್ಷಣ, ನಿಮ್ಮ SSH ಕ್ಲೈಂಟ್ಗೆ ಉತ್ತರವು ಪೂರೈಕೆದಾರರ ನೆಟ್ವರ್ಕ್ಗೆ ಹೋಗುತ್ತದೆ, ಅದಕ್ಕೆ ನಿಮ್ಮ ವಿಳಾಸಕ್ಕೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವಿಲ್ಲ. ಸಂಪರ್ಕ ನೇತಾಡುತ್ತದೆ, ಮುಂದಿನ ಪ್ರಯತ್ನ ಸಮಯ ಮೀರಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಡೀಮನ್ ಸಾರ್ವಕಾಲಿಕವಾಗಿ ಪೋರ್ಟ್ 22 ರಂದು ಕೇಳುತ್ತಲೇ ಇರುತ್ತದೆ.

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

ಉತ್ತರ ತಪ್ಪು ಬಾಗಿಲಿನಿಂದ ಏಕೆ ಹೊರಬರುತ್ತದೆ

ಒಳಬರುವ ಪ್ಯಾಕೆಟ್ಗಳು ಇನ್ನೂ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ಗೆ ಬರುತ್ತವೆ, ಏಕೆಂದರೆ VPN ಕ್ಲೈಂಟ್ ಇಂಟರ್ನೆಟ್ ನಿಮ್ಮ ಸರ್ವರ್ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ತಲುಪುವ ರೀತಿಯನ್ನು ಬದಲಿಸಲಾಗದು. ಉತ್ತರಗಳು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರ: ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ಗೂ ಕರ್ನಲ್ ಗಮ್ಯಸ್ಥಾನ ಹುಡುಕುತ್ತದೆ, ಮತ್ತು --redirect-gateway ನಂತರ ಡೀಫಾಲ್ಟ್ ನಮೂದು ಟನೆಲ್ ಎನ್ನುತ್ತದೆ. ಪೂರೈಕೆದಾರರ ನಿರ್ಗಮನವು ತಾನು ಸೇವೆ ಸಲ್ಲಿಸದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ನೋಡಿ ಪ್ಯಾಕೆಟ್ ಬಿಡುತ್ತದೆ.

OpenVPN ನ ಸ್ವಂತ ರಕ್ಷಣೆ ನಿಖರವಾಗಿ ಒಂದು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಆವರಿಸುತ್ತದೆ. 2.6 ಕೈಪಿಡಿ --redirect-gateway ಅನ್ನು ಕ್ರಮವಾಗಿ ವಿವರಿಸುತ್ತದೆ: ಟನೆಲ್ಗಿಂತ ಮೊದಲು ಬಳಸಿದ ಗೇಟ್ವೇ ಮೂಲಕ VPN ಪೀರ್ಗೆ ಹೋಸ್ಟ್ ಮಾರ್ಗ ಸೇರಿಸುತ್ತದೆ, ಇದರಿಂದ ಗೂಢಲಿಪೀಕೃತ ಸಂಚಾರ ತನ್ನೊಳಗೇ ಹಿಂತಿರುಗಲಾಗದು, ನಂತರ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಬದಲಿಸುತ್ತದೆ. ಆ ಹೋಸ್ಟ್ ಮಾರ್ಗ ಪೀರ್ಗೆ ಮಾತ್ರ. ನಿಮ್ಮ SSH ಕ್ಲೈಂಟ್ ಕೇವಲ ಇನ್ನೊಂದು ಇಂಟರ್ನೆಟ್ ವಿಳಾಸ ಮತ್ತು ಯಾವುದೇ ವಿನಾಯಿತಿ ಪಡೆಯುವುದಿಲ್ಲ.

ಒಂದು ಪ್ರಿಫಿಕ್ಸ್ ತಪ್ಪನ್ನು ಬೇಗನೆ ಹೊರಗಿಡುವುದು ಉತ್ತಮ. ಉದ್ದವಿಲ್ಲದ ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 ಏಕೈಕ ವಿಳಾಸ 0.0.0.0 ಗೆ ಹೊಂದುತ್ತದೆ, ಇಂಟರ್ನೆಟ್ಗೆ ಅಲ್ಲ; ಅದು 0.0.0.0/0 ಆಗಿರಬೇಕು. ಮತ್ತು ಡೀಫಾಲ್ಟ್ ತೆಗೆದುಕೊಳ್ಳುವುದು ಟನೆಲ್ನ ಸ್ವಂತ ಸಾಗಣೆಯನ್ನು ಮುರಿದರೆ, ಅಂತ್ಯಬಿಂದುವನ್ನು ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೋಸ್ಟ್ ಮಾರ್ಗವಾಗಿ ಸೇರಿಸಿ, ಪೂರೈಕೆದಾರರ ನಿಜವಾದ ವಿಳಾಸ ಬಳಸಿ.

ತಕ್ಷಣದ ದುರಸ್ತಿಗಾಗಿ ನಿಮ್ಮ SSH ಕ್ಲೈಂಟ್ ವಿಳಾಸ ಪಿನ್ ಮಾಡಿ

ಅತ್ಯಂತ ವೇಗದ ದುರಸ್ತಿ ಎಂದರೆ ಟನೆಲ್ ಇರುವ ಮೊದಲು ಸರ್ವರ್ ಬಳಸಿದ ಗೇಟ್ವೇ ಮೂಲಕ ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ವಿಳಾಸಕ್ಕೆ ಹೋಸ್ಟ್ ಮಾರ್ಗ. ನಿಮ್ಮ ಕಡೆಯಿಂದ ಸರ್ವರ್ ನೋಡುವ ವಿಳಾಸ ಹುಡುಕಿ, ನಂತರ ಹಳೆಯ ಗೇಟ್ವೇ ತಿಳಿಯಲು ಸರ್ವರ್ನ ಕೋಷ್ಟಕ ಓದಿ:

curl -s https://ifconfig.co
ip route

ಸರ್ವರ್ನಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ವಿನಾಯಿತಿ ಸೇರಿಸಿ. ಇಲ್ಲಿನ ವಿಳಾಸಗಳು ಪ್ಲೇಸ್ಹೋಲ್ಡರ್ಗಳು; ಆಕಾರವೇ ಮುಖ್ಯ:

sudo ip route add 80.128.240.55 via 192.168.178.1

ಇದು ವರದಿಯಾದ ಪ್ರಕರಣದಲ್ಲಿ ಬಳಸಿದ ದುರಸ್ತಿ, ಮತ್ತು ಅದು ತಕ್ಷಣ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಇದು ಎರಡು ಊಹಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ಸೂಕ್ಷ್ಮವೂ ಆಗಿದೆ: ಮರುಬೂಟ್ನಲ್ಲಿ ಮಾರ್ಗ ಮಾಯವಾಗುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ISP ಬೇರೆ ವಿಳಾಸ ನೀಡಿದ ಕ್ಷಣ ಅದು ತಪ್ಪಾಗುತ್ತದೆ. ಇದನ್ನು ತುರ್ತು ಕ್ರಮವೆಂದು ಪರಿಗಣಿಸಿ ಮತ್ತು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಶಾಶ್ವತಗೊಳಿಸಿ, ನೆಟ್ವರ್ಕ್ ಘಟಕ ಅಥವಾ ಡಿಸ್ಪ್ಯಾಚರ್ ಕೊಕ್ಕೆ ಮೂಲಕ, ಅಥವಾ ಇದು ತಾತ್ಕಾಲಿಕ ಎಂದು ಒಪ್ಪಿ ಚೇತರಿಕೆಯ ಮಾರ್ಗ ಬರೆದಿಡಿ.

ಕ್ಲೈಂಟ್ ಡೀಫಾಲ್ಟ್ ತೆಗೆದುಕೊಳ್ಳುವುದನ್ನು ತಡೆಯಿರಿ

ಸ್ವಚ್ಛವಾದ ಆಯ್ಕೆ ಎಂದರೆ ಟನೆಲ್ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಬದಲಿಸದಂತೆ ತಡೆಯುವುದು. route-nopull, --client ಅಥವಾ --pull ಜೊತೆ ಬಳಸಿದಾಗ, ಮಾರ್ಗಗಳು, block-outside-dns ಮತ್ತು DNS ಸರ್ವರ್ಗಳಂತಹ DHCP ಶೈಲಿಯ ಆಯ್ಕೆಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ತಳ್ಳಲಾದ ಆಯ್ಕೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಹಾಗಾಗಿ ಅಗತ್ಯವಿರುವ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಮಾತ್ರ ಸೇರಿಸುತ್ತೀರಿ. ಇನ್ನೂ ಸಣ್ಣ ಸಾಧನ ಎಂದರೆ ಎಳೆತದ ಫಿಲ್ಟರ್, ಅದು ಒಂದು ಸಮಸ್ಯಾತ್ಮಕ ಸೂಚನೆಯನ್ನು ಬಿಟ್ಟು ಉಳಿದದ್ದನ್ನು ಇರಿಸುತ್ತದೆ:

route-nopull
pull-filter ignore "redirect-gateway"

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

ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಮೂಲ ಅಥವಾ ಸಂಪರ್ಕದ ಪ್ರಕಾರ ಬೇರ್ಪಡಿಸಿ

ಒಳಬರುವ ವಿಳಾಸ ಸ್ಥಿರವಾಗಿದ್ದಾಗ, ಮೂಲ ನಿಯಮ ಟನೆಲ್ನ ಸ್ವಂತ ಮಾರ್ಗಗಳನ್ನು ಮುಟ್ಟದೆ ಉತ್ತರಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಇರಿಸುತ್ತದೆ. ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ವಿಳಾಸಕ್ಕೆ LAN ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಭೌತಿಕ ಡೀಫಾಲ್ಟ್ ಇರುವ ತನ್ನದೇ ಕೋಷ್ಟಕ ಕೊಡಿ, ನಂತರ ಅಲ್ಲಿಂದ ಬರುವ ಸಂಚಾರಕ್ಕೆ ಆ ಕೋಷ್ಟಕ ಆಯ್ಕೆ ಮಾಡಿ:

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ಒಳಬರುವ SSH ಸಂಪರ್ಕಕ್ಕೆ ಉತ್ತರಗಳು ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸಿದ ವಿಳಾಸದಿಂದಲೇ ಬರುತ್ತವೆ. ಪ್ರತಿ ಒಳಬರುವ ಸೇವೆಯೂ ಕೆಲಸ ಮುಂದುವರಿಸಬೇಕಿದ್ದ ವರದಿಯಾದ ಪ್ರಕರಣವು ನಿಖರವಾಗಿ ಈ ಆಕಾರ ಬಳಸಿತ್ತು. ಒಳಬರುವ ವಿಳಾಸ ತೇಲುತ್ತಿದ್ದರೆ ಅಥವಾ ಮಾರ್ಗ ಚಲನಶೀಲವಾಗಿದ್ದರೆ, ಬದಲಿಗೆ ಸಂಪರ್ಕವನ್ನು ಗುರುತಿಸಿ: ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಬರುವ ಮೊದಲ ಪ್ಯಾಕೆಟ್ಗೆ conntrack ಗುರುತು ಹಾಕಿ, OUTPUT ನಲ್ಲಿ ಉತ್ತರ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಅದನ್ನು ನಕಲಿಸಿ, ಮತ್ತು ಗುರುತಿಸಿದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಭೌತಿಕ ಗೇಟ್ವೇ ಕಡೆ ತೋರಿಸುವ ಕೋಷ್ಟಕದ ಮೂಲಕ ರೂಟ್ ಮಾಡಿ.

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

ಪರೀಕ್ಷಿಸುವಾಗ ಸಂಪರ್ಕ ಗುರುತು, ಫೈರ್ವಾಲ್ ಗುರುತು ಮತ್ತು ಕೋಷ್ಟಕ ಸಂಖ್ಯೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿಡಿ. ಎರಡು ಪಾತ್ರಗಳಿಗೆ ಒಂದೇ ಸಂಖ್ಯೆಯನ್ನು ಮರುಬಳಕೆ ಮಾಡುವುದು ಸರಿ ಕಾಣುವ ಮತ್ತು ತಪ್ಪು ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಹೊಂದುವ ನಿಯಮವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಕೋಷ್ಟಕದ ಡೀಫಾಲ್ಟ್ ನಮೂದಿಗೆ ಸಾಮಾನ್ಯ ಇಥರ್ನೆಟ್ ಕೊಂಡಿಯಲ್ಲಿ LAN ಗೇಟ್ವೇ ಜೊತೆ via ಸಹ ಬೇಕು; ಬರೀ dev eth0 ಇಂಟರ್ಫೇಸ್ ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಆಗಿದ್ದಾಗ ಅಥವಾ ಮುಂದಿನ ಹೆಜ್ಜೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಬಗೆಹರಿದಾಗ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ವರದಿಯಾದ Jessie ಹೋಸ್ಟ್ ಬರೀ ರೂಪ ಕೆಲಸ ಮಾಡಿದ ಕೊಂಡಿಯಲ್ಲಿತ್ತು, ಅದು ನಕಲಿಸಬಹುದಾದ ಯಾವುದೇ ವಿತರಣಾ ನಿಯಮವಲ್ಲ.

ಹೊರಗೆ ಲಾಕ್ ಆಗದೆ ಪರಿಶೀಲಿಸಿ

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

ip route get 80.128.240.55

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

ಇಡೀ ಅಭ್ಯಾಸದ ಉದ್ದಕ್ಕೂ ಔಟ್-ಆಫ್-ಬ್ಯಾಂಡ್ ಕನ್ಸೋಲ್ ಲಭ್ಯವಿರಿಸಿ. ನೀವು ಈಗಷ್ಟೇ ಮುರಿದ ಟನೆಲ್ನದೇ ಏಕೈಕ ಪ್ರವೇಶ ಮಾರ್ಗವಿರುವ ಸರ್ವರ್ ಅನ್ನು ಆ ಟನೆಲ್ ಮೂಲಕ ಸರಿಪಡಿಸಲಾಗದು, ಮತ್ತು ಸೇರಿಸಿದ ಕೋಷ್ಟಕ ಸಂಖ್ಯೆಗಳು ಹಾಗೂ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಬರೆದಿಟ್ಟರೆ ಹಿಂತಿರುಗಿಸುವುದು ಸುಲಭ.