ಆ L2TP ವಿಳಾಸವು IPCP, LAN ನಲ್ಲಿ DHCP ಲೀಸ್ ಅಲ್ಲ

ಸಂಪರ್ಕ ಎದ್ದು ಬರುತ್ತದೆ ಮತ್ತು ಅಡಾಪ್ಟರ್ ಕಚೇರಿಯ ಶ್ರೇಣಿಯಲ್ಲಿ ವಿಳಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ವಾಭಾವಿಕ ತೀರ್ಮಾನವೆಂದರೆ VPN ನಿಮಗೆ LAN ವಿಳಾಸವನ್ನು ನೀಡಿ ನಿಮ್ಮನ್ನು LAN ನಲ್ಲಿ ಇರಿಸಿತು. ಅದರ ಎರಡೂ ಅರ್ಧಗಳು ಸಂಪೂರ್ಣ ಸರಿಯಲ್ಲ. L2TP PPP ಸೆಷನ್ ಅನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು PPP IPCP ಜೊತೆ ಒಳಗಿನ IPv4 ವಿಳಾಸವನ್ನು ಮಾತುಕತೆ ಮಾಡುತ್ತದೆ. ಆ ವಿಳಾಸವು ಎರಡು ಪಕ್ಷಗಳ ನಡುವೆ ಒಪ್ಪಿದ ಸೆಷನ್ ನಿಯತಾಂಕ, ಕಚೇರಿಯ DHCP ಸರ್ವರ್ ನೀಡುವ ಲೀಸ್ ಅಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಹೊಂದಿರುವುದು ನಿಮ್ಮನ್ನು ಕಚೇರಿಯ ತಂತಿಯಲ್ಲಿ ನೆರೆಯವನನ್ನಾಗಿ ಮಾಡುವುದಿಲ್ಲ.

ಒಂದು ಸಂಪರ್ಕದಲ್ಲಿ ಎರಡು ವಿಳಾಸಗಳು

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

ಈ ಮೂರು ಪಾತ್ರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸುವುದು ಜನರು ಈ ಪದರಕ್ಕೆ ತರುವ ಹೆಚ್ಚಿನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ. VPN ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಖಾಸಗಿ ಸಂಖ್ಯೆ ಸಾಮಾನ್ಯ ಮತ್ತು ನಿರೀಕ್ಷಿತ. ಅದು ಅಂತ್ಯ ಬಿಂದು ನಿಮ್ಮ ಸಾರ್ವಜನಿಕ ನಿರ್ಗಮನವನ್ನು ಬದಲಿಸಿದೆಯೇ ಎಂದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ನಿಮ್ಮ ಸಂಚಾರ ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ತಲುಪುತ್ತದೆ ಎಂಬುದನ್ನು ತನ್ನಿಂದ ತಾನೇ ನಿರ್ಧರಿಸುವುದಿಲ್ಲ.

IPCP ನಿಖರವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ

IPCP ಎಂಬುದು PPP ಗಾಗಿ IPv4 ನಿಯಂತ್ರಣ ಪ್ರೋಟೋಕಾಲ್. ಪ್ರತಿ ಬದಿಯೂ ತನಗೆ ಬೇಕಾದ ಆಯ್ಕೆಗಳನ್ನು ವಿವರಿಸುವ Configure-Request ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ವಿಳಾಸ ಆಯ್ಕೆ ಅವುಗಳಲ್ಲಿ ಒಂದು. ಇನ್ನೂ ವಿಳಾಸವಿಲ್ಲದ ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ 0.0.0.0 ನೊಂದಿಗೆ ಕೇಳುತ್ತದೆ, ಮತ್ತು ಸರ್ವರ್ ಕ್ಲೈಂಟ್ ಬಳಸಬೇಕೆಂದು ಬಯಸುವ ವಿಳಾಸವನ್ನು ಹೊತ್ತ Configure-Nak ನೊಂದಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ನಂತರ ಕ್ಲೈಂಟ್ ಆ ವಿಳಾಸವನ್ನು ಕೇಳುತ್ತದೆ, ಮತ್ತು ಸೆಷನ್ ಸ್ಥಳೀಯ ಹಾಗೂ ದೂರದ ವಿಳಾಸದೊಂದಿಗೆ ಏಳುತ್ತದೆ.

ಆ ವಿನಿಮಯವು PPP ಮತ್ತು IPCP ವಿಶೇಷಣಗಳಲ್ಲಿ ದಾಖಲಾಗಿದೆ, ಮತ್ತು ದೋಷದಂತೆ ಕಾಣುವ ವಿವರವನ್ನು ವಿವರಿಸುತ್ತದೆ: ವಿಳಾಸವನ್ನು ಸರ್ವರ್ ತನ್ನದೇ ನೀತಿಯಿಂದ ಆರಿಸುತ್ತದೆ, ಅದು ಪೂಲ್, ಪ್ರತಿ ಬಳಕೆದಾರರ ಸೆಟ್ಟಿಂಗ್ ಅಥವಾ ದೃಢೀಕೃತ ಗುರುತಿಗೆ ಬದ್ಧವಾದ ವಿಳಾಸವಾಗಿರಬಹುದು. ಪೂಲ್ ಖಾಲಿಯಾದಾಗ, ಅಥವಾ ನೀತಿಯು ವಿನಂತಿಯೊಂದಿಗೆ ಘರ್ಷಿಸಿದಾಗ, ದೃಢೀಕರಣ ಯಶಸ್ವಿಯಾಗಬಹುದು ಆದರೆ ವಿಳಾಸ ಮಾತುಕತೆ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಎಂದಿಗೂ ಸ್ಥಿರಗೊಳ್ಳದ ಸಂಪರ್ಕವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

