VPN ವಿಳಾಸ ಮತ್ತು LAN DHCP ಬಾಡಿಗೆ: ಟನೆಲ್ IP ಯಾರು ನೀಡುತ್ತಾರೆ?

ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು Wi-Fi ಚಿಹ್ನೆಯ ಬದಲು ಅಡಾಪ್ಟರ್ ನೋಡಿ. 10.80.0.14 ನಂತಹ ವಿಳಾಸ ಟನೆಲ್ ಮೇಲೆ ಇರಬಹುದು, ಆದರೆ ಕಚೇರಿ LAN ನ ಯಾವುದೇ DHCP ಸರ್ವರ್ ಆ ಬಾಡಿಗೆಯನ್ನು ಎಂದೂ ದಾಖಲಿಸಿಲ್ಲ. ಯಾವ ಪ್ರಕ್ರಿಯೆ ಸಂಖ್ಯೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿತು ಎಂಬುದು ಸಮಸ್ಯೆ ಪರಿಶೀಲನೆ ಎಲ್ಲಿಂದ ಆರಂಭವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಎಲ್ಲವೂ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತದೆ: ಒಂದು IPv4 ವಿಳಾಸ, ಒಂದು ಮಾಸ್ಕ್, ಕೆಲವೊಮ್ಮೆ ಡೀಫಾಲ್ಟ್ ಗೇಟ್‌ವೇ. ವ್ಯತ್ಯಾಸವು ಆ ವಿಳಾಸಕ್ಕೆ ಯಾರು ಉತ್ತರಿಸುತ್ತಾರೆ ಮತ್ತು ಅದರ ದಾಖಲೆಯನ್ನು ಯಾರು ಇಟ್ಟುಕೊಳ್ಳುತ್ತಾರೆ ಎಂದು ಕೇಳಿದಾಗ ಮಾತ್ರ ಕಾಣಿಸುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ಬದಿಯಿಂದ ಟನೆಲ್ ವಿಳಾಸ ಓದಿ

ಮೊದಲ ಸಾಲಿನ ಬದಲು ಇಡೀ ಬ್ಲಾಕ್ ಓದಿದರೆ Windows ವ್ಯತ್ಯಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ. ipconfig /all ಅಡಾಪ್ಟರ್ ವಿವರಣೆ, ಭೌತಿಕ ವಿಳಾಸ ಮತ್ತು DHCP ಸಾಲನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. PPP ಅಥವಾ IKEv2 ಡಯಲ್-ಅಪ್ ಅಡಾಪ್ಟರ್ ಸಾಮಾನ್ಯವಾಗಿ DHCP ನಿಷ್ಕ್ರಿಯ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಸಂಪರ್ಕವು LAN ಸರ್ವರ್‌ನಿಂದ ಬಾಡಿಗೆ ಪಡೆಯುವ ಬದಲು ಡಯಲ್-ಅಪ್ ಸಮಯದಲ್ಲೇ ತನ್ನ ವಿಳಾಸವನ್ನು ಮಾತುಕತೆ ಮಾಡಿತ್ತು. DHCP ಸಕ್ರಿಯವಾಗಿರುವ ಟನೆಲ್ ಅಡಾಪ್ಟರ್ ಅಸಾಮಾನ್ಯ ಮತ್ತು ಪ್ರತ್ಯೇಕ ತನಿಖೆಗೆ ಅರ್ಹ.

Linux ಅದೇ ಮಾಹಿತಿಯನ್ನು ಎರಡು ಉಪಕರಣಗಳ ನಡುವೆ ಹಂಚುತ್ತದೆ. ip -4 addr show dev tun0 ವಿಳಾಸ ಮತ್ತು ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದವನ್ನು ನೀಡುತ್ತದೆ. nmcli -f IP4 connection show work ಮೌಲ್ಯವು ಸಂಪರ್ಕ ಪ್ರೊಫೈಲ್‌ನಿಂದ, ಲಿಂಕ್‌ನಲ್ಲಿ ನಡೆದ DHCP ವಿನಿಮಯದಿಂದ ಅಥವಾ ತಳ್ಳಲಾದ ಸಂರಚನೆಯಿಂದ ಬಂದಿದೆಯೇ ಎಂದು ಬಯಲು ಮಾಡುತ್ತದೆ. WireGuard ಅತ್ಯಂತ ಸ್ಪಷ್ಟ ಪ್ರಕರಣ, ಏಕೆಂದರೆ ಇಂಟರ್ಫೇಸ್ ಕಾಣಿಸಿಕೊಂಡಾಗ wg-quick ಸಂರಚನಾ ಕಡತದ Address ಸಾಲನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ ಮತ್ತು ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಯಾವುದೇ ಪೀರ್ ಏನನ್ನೂ ಹಂಚುವುದಿಲ್ಲ.

