LAN ರೌಟರ್ ಮತ್ತು VPN ಕ್ಲೈಂಟ್: ಎರಡು ಸಾಧನಗಳು, ಎರಡು ರೂಟ್ ಕೋಷ್ಟಕಗಳು

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

ರೂಟ್ಗೆ ಮುಟ್ಟುವ ಮೊದಲು ಎರಡು ಹಾಪ್ಗಳನ್ನು ಬಿಡಿಸಿ

ಒಂದು ಉದಾಹರಣೆ ವಿನ್ಯಾಸ ತೆಗೆದುಕೊಳ್ಳಿ: LAN ಹೋಸ್ಟ್ಗಳು 192.168.50.0/24 ನಲ್ಲಿ, ಸಾಮಾನ್ಯ ರೌಟರ್ 192.168.50.1 ನಲ್ಲಿ, ಮೀಸಲಾದ ಕ್ಲೈಂಟ್ 192.168.50.15 ನಲ್ಲಿ, ಮತ್ತು ದೂರದ LAN 10.60.0.0/24 ನಲ್ಲಿ, ಅದು ಆ ಕ್ಲೈಂಟ್ ಹೊಂದಿರುವ ಟನಲ್ ಮೂಲಕ ಮಾತ್ರ ತಲುಪಬಹುದು. ಎರಡು ಖಾಸಗಿ ಶ್ರೇಣಿಗಳಲ್ಲಿ ಯಾವುದೂ ಇನ್ನೊಂದನ್ನು ಅತಿಕ್ರಮಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಟನಲ್ಗೆ ತನ್ನದೇ ಆದ ವಿಳಾಸ ಯೋಜನೆ ಇದೆ.

ಎರಡೂ ಖಾಸಗಿ ಶ್ರೇಣಿಗಳು ಮುಖ್ಯ, ಏಕೆಂದರೆ ಯಾವ ಸಾಧನ ಉತ್ತರಿಸಬಹುದು ಎಂಬುದನ್ನು ಅವು ನಿರ್ಧರಿಸುತ್ತವೆ. ದೂರದ ಬದಿ ಪ್ಯಾಕೆಟ್ ಕ್ಲೈಂಟ್ನ ಟನಲ್ ವಿಳಾಸದಿಂದ ಬರುತ್ತಿರುವುದನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಅದರ ಉತ್ತರವು 192.168.50.0/24 ಗೆ ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಕಂಡುಕೊಳ್ಳಬೇಕು. ಹೊರಹೋಗುವ ದಿಕ್ಕನ್ನು ಮಾತ್ರ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದರೆ, ವಿನಂತಿ ಕೆಲಸ ಮಾಡಬಹುದು ಆದರೆ ಉತ್ತರ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ.

ಹಂತ 1: ರೌಟರ್ ಅನ್ನು ಟನಲ್ಗಲ್ಲ, ಕ್ಲೈಂಟ್ನ ಕಡೆಗೆ ತೋರಿಸಿ

LAN ರೌಟರ್ನಲ್ಲಿ, ಮುಂದಿನ ಹಾಪ್ ಕ್ಲೈಂಟ್ನ LAN ವಿಳಾಸವಾಗಿರುವ ಗಮ್ಯಸ್ಥಾನ ರೂಟ್ ಸೇರಿಸಿ:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

ಆ ದಾಖಲೆ “ಟನಲ್ ಮಾಡಬಲ್ಲ ಯಂತ್ರಕ್ಕೆ ಅದನ್ನು ತಲುಪಿಸಿ” ಎಂದು ಹೇಳುತ್ತದೆ. ಟನಲ್ ಹೇಗೆ ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಅದು ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ರೂಟ್ಗೆ ಬದಲಿಯಲ್ಲ. ನಿರ್ವಹಿತ ರೌಟರ್ನಲ್ಲಿ ಸಮಾನವಾದದ್ದು ಸಾಧನದ ಸ್ಟ್ಯಾಟಿಕ್-ರೂಟ್ ಪುಟದಲ್ಲಿ ಇರುತ್ತದೆ; Linux ರೌಟರ್ನಲ್ಲಿ ಅದು LAN ಅನ್ನು ಹೊಂದಿರುವ ಇಂಟರ್ಫೇಸ್ ಕಾನ್ಫಿಗರೇಶನ್ಗೆ ಸೇರುತ್ತದೆ, ನೀವು ಮುಚ್ಚುವ ಶೆಲ್ಗೆ ಅಲ್ಲ.

