WireGuard DNS ಪುಶ್ ಮಾಡುವುದಿಲ್ಲ: ಖಾಸಗಿ BIND ವಲಯವನ್ನು ನೀಡುವುದು

ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಕೀಗಳು ಮತ್ತು ಅನುಮತಿಸಿದ IP ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಎಂದಿಗೂ ರಿಜಾಲ್ವರ್ ಸಾಗಿಸುವುದಿಲ್ಲ. ಇಲ್ಲಿ ಸಿದ್ಧ ಖಾಸಗಿ BIND 9 ವಲಯ ಮತ್ತು ಅದನ್ನು ಪರಿಹರಿಸುವ ಪ್ರತಿ-ಲಿಂಕ್ ಕ್ಲೈಂಟ್ ನೀತಿ ಇದೆ.

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

ಸುರಂಗ ಮತ್ತು ರಿಜಾಲ್ವರ್ ಪ್ರತ್ಯೇಕ ಒಪ್ಪಂದಗಳು

WireGuard ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಚಿಕ್ಕದು. ನೀವು ಪಟ್ಟಿ ಮಾಡಿದ ವಿಳಾಸಗಳಿಗೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸರಿಸುತ್ತದೆ ಮತ್ತು ಪೀರ್‌ಗಳನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ; ಆ ಪದರದ ಮೇಲಿನ ಎಲ್ಲವೂ ನಿಮ್ಮ ವಿನ್ಯಾಸ. OpenVPN dhcp-option DNS ಪುಶ್ ಮಾಡಬಲ್ಲದು ಏಕೆಂದರೆ ಅದರ ನಿಯಂತ್ರಣ ಚಾನಲ್ ಸಂರಚನೆಯನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸ ಎರಡರ ನಡುವೆ ಸಂಚರಿಸುವವರನ್ನು ಎಡವಿಸುತ್ತದೆ.

ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ಸುರಂಗ ಹೆಸರು ಪರಿಹಾರದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್‌ಗೆ 10.90.0.1 ಗೆ ಪರಿಪೂರ್ಣ ಮಾರ್ಗ ಇರಬಹುದು ಮತ್ತು ಆದರೂ ತನ್ನ ಪ್ರಶ್ನೆಗಳನ್ನು ಸಾರ್ವಜನಿಕ ರಿಜಾಲ್ವರ್‌ಗೆ ಕಳುಹಿಸಬಹುದು, ಆದ್ದರಿಂದ ಲಕ್ಷಣ “VPN DNS ಮುರಿಯಿತು” ಎಂಬಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ DNS ಎಂದಿಗೂ VPN ಕಡೆಗೆ ತೋರಿಸಿರಲಿಲ್ಲ.

ಪುನರಾವರ್ತಕ ರಿಜಾಲ್ವರ್ ಆಗದೆ ವಲಯವನ್ನು ನೀಡಿ

ಸರ್ವರ್ ಬದಿ ಒಂದು ಸಣ್ಣ ಅಧಿಕೃತ ವಲಯ, ಸಾಮಾನ್ಯ ರಿಜಾಲ್ವರ್ ಅಲ್ಲ. ಈ ಉದಾಹರಣೆಯಲ್ಲಿ ಗೇಟ್‌ವೇ 10.90.0.1, ಕ್ಲೈಂಟ್‌ಗಳು 10.90.0.0/24, ಮತ್ತು ನಿಮಗೆ ಮುಖ್ಯವಾದ ಅಪ್ಲಿಕೇಶನ್ 10.60.0.20 ನಲ್ಲಿ ಉತ್ತರಿಸುತ್ತದೆ.

ಎರಡನೇ ಬ್ಲಾಕ್ ರಚಿಸುವ ಬದಲು ಈ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ options ಬ್ಲಾಕ್‌ಗೆ ವಿಲೀನಗೊಳಿಸಿ:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

ನಂತರ ವಲಯ ಮತ್ತು ಅದರ ಫೈಲ್ ಘೋಷಿಸಿ:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

ಮರುಲೋಡ್ ಮಾಡುವ ಮೊದಲು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಲೋಡ್ ಸಮಯದಲ್ಲಿ ವಾಕ್ಯರಚನೆ ದೋಷ ಅದು ಸೇವೆ ನೀಡುವ ಪ್ರತಿ ವಲಯಕ್ಕೂ ಇಡೀ ಸರ್ವರ್ ಅನ್ನು ಬೀಳಿಸುತ್ತದೆ:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

