ನಿಮ್ಮ VPN ರಿಸಾಲ್ವರ್ ಮೂಲಕವೇ DNS ಗೆ ಅವಕಾಶ ನೀಡಿ: ಹಂತ ಹಂತದ ಮಾರ್ಗದರ್ಶಿ
ಬ್ರೌಸರ್ನಿಂದ ಉತ್ತರದವರೆಗೆ ಒಂದು ಹೆಸರು ಹುಡುಕಾಟವನ್ನು ಅనುಸರಿಸಿ. ರಿಸಾಲ್ವರ್ ಎಲ್ಲಿ ಆಯ್ಕೆಯಾಗುತ್ತದೆ, ಫೈರವಾಲ್ ಎಲ್ಲಿ ಅದನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಪೋರ್ಟ್ 53 ನಿಯಮ ಎಂದೂ ಏನನ್ನು ಆವರಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ನೋಡಿ.
ನೀವು ಹೆಸರನ್ನು ಟೈಪ್ ಮಾಡಿದ ಕ್ಷಣದಿಂದ ಒಂದು ಹೆಸರು ಹುಡುಕಾಟವನ್ನು ಅನುಸರಿಸಿ. ಬ್ರೌಸರ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂಗೆ ಕೇಳುತ್ತದೆ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂ ತನ್ನ ನೀತಿ ಆಯ್ಕೆ ಮಾಡಿದ ರಿಸಾಲ್ವರ್ಗೆ ಕೇಳುತ್ತದೆ, ಮತ್ತು ಪ್ರಶ್ನೆ ಯಾವುದೋ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಯಾವುದೋ ಸಾಗಣೆಯೊಂದಿಗೆ ಸಾಧನದಿಂದ ಹೊರಡುತ್ತದೆ. ನಿಮ್ಮ VPN ವಿನ್ಯಾಸವು ಉತ್ತರವು ನಿರ್ದಿಷ್ಟ ರಿಸಾಲ್ವರ್ನಿಂದ ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗದ ಮೂಲಕ ಬರಬೇಕು ಎಂದು ಹೇಳುತ್ತದೆ. ಈ ಎರಡು ಹೇಳಿಕೆಗಳ ನಡುವಿನ ಅಂತರವೇ ನೀವು ಸಂರಚಿಸಿ ನಂತರ ಜಾರಿಗೊಳಿಸುವುದು.
ಹಂತ 1: ರಿಸಾಲ್ವರ್ ಮತ್ತು ಮಾರ್ಗಕ್ಕೆ ಹೆಸರಿಸಿ
ಫೈರವಾಲ್ ಮುಟ್ಟುವ ಮೊದಲು ಮೂರು ವಿಷಯಗಳನ್ನು ಬರೆಯಿರಿ: ರಿಸಾಲ್ವರ್ನ ವಿಳಾಸ, ನೀವು ನಿರೀಕ್ಷಿಸುವ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಪೋರ್ಟ್, ಮತ್ತು ಪ್ರಶ್ನೆ ಹೊರಡಬೇಕಾದ ಇಂಟರ್ಫೇಸ್. ಆ ಪಟ್ಟಿ ಇಲ್ಲದೆ ನಿಯಮವು ಸಂಚಾರದ ಬಗ್ಗೆ ಒಂದು ಊಹೆ, ನಿರ್ಧಾರದ ಜಾರಿಗಲ್ಲ. VPN ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾವನ್ನು ಸಾಗಿಸಬಹುದು ಆದರೆ DNS ಬೇರೆ ಏರ್ಪಾಡನ್ನು ಅನುಸರಿಸಬಹುದು, ಮತ್ತು ಅದು ತಾನಾಗಿಯೇ ತಪ್ಪಲ್ಲ. ಯಾರೂ ಕ್ಲೈಂಟ್ಗೆ ಬೇರೆ ಏನನ್ನೂ ಹೇಳದಿದ್ದಾಗ ಇದು ಸಂಭವಿಸುತ್ತದೆ.
ಮಾರ್ಗವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೆಸರಿಸುವುದು ವಿನ್ಯಾಸ ಮತ್ತು ಆಕಸ್ಮಿಕದ ನಡುವಿನ ವ್ಯತ್ಯಾಸ. ಇದು ನಂತರ ಪರೀಕ್ಷಿಸಲು ಸಹ ಏನನ್ನೋ ನೀಡುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ರತಿ ಅವಲೋಕನವನ್ನೂ ಲಿಖಿತ ನಿರೀಕ್ಷೆಯೊಂದಿಗೆ ಹೋಲಿಸಬಹುದು. ಆ ಪಟ್ಟಿಯನ್ನು ಬದಲಾವಣೆ ಟಿಕೆಟ್ನಲ್ಲಿ ಇರಿಸಿ, ಯಾರೋ ಒಬ್ಬರ ತಲೆಯಲ್ಲಿ ಅಲ್ಲ.
ಹಂತ 2: ನೀತಿ ನಿಜವಾಗಿ ಇರುವಲ್ಲೇ ಅದನ್ನು ಇರಿಸಿ
ರಿಸಾಲ್ವರ್ ಆಯ್ಕೆ ಕ್ಲೈಂಟ್ನದು: ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ನೆಟ್ವರ್ಕ್ ಸಂರಚನೆ, VPN ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಸೆಟ್ಟಿಂಗ್ಗಳು, ಅಥವಾ ನಿರ್ವಹಿತ ಬ್ರೌಸರ್ ನೀತಿ. ಮೊದಲು ಅಲ್ಲೇ ಇರಿಸಿ, ವೇದಿಕೆ ಬೆಂಬಲಿಸುವ ಕ್ರಮದಿಂದ, ಏಕೆಂದರೆ ಫೈರವಾಲ್ ಎಂದೂ ತಿಳಿಸದ ರಿಸಾಲ್ವರ್ ಆಯ್ಕೆ ಮಾಡಲು ಕ್ಲೈಂಟ್ಗೆ ಒತ್ತಾಯಿಸಲಾಗದು. ವಿಭಜಿತ ಸುರಂಗದ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಯಾವ ಡೊಮೇನ್ಗಳು ಒಳ ರಿಸಾಲ್ವರ್ಗೆ ಹೋಗುತ್ತವೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿ. ನಿರ್ವಹಿತ ತಂಡದಲ್ಲಿ DoH ಗೆ ಬ್ರೌಸರ್ ನೀತಿಯೇ ಹೆಚ್ಚಾಗಿ ಏಕೈಕ ಹತೋಟಿ, ಏಕೆಂದರೆ ಬ್ರೌಸರ್ ಸಿಸ್ಟಂ ಸೆಟ್ಟಿಂಗ್ನಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ತನ್ನದೇ ಎನ್ಕ್ರಿಪ್ಟ್ ರಿಸಾಲ್ವರ್ ಆಯ್ಕೆ ಮಾಡಬಹುದು.
ಇದನ್ನು ಬಿಟ್ಟು ನೇರವಾಗಿ ಫೈರವಾಲ್ಗೆ ಹೋದರೆ ಸರಿಯಾದ ರಿಸಾಲ್ವರ್ಗೆ ಅನುಮತಿ ನೀಡುವ ನಿಯಮ ಮತ್ತು ಅದನ್ನು ಎಂದೂ ಬಳಸದ ಕ್ಲೈಂಟ್ ಸಿಗುತ್ತದೆ. ನಿಯಮ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ರಿಸಾಲ್ವರ್ ದಾಖಲೆಗಳು ಖಾಲಿ ಉಳಿಯುತ್ತವೆ, ಇದು ದೋಷ ನಿವಾರಣೆಗೆ ಗೊಂದಲದ ಜೋಡಿ. ಮೊದಲು ಆಯ್ಕೆಯನ್ನು ಸಂರಚಿಸಿ, ನಂತರ ಜಾರಿಗೊಳಿಸಿ.
ಹಂತ 3: ಮಾರ್ಗವನ್ನು ಕಿರಿದಾಗಿ ಜಾರಿಗೊಳಿಸಿ
ಈಗ ಅನುಮತಿಸಿದ ಮಾರ್ಗಕ್ಕೆ ನೆಟ್ವರ್ಕ್ ಅನುಮತಿ ಸೇರಿಸಿ: ರಿಸಾಲ್ವರ್ನ ವಿಳಾಸ, ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಪೋರ್ಟ್, ಮತ್ತು ಅದು ಹೊರಡಬೇಕಾದ ಇಂಟರ್ಫೇಸ್. ಎಲ್ಲಾ ಹೊರಹೋಗುವ DNS ಗೆ ಅನುಮತಿ ನೀಡುವ ಬದಲು ನಿಯಮವನ್ನು ಆ ರಿಸಾಲ್ವರ್ಗೆ ಸೀಮಿತಗೊಳಿಸಿ. ಕೆಳಗಿನ ಮೂರು ಮಾರ್ಗಗಳು ಆಧುನಿಕ ಕ್ಲೈಂಟ್ ತೆಗೆದುಕೊಳ್ಳಬಹುದಾದವು, ಮತ್ತು ಪೋರ್ಟ್ 53 ನಿಯಮ ಆವರಿಸುವುದು ಮೊದಲನೆಯದನ್ನು ಮಾತ್ರ.
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
DoH ಮತ್ತು DoT ಅನ್ನು ತಡೆಯುವುದು ಕಾನೂನುಬದ್ಧ; ಪೋರ್ಟ್ 53 ನಿಯಮ ಅವುಗಳನ್ನು ಈಗಾಗಲೇ ತಡೆದಿದೆ ಎಂದು ಊಹಿಸುವುದು ಅಲ್ಲ. DoH ಬಳಸುವ ಬ್ರೌಸರ್ ನಿಮ್ಮ ನಿಯಮ ಎಂದೂ ವಿವರಿಸದ ಮಾರ್ಗದಲ್ಲಿ ಹೆಸರುಗಳನ್ನು ಬಗೆಹರಿಸುತ್ತದೆ, ಮತ್ತು ತನ್ನದೇ ರಿಸಾಲ್ವರ್ ತರುವ ಅಪ್ಲಿಕೇಶನ್ ಸಹ ಹಾಗೆಯೇ ಮಾಡುತ್ತದೆ. ನೀವು ಅನುಮತಿಸಲು ಉದ್ದೇಶಿಸಿರುವ ಪ್ರತಿ ಮಾರ್ಗ ಮತ್ತು ನಿರಾಕರಿಸಲು ಉದ್ದೇಶಿಸಿರುವ ಪ್ರತಿಯೊಂದನ್ನು ಬರೆಯಿರಿ. ಮಾರ್ಗವನ್ನು ಹೆಸರಿಸದ ನಿಯಮ ಅದರ ಬಗ್ಗೆ ನಿರ್ಧರಿಸಿಲ್ಲ.
ಹಂತ 4: ಖಾಸಗಿ ಮತ್ತು ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳನ್ನು ಅನುಸರಿಸಿ
ವಿಭಜಿತ DNS ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಖಾಸಗಿ ಹೆಸರು ಸ್ಥಳಗಳನ್ನು ಮಾತ್ರ ಒಳ ರಿಸಾಲ್ವರ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ ಆದರೆ ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳು ಬೇರೆಡೆಗೆ ಹೋಗುತ್ತವೆ, ಆದ್ದರಿಂದ ವಿನ್ಯಾಸದಲ್ಲಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ರಿಸಾಲ್ವರ್ ಇರುವುದು ಸೋರಿಕೆ ಅಲ್ಲ. ಸೋರಿಕೆ ಎಂದರೆ ನಿಮ್ಮ ರಿಸಾಲ್ವರ್ಗೆ ಹೋಗಬೇಕಿದ್ದ ಪ್ರಶ್ನೆ ಬೇರೆಡೆ ತಲುಪುವುದು, ಅಥವಾ ತಲುಪಲಾಗದ ಉದ್ದೇಶಿತ ಮಾರ್ಗ ಕ್ಲೈಂಟ್ ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ಹಿಂದಕ್ಕೆ ಬೀಳಿಸುವುದು. ಆ ಎರಡು ಸಂದರ್ಭಗಳೇ ಹುಡುಕಬೇಕಾದದ್ದು. ಉದ್ದೇಶಿತ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ ಒಂದು ಒಳ ಮತ್ತು ಒಂದು ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಅನುಸರಿಸಿ ಮತ್ತು ಯಾವ ರಿಸಾಲ್ವರ್ ಯಾವುದಕ್ಕೆ ಉತ್ತರಿಸಿತು ಎಂದು ಗಮನಿಸಿ.
ನಿಮ್ಮ ರಿಸಾಲ್ವರ್ ಬಗ್ಗೆ ವರದಿ ಮಾಡುವ ಪರೀಕ್ಷಾ ತಾಣವು ಸುಳಿವು, ಸಾಕ್ಷ್ಯವಲ್ಲ, ಏಕೆಂದರೆ ಅದು ತಲುಪಿದ ಪ್ರಶ್ನೆಗಳನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ. ಪ್ರಶ್ನೆ ನಿಜವಾಗಿ ಯಾವ ಮಾರ್ಗ ತೆಗೆದುಕೊಂಡಿತು ಎಂದು ತಿಳಿಯಬೇಕಾದಾಗ ಅದನ್ನು ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ, ನಂತರ ಎರಡೂ ಅವಲೋಕನಗಳನ್ನು ಹೋಲಿಸಿ. ಅವು ಹೊಂದಿಕೆಯಾಗದಿದ್ದಾಗ, ಯಾರೂ ದಾಖಲಿಸದ ಹಿನ್ನಡೆಯನ್ನು ನೀವು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ.
ರಿಸಾಲ್ವರ್ನ ವಿಳಾಸ ಸರಿಯಾಗಿದ್ದರೂ ತಲುಪಲಾಗದಿದ್ದರೆ, ಸಮಸ್ಯೆ ನೀತಿಯಲ್ಲಿ ಅಲ್ಲ, ಮಾರ್ಗನಿರ್ದೇಶನ ಅಥವಾ ಶೋಧನೆಯಲ್ಲಿ ಇದೆ. ಪ್ರಶ್ನೆಯನ್ನು ಆ ವಿಳಾಸದವರೆಗೆ ಪತ್ತೆ ಮಾಡಿ ಮತ್ತು ಯಾವುದೇ ರಿಸಾಲ್ವರ್ ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸುವ ಮೊದಲು ಉತ್ತರವು ನಿರೀಕ್ಷಿತ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಮರಳಿ ಬರುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
ಹಂತ 5: ಹಿಂತಿರುಗುವ ದಾರಿ ಬಿಡಿ
ಗೇಟ್ವೇಯಲ್ಲಿ DNS ಪ್ರವೇಶವನ್ನು ಕಠಿಣಗೊಳಿಸುವ ಮೊದಲು ಹೆಸರು ಬಗೆಹರಿಸುವಿಕೆಯನ್ನು ಅವಲಂಬಿಸದ ಮರುಪಡೆಯುವಿಕೆ ವಿಧಾನವನ್ನು ಖಚಿತಪಡಿಸಿ. ಮುರಿದ ರಿಸಾಲ್ವರ್ ಪ್ರತಿ ದುರಸ್ತಿ ಸಾಧನವನ್ನೂ ತಲುಪಲು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ, ಬದಲಾವಣೆಯನ್ನು ಹಿಂಪಡೆಯಲು ನೀವು ಬಳಸುವ ಸಾಧನಗಳೂ ಸೇರಿ. ಹೊಸ ನೀತಿ ಸಾಬೀತಾಗುವವರೆಗೆ ಸ್ಥಳೀಯ ಕನ್ಸೋಲ್ ಅಥವಾ ಹೊರ ಪಟ್ಟಿಯ ಮಾರ್ಗ ತೆರೆದಿಡಿ. ನೀತಿ ಮರುಸಂಪರ್ಕವನ್ನು ತಾಳಿಕೊಂಡ ನಂತರವೇ ಅದನ್ನು ತೆಗೆಯಿರಿ.
ಮರುಸಂಪರ್ಕ ಅಥವಾ ಬ್ರೌಸರ್ ನೀತಿ ನವೀಕರಣದ ನಂತರ ಪರಿಣಾಮಕಾರಿ ಸ್ಥಿತಿಯನ್ನು ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಎರಡೂ ನಿಮ್ಮ ನಿಯಮ ಬದಲಿಸದೆ ರಿಸಾಲ್ವರ್ ಬದಲಿಸಬಹುದು. ಅಗತ್ಯವೆಂದರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ತಿಳಿದ ಸ್ವೀಕರಿಸುವವರು ಮತ್ತು ಸಂರಕ್ಷಿತ ಮಾರ್ಗ, ಒಂದು ಸ್ಕ್ರೀನ್ಶಾಟ್ನಲ್ಲಿ ಸಮಾಧಾನಕರ ರಿಸಾಲ್ವರ್ ಲೇಬಲ್ ಅಲ್ಲ. RFC 8484 DNS over HTTPS ವಿಶೇಷಣ ನಿಮ್ಮ ಪೋರ್ಟ್ ನಿಯಮ ಕಾಣದ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾರ್ಗಕ್ಕೆ ಆಧಾರ.