ಗೇಟ್ವೇಯಲ್ಲಿ OpenVPN DNS: dnsmasq ಮತ್ತು ಫೈರ್ವಾಲ್ ವ್ಯಾಪ್ತಿ

ಸುರಂಗದ ವಿಳಾಸದಲ್ಲಿ dnsmasq ಚಲಾಯಿಸಿ, ಕ್ಲೈಂಟ್ ಪೂಲ್ನಿಂದ ಮಾತ್ರ DNS ಗೆ ಅನುಮತಿ ನೀಡಿ, ರಿಝಾಲ್ವರ್ ಪುಶ್ ಮಾಡಿ, ನಂತರ ನೇರ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ಹುಡುಕಾಟವನ್ನು ಪರೀಕ್ಷಿಸಿ.

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

ಆಲಿಸುವವನು ಎರಡು ದಿಕ್ಕಿನ ಸ್ಥಳೀಯ ಸೇವೆ

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

ಕ್ಲೈಂಟ್ ವರದಿ ಮಾಡುವ ಸಮಯ ಮೀರಿಕೆ ಮತ್ತು ಗೇಟ್ವೇಯಲ್ಲಿ ಕಾಣುವ ಸಮಯ ಮೀರಿಕೆ ಒಂದೇ ದೋಷವಲ್ಲ.

ಸುರಂಗದ ವಿಳಾಸವನ್ನು ಬಂಧಿಸಿ, ಪ್ರತಿ ವಿಳಾಸವನ್ನಲ್ಲ

ಈ ಕೆಲಸಕ್ಕೆ ಮೀಸಲಾದ dnsmasq ನಿದರ್ಶನಕ್ಕೆ ಸ್ಪಷ್ಟ ಆಲಿಸುವ ವಿಳಾಸ, ಪ್ರಾರಂಭದ ನಂತರ ಸುರಂಗ ಕಾಣಿಸಿಕೊಳ್ಳುವುದನ್ನು ಸಹಿಸುವ ಬೈಂಡ್ ಮೋಡ್, ಮತ್ತು ಒಂದು ಸ್ಪಷ್ಟ ಅಪ್ಸ್ಟ್ರೀಮ್ ಬೇಕು. ಇದು ನಾನು ಬಳಸುವ ಅತ್ಯಂತ ಚಿಕ್ಕ ಆವೃತ್ತಿ:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic ಪ್ರತ್ಯೇಕ ವಿಳಾಸಗಳನ್ನು ಬಂಧಿಸುತ್ತದೆ ಮತ್ತು tun0 ನಂತರ ಕಾಣಿಸಿಕೊಂಡಾಗ ನಿಭಾಯಿಸುತ್ತದೆ, ಇದು VPN ಸೇವೆ ಮರುಪ್ರಾರಂಭವಾಗುವ ಹೋಸ್ಟ್ನಲ್ಲಿ ಮುಖ್ಯ. loopback ಅನ್ನು ಪಟ್ಟಿ ಮಾಡುವುದು ಸಾರ್ವಜನಿಕ ಆಲಿಸುವವನನ್ನು ಸೇರಿಸದೆ ಸ್ಥಳೀಯ ಸಾಧನಗಳನ್ನು ಕೆಲಸ ಮಾಡುತ್ತಿರಿಸುತ್ತದೆ. no-resolv ಡೀಮನ್ ಹೋಸ್ಟ್ನ ರಿಝಾಲ್ವರ್ ಸಂರಚನೆಯಿಂದ ಅಪ್ಸ್ಟ್ರೀಮ್ಗಳನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಮತ್ತು no-hosts ಈ ನಿದರ್ಶನ ಗೇಟ್ವೇಯ hosts ಕಡತವನ್ನು ಪ್ರಕಟಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಈ ಆಯ್ಕೆಗಳಲ್ಲಿ ಯಾವುದೂ ಯಾರಿಗೂ ಸೇವೆಯನ್ನು ಪ್ರಶ್ನಿಸುವ ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ.

ಎರಡನೇ ಡೀಮನ್ ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಪೋರ್ಟ್ 53 ರಲ್ಲಿ ಈಗಾಗಲೇ ಇರುವ ಆಲಿಸುವವನು ಇದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ತಪ್ಪು ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಅಲೆದಾಡುವ ಕಡತದ ಬದಲು ವಿತರಣೆಯ ಸಂರಚನಾ ಮಾಲೀಕರನ್ನು ಬಳಸಿ.

DNS ಇನ್ಪುಟ್ಗೆ ಅನುಮತಿ ನೀಡಿ, ಸುರಂಗ ಸಂಚಾರಕ್ಕಲ್ಲ

