ಮನೆಯ VPN ಸರ್ವರ್‌ಗೆ ಡೈನಾಮಿಕ್ DNS ಬೇಕೇ?

ನನ್ನನ್ನು ಕೇಳುವ ಮನೆಯ VPN ವೈಫಲ್ಯಗಳಲ್ಲಿ ಬಹುಪಾಲು DNS ವೈಫಲ್ಯಗಳಲ್ಲ, ಆದರೂ ಜನರು ಮೊದಲು ಡೈನಾಮಿಕ್ DNS ಚಂದಾದಾರಿಕೆ ಖರೀದಿಸುತ್ತಾರೆ. ಏನನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಮೊದಲು, ಹೋಸ್ಟ್‌ನಾಮ್ ನಿಜವಾಗಿ ಮುರಿದ ಭಾಗವೇ ಎಂದು ನಿರ್ಧರಿಸಿ. ನವೀಕರಣಕಾರ ನಿಮ್ಮ ISP ನೀಡಿದ ವಿಳಾಸ ಬದಲಾದಾಗ ದಾಖಲೆಯನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ; ಅದು ಪೋರ್ಟ್ ತೆರೆಯಲಾರದು, ಕ್ಯಾರಿಯರ್ NAT ಭೇದಿಸಲಾರದು ಅಥವಾ ಚಾಲನೆಯಲ್ಲಿರುವ WireGuard ಸೆಷನ್ ತನ್ನ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಬದಲಾಗಿದೆ ಎಂದು ಗಮನಿಸುವಂತೆ ಮಾಡಲಾರದು. ಡೈನಾಮಿಕ್ DNS ಪೂರ್ಣ ಪರಿಹಾರವೇ ಅಥವಾ ಅದರ ಒಂದೇ ಸಾಲೇ ಎಂದು ಮೂರು ಷರತ್ತುಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ.

ಷರತ್ತು ಒಂದು: ನಿಮ್ಮ ವಿಳಾಸ ನಿಜವಾಗಿ ಬದಲಾಗುತ್ತದೆ

ವಸತಿ ವಿಳಾಸಗಳು ಸಾಮಾನ್ಯ ಕಾರಣಗಳಿಗೆ ಬದಲಾಗುತ್ತವೆ: ವಿದ್ಯುತ್ ಕಡಿತದ ನಂತರ ಮೊಡೆಮ್ ಮತ್ತೆ ಸಿಂಕ್ ಆಗುತ್ತದೆ, ISP ಪೂಲ್ ಮರುಸಮತೋಲನ ಮಾಡುತ್ತದೆ, ದೀರ್ಘ ಅಡಚಣೆಯ ನಂತರ ಹೊಸ ಗುತ್ತಿಗೆ ಬರುತ್ತದೆ. ಕೆಲವು ಲೈನ್‌ಗಳಲ್ಲಿ ಅವು ಬಹಳ ವಿರಳವಾಗಿ ಬದಲಾಗುತ್ತವೆ, ಮತ್ತು ಅದೇ ವಿಳಾಸ ಒಂದು ವರ್ಷ ಉಳಿದಿರುವುದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ; ವ್ಯಾಪಾರ ಪ್ಲಾನ್‌ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಥಿರ ವಿಳಾಸ ಇರುತ್ತದೆ. ಹನ್ನೆರಡು ತಿಂಗಳಲ್ಲಿ ಏನೂ ಬದಲಾಗಿಲ್ಲದಿದ್ದರೆ, ಕೈಯಿಂದ ಸಂಪಾದಿಸುವ ಒಂದು A ದಾಖಲೆ ಒಂದು ಡೀಮನ್ ಕಡಿಮೆ ಜೀವಂತವಾಗಿಡಬೇಕಾದದ್ದು.

