LAN ಹೋಸ್ಟ್ OpenVPN ಕ್ಲೈಂಟ್ ವಿಳಾಸಕ್ಕೆ ARP ಏಕೆ ಕಳುಹಿಸುತ್ತದೆ

LAN ಹೋಸ್ಟ್ ಮತ್ತು VPN ಕ್ಲೈಂಟ್ ನಡುವಿನ ತಲುಪುವಿಕೆ ಸಮಸ್ಯೆಗಳು ಹೆಚ್ಚಾಗಿ ವಿಳಾಸ ಯೋಜನೆಗೇ ಮರಳುತ್ತವೆ. ಆ ಹೋಸ್ಟ್ಗೆ 10.0.100.0/22 ಮೇಲೆ ಇಂಟರ್ಫೇಸ್ ಕೊಡಿ; ಅದು 10.0.100.0 ರಿಂದ 10.0.103.255 ರವರೆಗಿನ ಪ್ರತಿ ವಿಳಾಸವನ್ನು ನೇರವಾಗಿ ಸಂಪರ್ಕಿತ ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ, 10.0.101.0/24 ನಲ್ಲಿ ಸದ್ದಿಲ್ಲದೆ ಇರಿಸಿದ ಕ್ಲೈಂಟ್ ಪೂಲ್ ಸೇರಿದಂತೆ. ಉತ್ತರ ಎಂದಿಗೂ ರೌಟರ್ಗೆ ಹೋಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಹೋಸ್ಟ್ ದೃಷ್ಟಿಯಿಂದ ಯಾವುದೇ ರೌಟರ್ ಒಳಗೊಂಡಿಲ್ಲ. ಪ್ಯಾಕೆಟ್ ನೆರೆಯವರಿಗೆ ವಿಳಾಸವಾಗಿ ತಂತಿಯಲ್ಲಿ ಕೇಳಲಾಗುತ್ತದೆ.

ಈ ಕಾರ್ಯವಿಧಾನವು ಸಂಪೂರ್ಣ ವರದಿಗಳ ಕುಟುಂಬದ ಹಿಂದೆ ಇದೆ: ಸುರಂಗ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಸರ್ವರ್ಗೆ ಮಾರ್ಗವಿದೆ, ಆದರೂ LAN ಹೋಸ್ಟ್ ಕ್ಲೈಂಟ್ ತಲುಪಲಾಗುತ್ತಿಲ್ಲ.

/24 ಅನ್ನು ನುಂಗುವ /22

ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಶ್ರೇಣಿಯಾಗಿ ಓದಿ, ಸ್ಟ್ರಿಂಗ್ ಆಗಿ ಅಲ್ಲ. /22 ನಲ್ಲಿ 1024 ವಿಳಾಸಗಳಿವೆ, 10.0.100.0/22 10.0.100.0 ರಿಂದ 10.0.103.255 ರವರೆಗೆ ವ್ಯಾಪಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ 10.0.101.0/24 ನಲ್ಲಿನ ಪೂಲ್ ಸಂಪೂರ್ಣವಾಗಿ ಅದರ ಒಳಗಿದೆ. ಈ ತಪ್ಪು ಪರಿಶೀಲನೆಯನ್ನು ದಾಟುತ್ತದೆ, ಏಕೆಂದರೆ ಪೂಲ್ನ ಮೊದಲ ಆಕ್ಟೆಟ್ಗಳು LAN ನ ಮೊದಲ ಆಕ್ಟೆಟ್ಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ ಕಾಣುತ್ತವೆ, ಮೂರನೇ ಆಕ್ಟೆಟ್ ಮಾತ್ರ ಈ ಒಳಗೊಳ್ಳುವಿಕೆಯನ್ನು ಬಯಲು ಮಾಡುತ್ತದೆ. ಎರಡೂ ಶ್ರೇಣಿಗಳನ್ನು ಸಂಖ್ಯೆಗಳಲ್ಲಿ ಬರೆಯಿರಿ, ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಎಂದು ಘೋಷಿಸುವ ಮೊದಲು.

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

ನೇರ ಸಂಪರ್ಕ ಎಂದರೆ ARP, ರೌಟಿಂಗ್ ಅಲ್ಲ