ಇದನ್ನು ಕೆಲಸ ಮಾಡಿಸುವ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು ಸ್ಥಳೀಯ-ಇನ್ಪುಟ್ ನಿಯಮಗಳು, ಸುರಂಗ ಇಂಟರ್ಫೇಸ್, ಕ್ಲೈಂಟ್ ಪೂಲ್, ಗೇಟ್ವೇ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ 53 ಗೆ ಸೀಮಿತ. ಪ್ರತಿ ಪ್ರೋಟೋಕಾಲ್ಗೆ ಒಂದು, ಎರಡು ನಿಯಮಗಳು ಸಾಕು:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS UDP ಜೊತೆಗೆ TCP ಮೇಲೂ ಚಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ UDP ಮಾತ್ರದ ನಿಯಮ ದೊಡ್ಡ ಉತ್ತರಗಳನ್ನು ಮಧ್ಯೆ ಮಧ್ಯೆ ಎನಿಸುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗಲು ಬಿಡುತ್ತದೆ. ಇವು ufw route ಅನುಮತಿಗಳಲ್ಲ, ಮತ್ತು ಅವು tun0 ಮೇಲೆ ವಿಶಾಲ ಅನುಮತಿಯಾಗಬಾರದು. ಕ್ರಮವು ವಿಷಯದಷ್ಟೇ ಮುಖ್ಯ: tun0 ನಿಂದ ಎಲ್ಲಾ ಇನ್ಪುಟ್ ಬೀಳಿಸುವ ಹಿಂದಿನ ನಿಯಮ ಇನ್ನೂ ಗೆಲ್ಲುತ್ತದೆ, ಮತ್ತು ಅಂತಿಮ ಡ್ರಾಪ್ನ ಕೆಳಗೆ ಅನುಮತಿ ಸೇರಿಸುವುದು ಏನನ್ನೂ ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ.

ಗೇಟ್ವೇ DNS ಈಗ ವಿನ್ಯಾಸದ ಭಾಗವಾಗಿದ್ದರೆ, ಆ ಹಿಂದಿನ ನೀತಿಯನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಏಕೆ ಎಂದು ದಾಖಲಿಸಿ.

ಅಪ್ಸ್ಟ್ರೀಮ್ ಅರ್ಧ ಭಾಗ ಪ್ರತ್ಯೇಕ ಮಾರ್ಗ

ಪ್ರಶ್ನೆಗಳು ಗೇಟ್ವೇಯಿಂದ ಅದರ ಸ್ವಂತ ವಿಳಾಸದಿಂದ ಅಪ್ಸ್ಟ್ರೀಮ್ ರಿಝಾಲ್ವರ್ನತ್ತ ಹೊರಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಗೇಟ್ವೇಯ ರೂಟ್ ಮತ್ತು ಆ ರಿಝಾಲ್ವರ್ನತ್ತ ಔಟ್ಪುಟ್ ನೀತಿ ಈ ವಿನಿಮಯವನ್ನು ಅನುಮತಿಸಬೇಕು. ಇದು ಕ್ಲೈಂಟ್ಗಳನ್ನು ಆಲಿಸುವವನಿಗೆ ಬಿಡುವ ನಿಯಮಕ್ಕಿಂತ ಬೇರೆ ನಿಯಮ, ಮತ್ತು ಇದು ಬೇರೆ ಲಕ್ಷಣದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ.

ಉತ್ತರಗಳು ಕೆಲಸ ಮಾಡಲು ಮಿತಿಯಿಲ್ಲದ ಸುರಂಗ ಔಟ್ಪುಟ್ ಸೇರಿಸಬೇಡಿ; ಟ್ರ್ಯಾಕ್ ಮಾಡಿದ ಉತ್ತರಗಳಿಗೆ ಅದು ಬೇಕಿಲ್ಲ.

ಆಯ್ಕೆಯನ್ನು ಪುಶ್ ಮಾಡಿ, ನಂತರ ಹ್ಯಾಂಡ್ಆಫ್ ಪರಿಶೀಲಿಸಿ

ಸರ್ವರ್ ಪುಶ್ ಮಾಡಿದ ಆಯ್ಕೆಯಿಂದ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ರಿಝಾಲ್ವರ್ ಘೋಷಿಸಬಹುದು. ಅದು ಆಯ್ಕೆ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಪಾಲಿಸಲೇಬೇಕಾದ ಸೂಚನೆಯಲ್ಲ:

push "dhcp-option DNS 10.90.0.1"