ಪ್ರಿಫಿಕ್ಸ್ ಕೂಡ ಏನೋ ಹೇಳುತ್ತದೆ. /32, ಅಥವಾ 255.255.255.255 ಮಾಸ್ಕ್ ಎಂದರೆ ಗೇಟ್‌ವೇ ಒಂದೇ ಹೋಸ್ಟ್ ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗನಿರ್ದೇಶನ ಮಾಡಲು ನಿರೀಕ್ಷಿಸುತ್ತದೆ, ಆದರೆ ಅಗಲವಾದ ಮಾಸ್ಕ್ ಟನೆಲ್‌ನ ಹಿಂದೆ ಎಲ್ಲೋ ಇರುವ ಆನ್-ಲಿಂಕ್ ಉಪಜಾಲವನ್ನು ಸೂಚಿಸುತ್ತದೆ.

IKEv2 ಸಂರಚನಾ ಪೇಲೋಡ್ ಏನನ್ನು ಒಯ್ಯುತ್ತದೆ

ಈ ಕೆಲಸಕ್ಕೆ IKEv2 ಗೆ ಮೀಸಲಾದ ಕಾರ್ಯವಿಧಾನವಿದೆ. RFC 7296, ವಿಭಾಗ 3.15.1 ರಲ್ಲಿ ವಿವರಿಸಲಾದ ಸಂರಚನಾ ಪೇಲೋಡ್ INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS ಮತ್ತು ಅವುಗಳ IPv6 ಸಮಾನಾಂತರಗಳಂತಹ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಒಯ್ಯುತ್ತದೆ. ಆದ್ಯತೆ ಇಲ್ಲದಿದ್ದಾಗ ಕ್ಲೈಂಟ್ ಶೂನ್ಯ ಉದ್ದದ ಮೌಲ್ಯವಿರುವ ಗುಣಲಕ್ಷಣ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತ್ಯುತ್ತರಿಸುವವರು ಬಳಸಬೇಕೆಂದು ಬಯಸುವ ಮೌಲ್ಯವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತಾರೆ. ಆ ವಿನಿಮಯವು ಈಗಾಗಲೇ ಗೂಢಲಿಪೀಕರಿಸಲಾದ IKE_AUTH ಒಳಗೆ ನಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ DHCP ಪ್ರಸಾರ ಟನೆಲ್ ದಾಟುವುದಿಲ್ಲ.

ಎರಡು ಪರಿಣಾಮಗಳು ಉಂಟಾಗುತ್ತವೆ. ಮೊದಲನೆಯದಾಗಿ, ವಿಳಾಸವನ್ನು ಪ್ರತ್ಯುತ್ತರಿಸುವವರು ಅಥವಾ ಅವರು ಸಲಹೆ ಪಡೆಯುವ ಯಾವುದೇ ಅಧಿಕಾರ ನೀಡುವ ಬ್ಯಾಕೆಂಡ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪೂಲ್ ಗೇಟ್‌ವೇಯಲ್ಲಿ, RADIUS ಉತ್ತರದಲ್ಲಿ ಅಥವಾ ಗುರುತು ಪೂರೈಕೆದಾರರ ಮ್ಯಾಪಿಂಗ್‌ನಲ್ಲಿ ಇರಬಹುದು. ಎರಡನೆಯದಾಗಿ, DNS ಗುಣಲಕ್ಷಣವು ವಿಳಾಸದ ಗುಣಲಕ್ಷಣದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿದೆ. 10.80.0.14 ಸ್ವೀಕರಿಸುವುದರಿಂದ ಯಾವ ರಿಜಾಲ್ವರ್ ಹಿಂತಿರುಗಿತು ಅಥವಾ ಯಾವುದಾದರೂ ಹಿಂತಿರುಗಿತೇ ಎಂಬುದು ಏನೂ ತಿಳಿಯದು.

ನೆಟ್‌ಮಾಸ್ಕ್ ಗುಣಲಕ್ಷಣವು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಐಚ್ಛಿಕ. ಅನೇಕ ನಿಯೋಜನೆಗಳು ಕೇವಲ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸಿ ಕ್ಲೈಂಟ್‌ಗೆ ಹೋಸ್ಟ್ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸಲು ಬಿಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಅದೇ ಪೂಲ್ ಒಬ್ಬ ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ /32 ಮತ್ತು ಇನ್ನೊಂದರಲ್ಲಿ /24 ಎಂಬಂತೆ ಕಾಣಬಹುದು.

LAN DHCP ವ್ಯಾಪ್ತಿ ಮತ್ತು VPN ಪೂಲ್ ಘರ್ಷಿಸುವ ಸ್ಥಳ

