StrongSwan Mac ತಲುಪಲಾಗದ DNS ವಿಳಾಸವನ್ನು ಕಳುಹಿಸುತ್ತದೆ

ಯಾರಾದರೂ MacBook ತೆರೆಯುವವರೆಗೆ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಟನಲ್ ಸ್ಥಾಪನೆಯಾಗುತ್ತದೆ, ಒಳಗಿನ ಹೋಸ್ಟ್‌ಗಳು ವಿಳಾಸದಿಂದ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ಹೆಸರಿನ ರೆಸಲ್ಯೂಶನ್ ಸಾಯುತ್ತದೆ. iPhone ನಲ್ಲಿ ಅದೇ ಪ್ರೊಫೈಲ್ ಅದೇ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ, ಆದರೆ Windows ಮತ್ತು Linux ಕ್ಲೈಂಟ್‌ಗಳು ಸರಿಯಾಗಿವೆ. ಸಾಮಾನ್ಯವಾಗಿ ಕಳುಹಿಸಿದ DNS ಗುಣಲಕ್ಷಣವೇ ಅಪರಾಧಿ: ಸರ್ವರ್ ತನ್ನ ಸಾರ್ವಜನಿಕ ಇಂಟರ್ಫೇಸ್ ವಿಳಾಸವನ್ನು ಹಂಚುತ್ತದೆ, ಮತ್ತು Apple ನ IKEv2 ಕ್ಲೈಂಟ್ ಟನಲ್ ಮೂಲಕ ಅಲ್ಲಿಗೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಕಳುಹಿಸುವುದಿಲ್ಲ. ರಿಸಾಲ್ವರ್ ಅನ್ನು ಪೂಲ್ ಒಳಗೆ ಸರಿಸಿ, ಕ್ಲೈಂಟ್ ಮುಟ್ಟದೆಯೇ ಲಕ್ಷಣ ಮಾಯವಾಗುತ್ತದೆ.

ಲಕ್ಷಣವು ಕಳುಹಿಸಿದ ವಿಳಾಸವನ್ನು ಸೂಚಿಸುತ್ತದೆ

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

ಸಾರ್ವಜನಿಕ ವಿಳಾಸವು ಸಾಮಾನ್ಯ ಆಯ್ಕೆ ಏಕೆಂದರೆ ಅದು ನಿರ್ವಾಹಕರು ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ಏಕೈಕ ವಿಳಾಸ. ಟನಲ್‌ನ ಸ್ವಂತ ಪ್ರಿಫಿಕ್ಸ್‌ನ ಹೊರಗಿರುವುದು ಖಾತರಿಯಾದ ಏಕೈಕ ವಿಳಾಸವೂ ಅದೇ, ಮತ್ತು ಆ ಗುಣವೇ Apple ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಮುರಿಯುತ್ತದೆ.

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಮೌಲ್ಯವನ್ನು ನೋಡಿ. ಕಳುಹಿಸಿದ ರಿಸಾಲ್ವರ್ ಸರ್ವರ್‌ನ WAN ವಿಳಾಸವಾಗಿದ್ದರೆ, ಸಮಸ್ಯೆಯ ರೂಪವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ ಮತ್ತು ಉಳಿದ ಊಹೆಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದು. ಅದನ್ನು ಪೂಲ್ ಪ್ರಿಫಿಕ್ಸ್‌ನೊಂದಿಗೂ ಹೋಲಿಸಿ, ಏಕೆಂದರೆ ಪೂಲ್ ಒಳಗೆ ಆದರೆ ಗುತ್ತಿಗೆ ಶ್ರೇಣಿಯ ಹೊರಗಿರುವ ವಿಳಾಸವು ಸರಿಪಡಿಸುವಿಕೆ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸರಿಯಾಗಿ ಹೊಂದುತ್ತದೆ. ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ ಎರಡು ನಿಮಿಷಗಳು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಇಡೀ ಮಧ್ಯಾಹ್ನ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವುದಕ್ಕಿಂತ ಉತ್ತಮ.

ಗುತ್ತಿಗೆ ಶ್ರೇಣಿಯಿಂದ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಕತ್ತರಿಸಿ

ಟನಲ್‌ಗೆ ರಿಸಾಲ್ವರ್ ಪೂಲ್‌ನ ಸ್ವಂತ ಸಬ್‌ನೆಟ್‌ನ ಸದಸ್ಯನಾಗಿರುವ ವಿಳಾಸ ಯೋಜನೆ ನೀಡಿ, ನಂತರ ಆ ವಿಳಾಸವನ್ನು ಕಾಯ್ದಿರಿಸಿ ಇದರಿಂದ ಯಾವುದೇ ಕ್ಲೈಂಟ್‌ಗೆ ಎಂದಿಗೂ ಗುತ್ತಿಗೆ ನೀಡಲಾಗದು. ಈ ಉದಾಹರಣೆಯಲ್ಲಿ ಪೂಲ್ 10.180.7.0/24, ಸರ್ವರ್ 10.180.7.1 ಅನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಗುತ್ತಿಗೆಗಳು 10.180.7.2 ರಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