ಎರಡನೇ ಆಜ್ಞೆಯ ಉತ್ತರವನ್ನು ಪರಿಶೀಲಿಸಿ. ಅದು ಕ್ಲೈಂಟ್ ಅನ್ನು gateway ಮತ್ತು LAN ಇಂಟರ್ಫೇಸ್ ಅನ್ನು device ಎಂದು ವರದಿ ಮಾಡಿದರೆ, ಮೊದಲ ಹಾಪ್ ಸರಿಯಾಗಿದೆ ಮತ್ತು ಉಳಿದ ಕೆಲಸ ಇನ್ನೊಂದು ಯಂತ್ರದಲ್ಲಿದೆ.

ಹಂತ 2: ಕ್ಲೈಂಟ್ಗೆ ಟನಲ್ ಬದಿಯಲ್ಲಿ ಅದರದೇ ರೂಟ್ ನೀಡಿ

ಕ್ಲೈಂಟ್ ಈಗ 10.60.0.0/24 ಗಾಗಿ ಪ್ಯಾಕೆಟ್ ಸ್ವೀಕರಿಸಿ ತನ್ನದೇ ಕೋಷ್ಟಕವನ್ನು ನೋಡುತ್ತದೆ. ಅದರ ಟನಲ್ ಕಾನ್ಫಿಗರೇಶನ್ ಆ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ರೂಟ್ ಸ್ಥಾಪಿಸಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿ ಮುಂದುವರಿಯುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಸಾಮಾನ್ಯ ಡಿಫಾಲ್ಟ್ಗೆ ಹೊಂದಿಕೆಯಾಗಿ 192.168.50.1 ಗೆ ಹಿಂತಿರುಗುತ್ತದೆ, ಅದು ಅದನ್ನು ಮತ್ತೆ ಕ್ಲೈಂಟ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ.

ಏನನ್ನಾದರೂ ಸೇರಿಸುವ ಮೊದಲು ನೋಡಿ:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

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

ಲೂಪ್, ಸಂಭವಿಸಿದಾಗ, ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅನಂತವಲ್ಲ: ಪ್ರತಿ ಹಾದಿಯಲ್ಲೂ TTL ಕಡಿಮೆಯಾಗುತ್ತದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಸಮಯ ಮೀರಿದ ಸಂದೇಶದೊಂದಿಗೆ ಸಾಯುತ್ತದೆ. ಆದ್ದರಿಂದ ಪುನರಾವರ್ತಿತ traceroute ಚಕ್ರವನ್ನು ಸೂಚಿಸಬಹುದು, ಆದರೆ ಫಾರ್ವರ್ಡ್ ಮಾಡದ ಕ್ಲೈಂಟ್ ಅದೇ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬೀಳಿಸುತ್ತದೆ.

ಹಂತ 3: ಫಾರ್ವರ್ಡಿಂಗ್ಗೆ ಅನುಮತಿ ನೀಡಿ ಮತ್ತು ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಆರಿಸಿ

ಸ್ವೀಕರಿಸುವುದು ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದು ಬೇರೆ ಬೇರೆ ಅನುಮತಿಗಳು. ಕ್ಲೈಂಟ್ನಲ್ಲಿ net.ipv4.ip_forward=1 ಕೆರ್ನೆಲ್ ಮಟ್ಟದಲ್ಲಿ ಸಾಗಣೆಗೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ, ಮತ್ತು ಫೈರ್ವಾಲ್ ನಿಯಮವು ಅದನ್ನು LAN ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಟನಲ್ ನಡುವೆ ಇನ್ನೂ ಅನುಮತಿಸಬೇಕು. ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ನಿರ್ವಹಣಾ ಪುಟಕ್ಕೆ ಪ್ರವೇಶವನ್ನು ಅನುಮತಿಸುವ ನಿಯಮವು ದೂರದ LANಗೆ ಸಾಗಣೆಯನ್ನು ಅನುಮತಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದೇ ಹೋಸ್ಟ್ ಸ್ಥಳೀಯವಾಗಿ ping ಗಳಿಗೆ ಉತ್ತರಿಸಿದಾಗ ಈ ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನಿಸದೇ ಇರುವುದು ಸುಲಭ.