ಊಹಿಸುವ ಬದಲು ಅಳೆಯಿರಿ. ರೌಟರ್‌ನ ಸ್ಥಿತಿ ಪುಟದಲ್ಲಿ WAN ವಿಳಾಸ ಓದಿ, ನಂತರ ಹೊರಗಿನ ಪ್ರಪಂಚ ಕಾಣುವುದರೊಂದಿಗೆ ಹೋಲಿಸಿ. ಇದನ್ನು LAN ನ ಯಂತ್ರದಿಂದ ಚಲಾಯಿಸಿ:

curl -fsS https://api.ipify.org; echo

ಎರಡು ಮೌಲ್ಯಗಳು ಭಿನ್ನವಾಗಿದ್ದರೆ, ನಿಮ್ಮ ರೌಟರ್ ಮುಂದೆ ಏನೋ ಅನುವಾದಿಸುತ್ತಿದೆ ಮತ್ತು ಯಾವುದೇ ಹೋಸ್ಟ್‌ನಾಮ್ ನವೀಕರಣ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. 100.64.0.0/10 ಒಳಗಿನ ವಿಳಾಸ ಕ್ಯಾರಿಯರ್-ಗ್ರೇಡ್ NAT ಗಾಗಿ ಹಂಚಿಕೊಂಡ ಶ್ರೇಣಿ, ಮತ್ತು ಸರಿಯಾಗಿ ನವೀಕರಿಸಿದ ಹೆಸರೂ ಹೊರಗಿನಿಂದ ಸಮಯ ಮೀರುವ ಸಾಮಾನ್ಯ ಕಾರಣ ಅದೇ.

ಷರತ್ತು ಎರಡು: ಕ್ಲೈಂಟ್‌ಗಳು ಹೆಸರನ್ನು ಮತ್ತೆ ಹುಡುಕುತ್ತವೆ

ಸಣ್ಣ TTL ಜನರು ಬಿಟ್ಟುಬಿಡುವ ಭಾಗ. ಪುನರಾವರ್ತಕ ರಿಝಾಲ್ವರ್‌ಗಳು ದಾಖಲೆಯ TTL ಗೌರವಿಸುತ್ತವೆ, ಆದರೆ ಕ್ಲೈಂಟ್ ಸ್ಟ್ಯಾಕ್‌ಗಳು ಪ್ರತ್ಯೇಕವಾಗಿ ಕ್ಯಾಶ್ ಮಾಡುತ್ತವೆ, ಮತ್ತು ಈಗಾಗಲೇ ಎದ್ದಿರುವ ಸುರಂಗ ಏನನ್ನೂ ಮತ್ತೆ ಪರಿಹರಿಸುವುದಿಲ್ಲ. ಡೀಬಗ್ ಮಾಡುವಾಗ ದಾಖಲೆಯನ್ನು 60-300 ಸೆಕೆಂಡಿಗೆ ಇರಿಸಿ; ಅದು ಹಳೆಯ ಉತ್ತರ ನೀಡುವ ಕಿಟಕಿಯನ್ನು ಚುಟುಕುಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಸಂಪರ್ಕಿತ ಸೆಷನ್ ಅನ್ನು ಸ್ಥಳಾಂತರಿಸುವುದಿಲ್ಲ.

OpenVPN ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದಾಗಲೆಲ್ಲಾ ಸಾಲನ್ನು remote vpn.example.net 1194 ಮತ್ತೆ ಪರಿಹರಿಸುತ್ತದೆ, ಮತ್ತು resolv-retry infinite ಹುಡುಕಾಟ ವಿಫಲವಾದಾಗ ನಿರ್ಗಮಿಸುವ ಬದಲು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. ಸರ್ವರ್‌ನಲ್ಲಿ float ಸ್ಥಾಪಿತ ಸೆಷನ್ ತನ್ನ ಮೂಲ ವಿಳಾಸ ಬದಲಾದ ಸಹವರ್ತಿಯನ್ನು ಅನುಸರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. WireGuard ಹೆಚ್ಚು ನೇರ: wg-quick up ಸಂರಚನೆ ಅನ್ವಯವಾದಾಗ Endpoint ಪರಿಹರಿಸುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಸುರಂಗವನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸಿದಾಗ ಅದನ್ನು ಮತ್ತೆ ಪರಿಹರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹಳೆಯ ವಿಳಾಸದ ವಿರುದ್ಧ ಇನ್ನೂ ಯಶಸ್ವಿಯಾಗುವ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ನಿಲ್ಲುವವರೆಗೆ ಯಶಸ್ವಿಯಾಗಿ ಉಳಿಯುತ್ತದೆ.

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

