VPN ಕ್ಲೈಂಟ್ ಹಿಂದಿನ ಸರ್ವರ್ ಟನೆಲ್ ಮೂಲಕ ಏಕೆ ಉತ್ತರಿಸುತ್ತದೆ

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

ಉತ್ತರ ರೂಟ್ ಆಗುತ್ತದೆ, ನೆನಪಿಡುವುದಿಲ್ಲ

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

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

ಕಟ್ಟುನಿಟ್ಟಿನ ಹಿಮ್ಮುಖ ಮಾರ್ಗ ಫಿಲ್ಟರಿಂಗ್ ಡೀಮನ್ ಓದುವ ಮೊದಲೇ ಒಳಬರುವ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಬೀಳಿಸಬಹುದು. ಮೊದಲು ಆ ಕೌಂಟರ್ ನೋಡಿ, ಏಕೆಂದರೆ ಫಿಲ್ಟರ್ನ ಬೀಳಿಕೆ ಮತ್ತು ರೂಟಿಂಗ್ ತಪ್ಪು ಹೊರಗಿನಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

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

ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ಮೂರು ದಾರಿಗಳು

ಸೇವೆಯ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಟನೆಲ್ನಿಂದ ಹೊರಗಿಡುವುದು ಅತ್ಯಂತ ಸಣ್ಣ ಆಯ್ಕೆ. LAN ಗೇಟ್ವೇ ಕಡೆಗೆ ತೋರಿಸುವ ಹೋಸ್ಟ್ ಮಾರ್ಗ, ಜೊತೆಗೆ ಎಲ್ಲಾ ವಿಳಾಸಗಳ ಬದಲು ಭೌತಿಕ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸಿದ ಡೀಮನ್, ಆ ಒಂದು ಹರಿವನ್ನು ಟನೆಲ್ನ ಹೊರಗೆ ಇಡುತ್ತದೆ. ಬದಲಾವಣೆ ಸ್ಥಳೀಯ ಮತ್ತು ಹಿಂತಿರುಗಿಸಲು ಸುಲಭ.

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

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

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

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

ಬಾಕ್ಸ್ LAN ಗೂ ರೂಟ್ ಮಾಡಿದಾಗ

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

ನಂತರ ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್ ಎಂದೂ ದಾಖಲಿಸದ ಹರಿವಿಗೆ ಉತ್ತರವನ್ನು ನೋಡಿ ಅದನ್ನು ಬೀಳಿಸುತ್ತದೆ. ಗಮ್ಯಸ್ಥಾನ ಅನುವಾದವು ಒಳಬರುವ ಸಂಪರ್ಕವನ್ನು ಸಾಧನಕ್ಕೆ ತಲುಪಿಸುತ್ತದೆ, ಮತ್ತು ಮೂಲ ಅನುವಾದವು ಉತ್ತರವು ರೌಟರ್ನಿಂದಲೇ ಬಂದಂತೆ ತೋರಿಸುತ್ತದೆ.

ರವಾನೆಯಾದ ಪೋರ್ಟ್ ಅನ್ನು WAN ನಲ್ಲಿ ಇರಿಸಿಕೊಂಡು ರೌಟರ್ನ ಸ್ವಂತ ಸಂಚಾರ ಟನೆಲ್ ಬಳಸುವ ಪಾಲಿಸಿ ಮಾರ್ಗವು ಹೆಚ್ಚು ಸ್ವಚ್ಛವಾದ ಸಮಾನ. ಮೂಲ ಅನುವಾದವಿಲ್ಲದೆ ಉತ್ತರವು ಬಾಹ್ಯ ಕ್ಲೈಂಟ್ಗೆ ಉದ್ದೇಶಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಒಳಗಿನ ಸಾಧನಕ್ಕೆ ಆ ವಿಳಾಸಕ್ಕೆ ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ.

ಕಾರಣಗಳನ್ನು ಬೇರ್ಪಡಿಸುವ ಮೂರು ಪರೀಕ್ಷೆಗಳು

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

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

ವಿನಾಯಿತಿ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಹೆಸರಿಸುತ್ತದೆ ಎಂದು ದಾಖಲಿಸಿ ಮತ್ತು ಸಂರಚನೆಯನ್ನು ಆವೃತ್ತಿ ನಿಯಂತ್ರಣದಲ್ಲಿ ಇರಿಸಿ. ನವೀಕರಣದ ನಂತರ ಹೆಸರು ಬದಲಾಗುವ ಇಂಟರ್ಫೇಸ್ ವಿರುದ್ಧ ಬರೆದ ನಿಯಮ ಇಂದು ಉತ್ತೀರ್ಣವಾಗುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ರೀಬೂಟ್ ನಂತರ ವಿಫಲವಾಗುತ್ತದೆ.