ದೂರದ ಬದಿಗೆ ಕನ್ನಡಿ ಸಮಸ್ಯೆ ಇದೆ. 192.168.50.0/24 ಈ ದೃಢೀಕೃತ ಕ್ಲೈಂಟ್ ಮೂಲಕ ತಲುಪಬಹುದು ಎಂದು ಅದು ತಿಳಿದಿರಬೇಕು. OpenVPN ಜೊತೆಗೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್ ತಳ್ಳುವ ಪ್ರತಿ-ಕ್ಲೈಂಟ್ ರೂಟ್, ಅಥವಾ ಸರ್ವರ್ನಲ್ಲಿ ಕ್ಲೈಂಟ್ನ ಹಿಂದಿನ LAN ಅನ್ನು ಘೋಷಿಸುವ ಕ್ಲೈಂಟ್-ನಿರ್ದಿಷ್ಟ ಫೈಲ್ ಎಂದರ್ಥ. ಅದು ಇಲ್ಲದೆ, ದೂರದ LAN ಉತ್ತರವನ್ನು ಬೀಳಿಸುತ್ತದೆ ಅಥವಾ ತನ್ನದೇ ಡಿಫಾಲ್ಟ್ ಗೇಟ್ವೇಗೆ, ಅಂದರೆ ಇಂಟರ್ನೆಟ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ.

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

ಹಂತ 4: ಎರಡೂ ನಿರ್ಣಯಗಳನ್ನು ಶಾಶ್ವತಗೊಳಿಸಿ, ನಂತರ ನಿಜವಾದ ದಾರಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ

ಪ್ರತಿ ರೂಟ್ಗೆ ಒಬ್ಬ ಮಾಲೀಕನಿರುತ್ತಾನೆ, ಮತ್ತು ಮಾಲೀಕ ಎಂದರೆ ಬೂಟ್ನಲ್ಲಿ ಅಥವಾ ಮರುಸಂಪರ್ಕದಲ್ಲಿ ಮತ್ತೆ ರೂಪುಗೊಳ್ಳುವ ಕಾನ್ಫಿಗರೇಶನ್. ರೌಟರ್ನಲ್ಲಿ ಅದು ಸ್ಟ್ಯಾಟಿಕ್ ರೂಟ್ ನಮೂದಾಗಿರಬಹುದು; ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಅದು VPN ಪ್ರೊಫೈಲ್, NetworkManager ಅಥವಾ systemd-networkd ಆಗಿರಬಹುದು. ಟನಲ್ ಅನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಕ್ಲೈಂಟ್ ಅನ್ನು ರೀಬೂಟ್ ಮಾಡಿ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಬದಲಾವಣೆಯನ್ನು ನಂಬುವ ಬದಲು ಕೋಷ್ಟಕವನ್ನು ಮತ್ತೆ ಓದಿ.

ಟನಲ್ನ ಹೊರ ಸಂಪರ್ಕವನ್ನು ಹೊತ್ತೊಯ್ಯುವ ಡಿಫಾಲ್ಟ್ ರೂಟ್ ಅನ್ನು ಅಸ್ಪೃಶ್ಯವಾಗಿ ಇರಿಸಿ. ಸೆಟಪ್ “ಸರಳ” ಮಾಡಲು ಅದನ್ನು ಬದಲಿಸುವುದು ಯಾವುದೇ ಒಳ ಸಂಚಾರವು ಅದನ್ನು ಬಳಸುವ ಮೊದಲೇ ಎನ್ಕ್ರಿಪ್ಟ್ ಆದ ದಾರಿಯನ್ನು ಮುರಿಯುತ್ತದೆ, ಮತ್ತು ಲಕ್ಷಣವೆಂದರೆ ಬದಲಾವಣೆಯ ನಂತರ ಎಂದಿಗೂ ಮರುಸ್ಥಾಪಿತವಾಗದ ಟನಲ್.

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