ಷರತ್ತು ಮೂರು: ಒಳಗಿನ ದಾರಿ ಇನ್ನೂ ತೆರೆದಿದೆ

ಡೈನಾಮಿಕ್ DNS ಹೆಸರು ಎಲ್ಲಿಗೆ ತೋರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಬದಲಿಸುತ್ತದೆ, ಬೇರೇನನ್ನೂ ಅಲ್ಲ. ರೌಟರ್‌ನಲ್ಲಿ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್, VPN ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಮತ್ತು ISP ಒಳಬರುವ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಅನುಮತಿ — ಎಲ್ಲವೂ ದಾಖಲೆ ಮುಖ್ಯವಾಗುವ ಮೊದಲು ಇರಬೇಕು. ಫಾರ್ವರ್ಡಿಂಗ್ ಯಾವುದನ್ನು ಗುರಿಯಾಗಿಸುತ್ತದೆ ಎಂದು ನೋಡಿ: ಅದು ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಬದಲು WAN ವಿಳಾಸಕ್ಕೆ ಪಿನ್ ಆಗಿದ್ದರೆ, ವಿಳಾಸ ಬದಲಾವಣೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ಮುರಿಯುತ್ತದೆ ಮತ್ತು ದೋಷ ದಾಖಲೆಯ ಮೇಲೆ ಬೀಳುತ್ತದೆ.

ಹೊರಗಿನಿಂದ ಪರೀಕ್ಷಿಸಿ. Wi-Fi ಆಫ್ ಮಾಡಿ ಸೆಲ್ಯುಲಾರ್ ಡೇಟಾದಲ್ಲಿರುವ ಫೋನ್ ಅತ್ಯಂತ ಅಗ್ಗದ ಪ್ರಾಮಾಣಿಕ ಪರೀಕ್ಷೆ; ಅದೇ LAN ನ ಲ್ಯಾಪ್‌ಟಾಪ್ ಅಲ್ಲ. ಹೆಸರು ನಿಮ್ಮ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಿದಾಗ ಮತ್ತು ರೌಟರ್‌ನಲ್ಲಿ NAT ಲೂಪ್‌ಬ್ಯಾಕ್ ಇಲ್ಲದಿದ್ದಾಗ, ಒಳಗಿನ ಪರೀಕ್ಷೆ ವಿಫಲವಾಗುತ್ತದೆ ಆದರೆ ದಾಖಲೆ ಸಂಪೂರ್ಣ ಸರಿಯಾಗಿರುತ್ತದೆ, ಮತ್ತು ಇದೇ ಬಹುಪಾಲು ಜನರನ್ನು ಎಂದೂ ತಪ್ಪಾಗಿರದ ದಾಖಲೆಯನ್ನು ಸಂಪಾದಿಸಲು ಕಳುಹಿಸುತ್ತದೆ.

ಮೂರೂ ನಿಜವಾದಾಗ ಏನನ್ನು ಚಲಾಯಿಸಬೇಕು

ಸಣ್ಣ ಹೋಸ್ಟ್‌ಗೆ ddclient ಅತ್ಯಂತ ಕಡಿಮೆ ಆಶ್ಚರ್ಯಕರ ನವೀಕರಣಕಾರ. ಕನಿಷ್ಠ ಸಂರಚನೆ ಪೂರೈಕೆದಾರ ಕಾಣುವ ವಿಳಾಸವನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ, ಇದು ಎರಡು NAT ದೋಷವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