ಎರಡೂ ಹಂಚಿಕೆದಾರರು ಒಂದೇ ಶ್ರೇಣಿಯತ್ತ ತೋರಿಸಿದಾಗ ಸಮಸ್ಯೆ ಆರಂಭವಾಗುತ್ತದೆ. 10.20.30.0/24 ಗಾಗಿ DHCP ಸರ್ವರ್ 10.20.30.128/25 ಗಾಗಿ ಸಂರಚಿಸಲಾದ VPN ಪೂಲ್ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ, ಆದ್ದರಿಂದ ಗೇಟ್‌ವೇ ಅದೇ ವಿಳಾಸವನ್ನು ದೂರದ ಕ್ಲೈಂಟ್‌ಗೆ ನೀಡುತ್ತಿರುವಾಗ 10.20.30.140 ಅನ್ನು ಮುದ್ರಕಕ್ಕೆ ಬಾಡಿಗೆ ನೀಡದಂತೆ ತಡೆಯುವುದು ಯಾವುದೂ ಇಲ್ಲ. ಘರ್ಷಣೆ ದಿನಗಳ ಕಾಲ ಮೌನವಾಗಿರುತ್ತದೆ ಮತ್ತು ನಂತರ ಮಧ್ಯಂತರ ನಕಲಾಗಿ ಹೊರಬರುತ್ತದೆ.

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

ಟನೆಲ್ ಅನ್ನು LAN ಗೆ ಸೇತುವೆ ಮಾಡುವುದು ಆ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ವಿನ್ಯಾಸಕ್ಕೆ ನಿಜವಾಗಿಯೂ ಒಂದೇ ಪ್ರಸಾರ ಕ್ಷೇತ್ರ ಬೇಕಿದ್ದರೆ, VPN ಅಂತ್ಯಬಿಂದುವು ತಾನೇ ವಿಳಾಸ ಹೊರಡಿಸುವ ಬದಲು ರಿಲೇ ಅಥವಾ ಹಂಚಿದ ಅಧಿಕೃತ ಮೂಲದ ಮೂಲಕ DHCP ಸರ್ವರ್‌ನಂತೆಯೇ ಹಂಚಿಕೆ ನಿರ್ಧಾರಗಳಲ್ಲಿ ಭಾಗವಹಿಸಬೇಕು.

ವಿಳಾಸ ಯಾವ ಪ್ರಕ್ರಿಯೆಯ ಒಡೆತನದಲ್ಲಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

ವ್ಯಾಪ್ತಿ ಬದಲಿಸುವ ಮೊದಲು ಒಡೆತನವನ್ನು ಸಾಬೀತು ಮಾಡಿ. ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ವಿಳಾಸ ಮತ್ತು ಪ್ರಿಫಿಕ್ಸ್ ದಾಖಲಿಸಿ. LAN ನಲ್ಲಿ ಬಾಡಿಗೆ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಹುಡುಕಿ. ಗೇಟ್‌ವೇಯಲ್ಲಿ ನೀಡಲು ಸಂರಚಿಸಲಾದ ಪೂಲ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ. ಬಾಡಿಗೆ ಕಡತದಲ್ಲಿ ಕಂಡುಬರುವ ವಿಳಾಸ DHCP ಸರ್ವರ್‌ನದು, ಅಂದರೆ ಟನೆಲ್ ಸೇತುವೆಯಾಗಿದೆ ಅಥವಾ ರಿಲೇ ಆಗಿದೆ; ಕೇವಲ ಗೇಟ್‌ವೇ ಪೂಲ್‌ನಲ್ಲಿ ಕಂಡುಬರುವ ವಿಳಾಸ ಟನೆಲ್ ಅಂತ್ಯಬಿಂದುವಿನದು.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

ಉತ್ತರ ಸ್ಪಷ್ಟವಾದಾಗ ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ದಾಖಲಿಸಿ: ಯಾವ ಘಟಕ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ಹಂಚುತ್ತದೆ, ಅದಕ್ಕೆ ಯಾವ ಶ್ರೇಣಿ ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ, ಹಿಂತಿರುಗುವ ಸಂಚಾರ ಆ ಶ್ರೇಣಿಯನ್ನು ಹೇಗೆ ತಲುಪುತ್ತದೆ ಮತ್ತು ಯಾವ ಸಂಪನ್ಮೂಲಗಳು ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ. ಆ ನಾಲ್ಕು ನಮೂದುಗಳು ವರ್ಚುವಲ್ ಅಡಾಪ್ಟರ್‌ನ ಒಂದು ಸಾಲನ್ನು ಕಾರ್ಯಾಚರಣೆಯ ಸತ್ಯವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತವೆ.

ಅಲ್ಲಿರುವಾಗಲೇ DNS ಗುಣಲಕ್ಷಣಕ್ಕೂ ಪರಿಶೀಲನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ವಿಳಾಸಗಳನ್ನು ನೀಡಿ ರಿಜಾಲ್ವರ್ ನೀಡದ ಪೂಲ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ಅದರ ಸ್ಥಳೀಯ DNS ನಲ್ಲಿ ಬಿಡುತ್ತದೆ, ಇದು LAN ಈಗಾಗಲೇ ಬಳಸುತ್ತಿರುವ ವಿಳಾಸವನ್ನು ನೀಡುವ ಪೂಲ್‌ಗಿಂತ ಬೇರೆ ವೈಫಲ್ಯ.