pppd ಲಾಗ್‌ನಲ್ಲಿ ಸ್ಥಳೀಯ ಮತ್ತು ದೂರದ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುವ ಸಾಲು ಆ ಮಾತುಕತೆಯ ಯಶಸ್ವಿ ಅಂತ್ಯ. ಯಶಸ್ವಿ ದೃಢೀಕರಣದ ಪಕ್ಕದಲ್ಲಿ ಅದರ ಅನುಪಸ್ಥಿತಿ ರುಜುವಾತುಗಳಿಗಲ್ಲ, ವಿಳಾಸದ ಹಂತಕ್ಕೆ ಸೂಚಿಸುತ್ತದೆ.

LAN ನಿಮಗೆ ಏಕೆ ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ

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

ಅತಿಕ್ರಮಿಸುವ ಶ್ರೇಣಿಗಳು ತಮ್ಮ ಕಾಣುವ ಗಾತ್ರಕ್ಕೆ ಹೊಂದದ ತೊಂದರೆ ಉಂಟುಮಾಡುವುದೂ ಇದೇ ಕಾರಣ. ಪೂಲ್ ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ಬಳಸುವ LAN ಜೊತೆ ಅತಿಕ್ರಮಿಸಿದರೆ, ಕ್ಲೈಂಟ್‌ನ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಈಗ ಅದೇ ಪ್ರಿಫಿಕ್ಸ್‌ನಲ್ಲಿ ಎರಡು ಹಕ್ಕುಗಳಿವೆ, ಮತ್ತು ಸುರಂಗಕ್ಕೆ ಸಂಬಂಧವಿಲ್ಲದ ಕಾರಣಗಳಿಂದ ತಪ್ಪಾದದ್ದೇ ಹೆಚ್ಚಾಗಿ ಗೆಲ್ಲುತ್ತದೆ.

ಮೊದಲು ಸೆಷನ್, ನಂತರ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

ಮೊದಲು ಇಂಟರ್ಫೇಸ್, ನಂತರ ಮಾರ್ಗಗಳು, ನಂತರ ಮುಖ್ಯವಾದ ಒಂದು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಪರಿಶೀಲಿಸಿ. ಪ್ರತಿ ಹಂತಕ್ಕೂ ತನ್ನದೇ ವೈಫಲ್ಯ ವಿಧಾನವಿದೆ, ಮತ್ತು ಮೂರನ್ನೂ ಒಟ್ಟಿಗೆ ಪರೀಕ್ಷಿಸಿದರೆ ನಂತರ ಸಮರ್ಥಿಸಲಾಗದ ತೀರ್ಮಾನ ಬರುತ್ತದೆ.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

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

ಮೂರು ಹಂತಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ

ದೃಢೀಕರಣ, ವಿಳಾಸ ಮಾತುಕತೆ ಮತ್ತು ಮುಂದುಗಡೆ ಕಳುಹಿಸುವಿಕೆ ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ಜವಾಬ್ದಾರರಿದ್ದಾರೆ. ರುಜುವಾತುಗಳು ಗುರುತಿನ ಸಮಸ್ಯೆ, IPCP ಖಾಲಿಯಾಗುವುದು ಸರ್ವರ್ ನೀತಿಯ ಸಮಸ್ಯೆ, ಮತ್ತು ಕಾಣೆಯಾದ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಜಾಲ ವಿನ್ಯಾಸದ ಸಮಸ್ಯೆ. ಮೂರನ್ನೂ “VPN ಕೆಟ್ಟುಹೋಗಿದೆ” ಎಂದು ವರದಿ ಮಾಡಿದರೆ ನಿಧಾನ ಪರಿಹಾರ ಖಚಿತ.

ನಿಯೋಜಿತ ವಿಳಾಸ, ಅದು ಬಂದ ಪೂಲ್ ಮತ್ತು LAN ಅದನ್ನು ತಲುಪಬೇಕೇ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ. ಆ ಒಂದು ಟಿಪ್ಪಣಿ ಮುಂದಿನ ವ್ಯಕ್ತಿ DHCP ಲೀಸ್ ಎಂದು ಭಾವಿಸಿ ಎಂದಿಗೂ ಸಂಬಂಧಿಸದ ವ್ಯಾಪ್ತಿಯನ್ನು ಹುಡುಕುವುದನ್ನು ತಡೆಯುತ್ತದೆ.