/22 ಇಂಟರ್ಫೇಸ್ ಇರುವ ಹೋಸ್ಟ್ 10.0.101.25 ಗೆ ಕಳುಹಿಸಿದಾಗ, ಕರ್ನಲ್ ಗಮ್ಯವನ್ನು ಇಂಟರ್ಫೇಸ್ ಪ್ರಿಫಿಕ್ಸ್ ಜೊತೆ ಹೋಲಿಸಿ ಹೊಂದಿಕೆ ಕಂಡುಕೊಳ್ಳುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ರೌಟ್ ಆದ ಪ್ಯಾಕೆಟ್ ಬದಲು ನೆರೆ ಹುಡುಕಾಟವಾಗುತ್ತದೆ, ಈಥರ್ನೆಟ್ನಲ್ಲಿ ನೆರೆ ಹುಡುಕಾಟ ಆ ವಿಳಾಸಕ್ಕೆ ARP ವಿನಂತಿ. ವಿಳಾಸವು ರೌಟೆಡ್ ಗೇಟ್ವೇ ಹಿಂದಿನ VPN ಕ್ಲೈಂಟ್ಗೆ ಸೇರಿದ್ದರೆ, LAN ನಲ್ಲಿ ಯಾವುದೇ ಹೋಸ್ಟ್ ಅದನ್ನು ಹೊಂದಿಲ್ಲ, ಆದ್ದರಿಂದ ವಿನಂತಿ ಉತ್ತರವಿಲ್ಲದೆ ಉಳಿಯುತ್ತದೆ, ಪ್ಯಾಕೆಟ್ಗಳು ಬಿಸಾಡಲ್ಪಡುತ್ತವೆ. ಸುರಂಗ ದೋಷಿ ಅಲ್ಲ, ಕ್ಲೈಂಟ್ ಸಂಚಾರವನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ.

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

TUN, TAP ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಏನನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ

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

ತೀರ್ಮಾನಗಳಿಗೆ ಬರುವ ಮೊದಲು ARP ವಿನಂತಿ ಎಲ್ಲಿ ಕಾಣಿಸಿತು, ಯಾವ ವ್ಯವಸ್ಥೆ ಕಳುಹಿಸಿತು ಎಂದು ದಾಖಲಿಸಿ. ಕಳುಹಿಸಿದವರು ಗಮ್ಯದ ಬಗ್ಗೆ ತಾವು ಏನು ಯೋಚಿಸುತ್ತಾರೆ ಎಂದು ಹೇಳುತ್ತಾರೆ, ಸುರಂಗ ಏನು ಮಾಡುತ್ತದೆ ಎಂದಲ್ಲ.

ಅತಿವ್ಯಾಪ್ತಿಯಾಗಲಾಗದ ಪೂಲ್ ವಿನ್ಯಾಸ ಮಾಡಿ

ಪ್ರತಿ ಸಂಪರ್ಕಿತ ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಪ್ರತಿ ಘೋಷಿತ ಸೈಟ್ ಪ್ರಿಫಿಕ್ಸ್ನ ಹೊರಗೆ ಪೂಲ್ ಆಯ್ಕೆ ಮಾಡಿ, ನಂತರ ಅದನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ತಲುಪಬಹುದಾದಂತೆ ಮಾಡುವ ಮಾರ್ಗಗಳನ್ನು ಸೇರಿಸಿ. ಯೋಜನೆಯ ಬಳಸದ ಭಾಗದಲ್ಲಿ 10.8.0.0/24 ನಂತಹ ಶ್ರೇಣಿಯನ್ನು ಯೋಚಿಸುವುದು ಸುಲಭ, ಅದನ್ನು ತಲುಪಬೇಕಾದ LAN, VPN ಸರ್ವರ್ಗೆ ತೋರಿಸುವ ಸ್ಥಿರ ಮಾರ್ಗವನ್ನು ಪಡೆಯುತ್ತದೆ. ಹಂಚಿಕೆ, ಘೋಷಿತ ಮಾರ್ಗಗಳು, ಅನುಮತಿಸಿದ ಮೂಲ ವಿಳಾಸಗಳು ಮತ್ತು ಫೈರ್ವಾಲ್ ನಿಯಮಗಳನ್ನು ಒಟ್ಟಿಗೆ ಬದಲಿಸಿ, ಏಕೆಂದರೆ ಅವು ನಾಲ್ಕು ಸೆಟ್ಟಿಂಗ್ಗಳಲ್ಲ, ಒಂದು ವಿನ್ಯಾಸವನ್ನು ವಿವರಿಸುತ್ತವೆ.

ಸರ್ವರ್ನಲ್ಲಿ Source NAT ಪೂಲ್ ಅನ್ನು LAN ನಿಂದ ರೌಟ್ ಮಾಡಬಹುದಾದ ವಿಳಾಸದ ಹಿಂದೆ ಮರೆಮಾಡಬಹುದು, ಇದು ಕಾನೂನುಬದ್ಧ ಸ್ಥಳಾಂತರ ಸಾಧನ. ಇದು ಮೂಲವನ್ನೂ ಮರುಬರೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ LAN ಸಂಪರ್ಕಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಆರೋಪಿಸುವ, ಕ್ಲೈಂಟ್ ಪ್ರತಿ ನಿಯಮಗಳನ್ನು ಅನ್ವಯಿಸುವ ಸಾಮರ್ಥ್ಯ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.

ಸ್ವೀಕೃತಿಗಾಗಿ ನಿಜವಾದ ಕ್ಲೈಂಟ್ಗೆ ವಾಸ್ತವವಾಗಿ ನಿಗದಿಯಾದ ವಿಳಾಸವನ್ನು ಮತ್ತು LAN ಹೋಸ್ಟ್ನಿಂದ ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಯನ್ನು ಬಳಸಿ, ನಂತರ ಉತ್ತರವು ತಂತಿಗೆ ಬದಲಾಗಿ ಯೋಜಿತ ಗೇಟ್ವೇ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.