ಕಮಾಂಡ್ ಲೈನ್ Linux ಕ್ಲೈಂಟ್ಗೆ ಅದರ ಸಂಪರ್ಕ ನಿರ್ವಾಹಕದ ರಿಝಾಲ್ವರ್ ಸಂಯೋಜನೆ ಬೇಕಾಗಬಹುದು, ಮತ್ತು ನಿರ್ವಹಿತ ಸಾಧನಕ್ಕೆ ನವೀಕರಿಸಿದ ನಿರ್ವಹಣಾ ಪ್ರೊಫೈಲ್ ಬೇಕಾಗಬಹುದು. ಸಂಪರ್ಕದ ನಂತರ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಸಕ್ರಿಯ ರಿಝಾಲ್ವರ್ ಅನ್ನು ದೃಢೀಕರಿಸಿ, ಪುಶ್ ಅನ್ವಯವಾಯಿತು ಎಂದು ಊಹಿಸುವ ಬದಲು. ಎರಡು ಕಾರ್ಯವಿಧಾನಗಳು ಒಟ್ಟಿಗೆ DNS ಹೊಂದಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಮಿನುಗುವ ರಿಝಾಲ್ಯೂಶನ್ ಎಂದು ಕಾಣುವ ಸ್ಪರ್ಧೆ ಉಂಟಾಗುತ್ತದೆ.

ಕ್ಲೈಂಟ್ನ ರಿಝಾಲ್ವರ್ ಸಂರಚನೆಗೆ ಒಬ್ಬ ಮಾಲೀಕರೇ ಗುರಿ, ಮತ್ತು ಪುಶ್ ಸಾಮಾನ್ಯವಾಗಿ ಆ ಮಾಲೀಕ ಆಗುವುದು ಕ್ಲೈಂಟ್ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಒಪ್ಪಿದಾಗ ಮಾತ್ರ.

ನೀವು ನಿಜವಾಗಿ ನಿರ್ಮಿಸಿದ್ದನ್ನು ಪರೀಕ್ಷಿಸಿ

ಒಂದು ಖಾಸಗಿ ಸಂಪೂರ್ಣ ಅರ್ಹ ಹೆಸರು ಮತ್ತು ಒಂದು ಅನುಮತಿಸಿದ ಬಾಹ್ಯ ಹೆಸರನ್ನು ನೇರವಾಗಿ ಸುರಂಗ ವಿಳಾಸದ ವಿರುದ್ಧ, UDP ಮತ್ತು TCP ಎರಡರಲ್ಲೂ ಪ್ರಶ್ನಿಸಿ. ನಂತರ ಅಪ್ಲಿಕೇಶನ್ನ ಸಾಮಾನ್ಯ ಹುಡುಕಾಟ ಮಾರ್ಗದ ಮೂಲಕ ಪುನರಾವರ್ತಿಸಿ.

ನೇರ ಪ್ರಶ್ನೆಗಳು ಕೆಲಸ ಮಾಡಿ ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ದೋಷ ಸರ್ವರ್ನಲ್ಲಲ್ಲ, ಹ್ಯಾಂಡ್ಆಫ್ನಲ್ಲಿದೆ:

  • ಕ್ಲೈಂಟ್ ಪುಶ್ ಮಾಡಿದ ಆಯ್ಕೆಯನ್ನು ಎಂದೂ ಅನ್ವಯಿಸಲಿಲ್ಲ.
  • ನಂತರ ಇನ್ನೊಂದು ರಿಝಾಲ್ವರ್ ಹೊಂದಿಸಲಾಯಿತು ಮತ್ತು ಸ್ಪರ್ಧೆಯಲ್ಲಿ ಗೆದ್ದಿತು.
  • ಅಪ್ಲಿಕೇಶನ್ ತನ್ನದೇ ರಿಝಾಲ್ವರ್ ಗ್ರಂಥಾಲಯ ಅಥವಾ ಸಂಗ್ರಹಿತ ಉತ್ತರವನ್ನು ಬಳಸುತ್ತದೆ.

ಅನುಮೋದಿತ VPN ಮಾರ್ಗದ ಹೊರಗಿನ ಮೂಲವು ಆಲಿಸುವವನನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸಲಾಗದು ಎಂದು ದೃಢೀಕರಿಸಿ ಮುಗಿಸಿ. ಯಶಸ್ವಿ ರಿಝಾಲ್ಯೂಶನ್ ಅದು ಹಿಂತಿರುಗಿಸಿದ ವಿಳಾಸಕ್ಕೆ ಅಧಿಕಾರ ನೀಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಈ ಎರಡು ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿರಿಸಿ.

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