ಪೂಲ್ ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ರಿಸಾಲ್ವರ್ ಒಂದೇ ಸಬ್‌ನೆಟ್ ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಈಗಾಗಲೇ ಟನಲ್ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುವ ಮಾರ್ಗವು ಪ್ರಶ್ನೆಗಳನ್ನೂ ಸಾಗಿಸುತ್ತದೆ. ಆ ಒಂದೇ ಗುಣವೇ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಕ್ಲೈಂಟ್‌ಗಳ ನಡುವೆ ಸಾಗಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. swanctl ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಅದೇ ಎರಡು ಸಂಗತಿಗಳು ipsec.conf ಸಿಂಟ್ಯಾಕ್ಸ್‌ನಲ್ಲಿ ಅಲ್ಲ, ಪೂಲ್ ವ್ಯಾಖ್ಯಾನ ಮತ್ತು ಸಂಪರ್ಕದ ಮೇಲಿನ DNS ಸೆಟ್ಟಿಂಗ್ ಆಗಿ ಕಾಣಿಸುತ್ತವೆ.

ಸರ್ವರ್‌ಗೆ ಇದಕ್ಕೆ ಹೊಸ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಅಗತ್ಯವಿಲ್ಲ. ಲೂಪ್‌ಬ್ಯಾಕ್ ಇಂಟರ್ಫೇಸ್‌ಗೆ 10.180.7.1 ಸೇರಿಸುವುದು ರಿಸಾಲ್ವರ್ ಬೈಂಡ್ ಆಗಿ ಉತ್ತರಿಸಲು ಸಾಕು, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್‌ಗಳು ಈಗಾಗಲೇ ಇರುವ ಪೂಲ್ ಮಾರ್ಗದ ಮೂಲಕ ಅಲ್ಲಿಗೆ ತಲುಪುತ್ತವೆ. ವಿಳಾಸವನ್ನು ಗುತ್ತಿಗೆ ಶ್ರೇಣಿಯ ಹೊರಗೆ ಇರಿಸಿ, ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಆಕಸ್ಮಿಕವಾಗಿ ಅದನ್ನು ಪಡೆಯದಂತೆ. ಪೂಲ್ ಅನ್ನು ಬಾಹ್ಯ DHCP ಅಥವಾ RADIUS ಸೇವೆ ನಿರ್ವಹಿಸಿದರೆ, ವಿಳಾಸವನ್ನು ಅಲ್ಲಿಯೂ ಕಾಯ್ದಿರಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಕೇಳುವ ಮೊದಲ ಕ್ಲೈಂಟ್ ಅದನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ರಿಸಾಲ್ವರ್ ಅನ್ನು ಬೈಂಡ್ ಮಾಡಿ ಮತ್ತು ಪೋರ್ಟ್ 53 ಮುಚ್ಚಿ

ವಿಳಾಸವನ್ನು ನಿಗದಿಪಡಿಸುವುದು ಅದರ ಮೇಲೆ ಕೇಳುವುದಕ್ಕೆ ಸಮವಲ್ಲ. LAN ವಿಳಾಸದಲ್ಲಿ ಮಾತ್ರ ಕೇಳುವ ರಿಸಾಲ್ವರ್ ಪೂಲ್ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸಿದ ಪ್ರಶ್ನೆಗಳನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ ಅಥವಾ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ರೂಟಿಂಗ್ ವೈಫಲ್ಯದಂತೆ ಕಾಣುವ ಟೈಮೌಟ್ ನೋಡುತ್ತದೆ.

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

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

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

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

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

ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಏನನ್ನು ಪಡೆದಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಮೊದಲು ಸರ್ವರ್‌ನ ದೃಷ್ಟಿಕೋನವನ್ನು, ನಂತರ ಕ್ಲೈಂಟ್‌ನದನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಎರಡೂ ಮಾಹಿತಿಪೂರ್ವಕವಾಗಿ ಭಿನ್ನವಾಗಿರುತ್ತವೆ. ಪೂಲ್ ಪಟ್ಟಿ ಯಾವ ವಿಳಾಸ ಗುತ್ತಿಗೆಗೆ ನೀಡಲಾಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಭದ್ರತಾ ಸಂಘಗಳ ಪಟ್ಟಿ ಸಂಪರ್ಕವು ನಿರೀಕ್ಷಿತ ಗುರುತಿನೊಂದಿಗೆ ಇದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ.

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

ನೇರ ಪ್ರಶ್ನೆ ರಿಸಾಲ್ವರ್ ಪೂಲ್ ವಿಳಾಸದಲ್ಲಿ ಅಲ್ಲಿಗೆ ತಲುಪಬಲ್ಲ ಹೋಸ್ಟ್‌ನಿಂದ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. Mac ಆ ಸರ್ವರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. macOS ನಲ್ಲಿ scutil --dns ಪ್ರತಿ ಸ್ಕೋಪ್ ಸೇವೆಗೆ ರಿಸಾಲ್ವರ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಾರಾಂಶ ಪ್ಯಾನೆಲ್‌ಗಿಂತ ಹೆಚ್ಚು ಮಾಹಿತಿಪೂರ್ವಕ; Windows ನಲ್ಲಿ Get-DnsClientServerAddress ಟನಲ್ ಅಡಾಪ್ಟರ್ ಕಳುಹಿಸಿದ ಮೌಲ್ಯವನ್ನು ಸ್ವೀಕರಿಸಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ.

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