ಅದನ್ನು shell ಲೂಪ್ ಬದಲು ಪ್ರತಿ ಕೆಲವು ನಿಮಿಷಗಳಿಗೊಮ್ಮೆ systemd ಟೈಮರ್‌ನಿಂದ ಚಲಾಯಿಸಿ, ಮತ್ತು ಯಶಸ್ಸನ್ನು ಊಹಿಸುವ ಬದಲು ಪೂರೈಕೆದಾರರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಲಾಗ್ ಮಾಡಿ. ರುಜುವಾತುಗಳನ್ನು ಕೀಲಿಯಂತೆ ನೋಡಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಎಲ್ಲಿಗೆ ಕಳುಹಿಸಲ್ಪಡುತ್ತದೆ ಎಂದು ಅದೇ ನಿರ್ಧರಿಸುತ್ತದೆ: ಖಾತೆ ಪಾಸ್‌ವರ್ಡ್ ಬದಲು ಸೀಮಿತ ನವೀಕರಣ ಟೋಕನ್ ಬಳಸಿ, ಫೈಲ್ ಅನ್ನು 0600 ಮೋಡ್‌ನಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ನವೀಕರಣಗಳನ್ನು HTTPS ಮೇಲೆ ಕಳುಹಿಸಿ.

ಬದ್ಧವಾಗುವ ಮೊದಲು ಪರಿಶೀಲಿಸಿ

ಒಂದು ಹುಡುಕಾಟ ಉಳಿದ ಪ್ರಪಂಚ ಏನನ್ನು ಕಾಣುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಬದಲಾವಣೆಯ ನಂತರ ಕಾಯಬೇಕಾದ TTL ಅನ್ನು ಮುದ್ರಿಸುತ್ತದೆ:

dig +noall +answer vpn.example.net @1.1.1.1

ಆ ವಿಳಾಸವನ್ನು ರೌಟರ್‌ನ WAN ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ. ಹೊಂದಿದರೆ, ಹೆಸರು ತನ್ನ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ಇನ್ನೂ ವಿಫಲವಾಗುವುದು ಒಳಬರುವ ತಲುಪುವಿಕೆ, ಕೀಲಿ ಅಥವಾ ಮತ್ತೆ ಪರಿಹರಿಸದ ಕ್ಲೈಂಟ್. ಭಿನ್ನವಾಗಿದ್ದರೆ, ನವೀಕರಣಕಾರ ತಪ್ಪು ಇಂಟರ್‌ಫೇಸ್ ಪ್ರಕಟಿಸುತ್ತಿದೆ, ಹೆಚ್ಚಾಗಿ ಅದು ರೌಟರ್‌ನ ಮೇಲಲ್ಲದೆ ರೌಟರ್ ಹಿಂದಿನ VPN ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಓಡಿದ್ದರಿಂದ.

ಒಂದು ನಿಮಿಷದ ರೋಲ್‌ಬ್ಯಾಕ್ ಇರಿಸಿಕೊಳ್ಳಿ: ಕೊನೆಯದಾಗಿ ಕೆಲಸ ಮಾಡಿದ ವಿಳಾಸ ಮತ್ತು ಹಿಂದಿನ TTL ಬರೆದಿಡಿ, ಪೂರೈಕೆದಾರರಿಗೆ ಕೆಟ್ಟ ಮಧ್ಯಾಹ್ನವಿದ್ದಾಗ ಎರಡನ್ನೂ ಕೈಯಿಂದ ಪ್ರಕಟಿಸಬಹುದು.

ಉತ್ತರ ಇಲ್ಲ ಎಂದಾಗ

ಷರತ್ತು ಒಂದು ಅಥವಾ ಮೂರು ವಿಫಲವಾದರೆ, ಸಂರಚನೆ ಅಲ್ಲ, ನಿರ್ಧಾರ ಬದಲಾಗುತ್ತದೆ. ಕ್ಯಾರಿಯರ್ NAT ಹಿಂದೆ ನಿಮ್ಮ ಪ್ರಾಯೋಗಿಕ ಆಯ್ಕೆಗಳು ISP ಯಿಂದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಕೇಳುವುದು, ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ಸ್ಥಿರ ವಿಳಾಸವಿರುವ ಸಣ್ಣ VPS ಗೆ ಸರಿಸುವುದು, ಅಥವಾ ತನ್ನದೇ ಭೇಟಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವ ಒವರ್‌ಲೇ ಬಳಸುವುದು. ವಿಳಾಸ ಸ್ಥಿರವಾಗಿದ್ದರೆ, ನವೀಕರಣಕಾರವನ್ನು ಬಿಟ್ಟುಬಿಡಿ: ಒಂದು A ದಾಖಲೆ, IPv6 ಬಳಸಿದರೆ ಒಂದು AAAA ದಾಖಲೆ, ಅದೇ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್.

ಕ್ಲೈಂಟ್‌ಗಳು ಸಂಪರ್ಕದಲ್ಲಿರುವಾಗ ವಿಳಾಸ ಬದಲಾದರೆ, ಪ್ರಾಮಾಣಿಕ ಸರಿಪಡಿಸುವಿಕೆ ಕ್ಲೈಂಟ್‌ನಲ್ಲೇ ಇರುತ್ತದೆ: ಮರುಸಂಪರ್ಕ ತರ್ಕ ಮತ್ತು ಮರುಪ್ರಯತ್ನ ಮಧ್ಯಂತರ, ವೇಗದ ನವೀಕರಣಕಾರವಲ್ಲ. ಎರಡನೇ ಪೂರೈಕೆದಾರ ಸೇರಿಸಿದರೆ ಮಧ್ಯಂತರ ಮರೆಯಾಗುತ್ತದೆ ಅಷ್ಟೇ.

ಮುಂದುವರಿಯುವ ಮೊದಲು ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ಕ್ರಮವಾಗಿ ದೃಢೀಕರಿಸಿ:

• ನವೀಕರಣಕಾರ ಪ್ರಕಟಿಸುವ ವಿಳಾಸ ರೌಟರ್‌ನ WAN ವಿಳಾಸಕ್ಕೆ ಹೊಂದುತ್ತದೆ.
• ದಾಖಲೆಯ TTL ಬದಲಾವಣೆ ಕೆಲವು ನಿಮಿಷಗಳಲ್ಲಿ ಕಾಣುವಷ್ಟು ಚಿಕ್ಕದಾಗಿದೆ.
• ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಬದ್ಧವಾಗಿದೆ, ಸ್ಥಿರ ವಿಳಾಸಕ್ಕಲ್ಲ.
• ಕೊನೆಯ ಬದಲಾವಣೆಯ ನಂತರ ಒಂದು ನಿಜವಾದ ಕ್ಲೈಂಟ್ ಮರುಸಂಪರ್ಕಗೊಂಡು ಸಂಚಾರ ಸಾಗಿಸಿದೆ.

ನಾಲ್ಕೂ ನಿಜವಾದರೆ, ಸಂರಚನೆಯನ್ನು ಬಿಟ್ಟುಬಿಡಿ; ನಿಮ್ಮ ಮುಂದಿನ ವೈಫಲ್ಯ ಹೆಸರಿಸುವ ಸಮಸ್ಯೆಯಲ್ಲ, ಕೀಲಿ ಅಥವಾ ಫೈರ್‌ವಾಲ್ ನಿಯಮ. ಯಾವುದಾದರೂ ವಿಫಲವಾದರೆ, ಇನ್ನೊಂದು ಚಲಿಸುವ ಭಾಗ ಸೇರಿಸುವ ಮೊದಲು ಆ ಸಾಲನ್ನು ಸರಿಪಡಿಸಿ. RFC 2136 ನವೀಕರಣ ಕಾರ್ಯವಿಧಾನವನ್ನೇ ವಿವರಿಸುತ್ತದೆ, ಡೀಮನ್ ತಂತಿಗೆ ಏನನ್ನು ಹಾಕುತ್ತದೆ ಎಂದು ನೋಡಲು ಬಯಸಿದರೆ.