UDP ಮತ್ತು TCP 53 ಅನ್ನು VPN ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಮಾತ್ರ ತೆರೆಯಿರಿ. ಸಾರ್ವಜನಿಕ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಖಾಸಗಿ ಅಧಿಕಾರವನ್ನು ಪ್ರಕಟಿಸುವುದು ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಎಣಿಕೆ ಎರಡನ್ನೂ ಆಮಂತ್ರಿಸುತ್ತದೆ, ಮತ್ತು allow-transfer ದ್ವಿತೀಯಕ್ಕೆ ನಿಜವಾಗಿ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ ಮುಚ್ಚಿದ್ದೇ ಇರಬೇಕು.

ಕ್ಲೈಂಟ್ ಅನ್ನು ಅದರ ಕಡೆಗೆ ತೋರಿಸಿ, ಪ್ರತಿ ಲಿಂಕ್‌ಗೆ

ಸಂಪರ್ಕವನ್ನು NetworkManager ಹೊಂದಿದೆ ಮತ್ತು systemd-resolved ರಿಜಾಲ್ವರ್ ಎಂದು ಊಹಿಸಿ. ಮೊದಲು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನೀತಿಯನ್ನು ಓದಿ, ವಿಶೇಷವಾಗಿ ಯಾವುದೇ ಮೂಲ ಮಾರ್ಗನಿರ್ದೇಶನ ಡೊಮೇನ್, ಏಕೆಂದರೆ ~. ನಮೂದು ನೀವು ಸೇರಿಸಲಿರುವುದನ್ನು ಮೀರುತ್ತದೆ.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

ಟಿಲ್ಡೆ ಮುಖ್ಯ ಅಕ್ಷರ. ಅದು ಡೊಮೇನ್ ಅನ್ನು ಮಾರ್ಗ-ಮಾತ್ರ ಎಂದು ಗುರುತಿಸುತ್ತದೆ: corp.example ಅಡಿಯಲ್ಲಿನ ಹೆಸರುಗಳು ಈ ಲಿಂಕ್‌ನ DNS ಸರ್ವರ್‌ಗೆ ಹೋಗುತ್ತವೆ, ಮತ್ತು ಡೊಮೇನ್ ಸಣ್ಣ ಹೆಸರಿನ ಹುಡುಕಾಟ ಪ್ರತ್ಯಯವಾಗಿ ಸೇರಿಸಲ್ಪಡುವುದಿಲ್ಲ. ಅದಿಲ್ಲದೆ, portal ಟೈಪ್ ಮಾಡುವುದು portal.corp.example ಪರಿಹರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಇದು ನಿಮಗೆ ಅನುಕೂಲಕರ ಮತ್ತು ಉಳಿದವರಿಗೆ ಆಶ್ಚರ್ಯಕರ. ಟಿಲ್ಡೆಯನ್ನು ಉದ್ಧರಣ ಚಿಹ್ನೆಗಳ ಒಳಗೆ ಇರಿಸಿ, ಏಕೆಂದರೆ ಉದ್ಧರಣವಿಲ್ಲದ್ದು ನಿಮ್ಮ ಮನೆ ಕೋಶವನ್ನು ತೋರಿಸಲು ಕಾಯುತ್ತಿರುವ ಶೆಲ್ ವಿಸ್ತರಣೆ.

ಬದಲಾವಣೆಯನ್ನು ಇಂಟರ್ಫೇಸ್ ಹೊಂದಿರುವ ನಿರ್ವಾಹಕರ ಮೂಲಕ ಅನ್ವಯಿಸಿ, ನಂತರ ಸಂಪರ್ಕವನ್ನು ಮತ್ತೆ ಸೇರಿಸಿ. ಅದೇ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಎರಡನೇ wg-quick ನಿದರ್ಶನವನ್ನು ಪ್ರಾರಂಭಿಸಬೇಡಿ; ಇಬ್ಬರು ಮಾಲೀಕರು ಮಾರ್ಗಗಳಿಗಾಗಿ ಹೋರಾಡುತ್ತಾರೆ ಮತ್ತು ಅವರಲ್ಲಿ ಒಬ್ಬರು ಅತ್ಯಂತ ಕೆಟ್ಟ ಕ್ಷಣದಲ್ಲಿ ಗೆಲ್ಲುತ್ತಾರೆ.

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

ಕ್ಲೈಂಟ್‌ನಿಂದ ಹೆಸರನ್ನು ಪ್ರಶ್ನಿಸಿ ಮತ್ತು ಉತ್ತರ ಹಾಗೂ ಅದನ್ನು ಉತ್ಪಾದಿಸಿದ ಸರ್ವರ್ ಎರಡನ್ನೂ ದೃಢೀಕರಿಸಿ:

resolvectl query portal.corp.example

ಅದು 10.60.0.20 ಹಿಂತಿರುಗಿಸಿದರೆ, DNS ಒಪ್ಪಂದ ಪೂರ್ಣಗೊಂಡಿದೆ. ಸಮಯ ಮುಗಿದರೆ, ಮೊದಲು 10.90.0.1 ಗೆ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಫೈರ್‌ವಾಲ್ ನಿಯಮ, ನಂತರ ಸರ್ವರ್‌ನಲ್ಲಿ allow-query. ಈ ಸಂರಚನೆಯಲ್ಲಿ ಹೆಸರು ಪರಿಹಾರ ವೈಫಲ್ಯಗಳು ಬಹುತೇಕ ಯಾವಾಗಲೂ ತಲುಪುವಿಕೆ ಅಥವಾ ACL, ವಲಯ ಫೈಲ್ ಅಲ್ಲ. ಕ್ಲೈಂಟ್‌ನಿಂದ ಹೊರಕ್ಕೆ ಕೆಲಸ ಮಾಡಿ, ಏಕೆಂದರೆ ಪ್ರಶ್ನೆ ಏಕೆ ಎಂದಿಗೂ ಬರಲಿಲ್ಲ ಎಂದು ಸರ್ವರ್ ನಿಮಗೆ ಹೇಳಲಾರದು.

ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಇನ್ನೂ ತನ್ನದೇ ಮಾರ್ಗ ಮತ್ತು ತನ್ನದೇ ಸೇವಾ ಅನುಮತಿ ಬೇಕು ಎಂದು ನೆನಪಿಡಿ. ತಲುಪಲಾಗದ ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುವ ಪರಿಹರಿಸಿದ ಹೆಸರು ಅದೇ ಉಡುಪಿನಲ್ಲಿ ಇನ್ನೊಂದು ವೈಫಲ್ಯ.

ಇನ್ನೂ ಸ್ವಯಂಚಾಲಿತವಲ್ಲದ್ದು

ತಮ್ಮದೇ ರಿಜಾಲ್ವರ್ ತರ್ಕವಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸಿಸ್ಟಂ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ, ಮತ್ತು ಎಷ್ಟೇ nmcli ಇದ್ದರೂ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. DNSSEC ಪರಿಶೀಲಿಸುವ ನಿಯೋಜನೆಗಳಿಗೆ ಖಾಸಗಿ ವಲಯಕ್ಕೆ ಸ್ಪಷ್ಟ ಟ್ರಸ್ಟ್ ಆಂಕರ್ ವಿನ್ಯಾಸ ಬೇಕು; ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಸಾರ್ವತ್ರಿಕ ಸೂಚನೆ ಉತ್ತರವಲ್ಲ. ನಿಮ್ಮ ಬಳಕೆದಾರರು ಚಲಾಯಿಸುವ ಅದೇ ಕ್ಲೈಂಟ್ ತಂತ್ರಾಂಶದೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ, ಆಕಸ್ಮಿಕವಾಗಿ ಸಿಸ್ಟಂ ರಿಜಾಲ್ವರ್ ಬಳಸುವ ಉಪಕರಣದೊಂದಿಗೆ ಅಲ್ಲ. ಆ ಎರಡರ ನಡುವಿನ ಅಂತರವೇ ಇಡೀ ದೋಷ ವರದಿ.

ಫ್ಲೀಟ್‌ಗಳು ತಮ್ಮ ಒದಗಿಸುವಿಕೆ ವ್ಯವಸ್ಥೆಯ ಮೂಲಕ ಈ ಕ್ಲೈಂಟ್ ನೀತಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಹುದು, ಆದರೆ ನೀತಿ ಮಾಲೀಕರನ್ನು ಹೊಂದಿದ ಪ್ರತ್ಯೇಕ ವಸ್ತುವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ. BIND 9 ಉಲ್ಲೇಖ ಮೇಲೆ ಬಳಸಿದ ಆಲಿಸುವಿಕೆ ಮತ್ತು ಪ್ರಶ್ನೆ ನಿಯಂತ್ರಣಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಮತ್ತು ನಿಮ್ಮ ಸ್ಥಾಪಿತ ಆವೃತ್ತಿಗೆ ವರ್ತನೆಯನ್ನು ದೃಢೀಕರಿಸಲು ಸರಿಯಾದ ಸ್ಥಳ ಅದೇ.

ಮುಂದಿನ ಹೆಜ್ಜೆ: ವಲಯದ ಸರಣಿ ಸಂಖ್ಯೆ ಹೆಚ್ಚಳ ಮತ್ತು ಪರಿಶೀಲನಾ ಆದೇಶಗಳನ್ನು ನಿಮ್ಮ ಬದಲಾವಣೆ ಪ್ರಕ್ರಿಯೆಗೆ ಸೇರಿಸಿ, ಇದರಿಂದ ಯಾವುದೇ ದಾಖಲೆ ಸಂಪಾದನೆ ಪರಿಶೀಲಿಸದೆ ಉತ್ಪಾದನೆಗೆ ತಲುಪದಂತೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು