ಸ್ಟೇಟ್‌ಲೆಸ್ VPN ಎಡ್ಜ್ ಫೈರ್‌ವಾಲ್‌ನಲ್ಲಿ DNS ಉತ್ತರ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ

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

ಎರಡು ವಿನಿಮಯಗಳು ಒಂದೇ ವಿನಿಮಯವಲ್ಲ

ಟ್ಯೂಪಲ್‌ಗಳನ್ನು ಬರೆಯಿರಿ, ತಪ್ಪು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ವಿನಂತಿಯ ಗಮ್ಯ ಪೋರ್ಟ್ ಉತ್ತರದ ಮೂಲ ಪೋರ್ಟ್ ಆಗುತ್ತದೆ, ಇದು ಪೋರ್ಟ್ 53 ಗೆ ಒಳಬರುವ ನಿಯಮ ಸೇರಿಸುವಾಗ ಹೆಚ್ಚಿನ ಜನರು ಊಹಿಸುವುದಕ್ಕೆ ನೇರ ವಿರುದ್ಧವಾಗಿದೆ:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

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

ಸ್ಟೇಟ್‌ಲೆಸ್ ಎಡ್ಜ್ ಮತ್ತು ಸ್ಟೇಟ್‌ಫುಲ್ ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್

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

ಹೋಲಿಕೆ ಮುಖ್ಯ ಏಕೆಂದರೆ ಎರಡು ಸಾಧನಗಳು ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ. ಉತ್ತರವನ್ನು ನಿರಾಕರಿಸುವ ಸ್ಟೇಟ್‌ಫುಲ್ ಫೈರ್‌ವಾಲ್ ಡ್ರಾಪ್ ದಾಖಲಿಸುತ್ತದೆ; ಸ್ಟೇಟ್‌ಲೆಸ್ ಎಡ್ಜ್ ಅದನ್ನು ಮೌನವಾಗಿ ನಿರಾಕರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ ಸುಮ್ಮನೆ ಕಾಲಮಿತಿ ತಲುಪುತ್ತದೆ.

ಅನುಮತಿಯನ್ನು ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯ ಸುತ್ತಲ್ಲ, ಪ್ರೋಟೋಕಾಲ್‌ನ ಸುತ್ತ ಕಟ್ಟಿ

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

ನಂತರ ಮಾರ್ಗದಲ್ಲಿ ಯಾವ ಉತ್ಪನ್ನವು ಸಂಚಾರವನ್ನು ನಿಜವಾಗಿ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ದಾಖಲಿತ IPv4 ಎಡ್ಜ್ ವ್ಯಾಪ್ತಿ IPv6 ನೀತಿಯನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಪೂರೈಕೆದಾರರ ಒಳಾಂಗಣ ಸಂಚಾರವು ಅದೇ ಫಿಲ್ಟರ್ ಮೂಲಕ ಎಂದೂ ಹಾದುಹೋಗದಿರಬಹುದು.

ಯಾವುದೇ ಮೂಲ ಪೋರ್ಟ್ 53 ಗೆ ಅನುಮತಿ ನೀಡುವುದು ಏಕೆ ಪರಿಹಾರವಲ್ಲ

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

ರೆಸಾಲ್ವರ್ ನೀವು ನಿಯಂತ್ರಿಸುವ ಸೇವೆಯಾಗಿದ್ದರೆ, ಅದರ ವಿಳಾಸಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸುವುದು ಸಾಕು. ಅದು ಸಾರ್ವಜನಿಕ ರೆಸಾಲ್ವರ್ ಆಗಿದ್ದರೆ, ನೀವು ಅನುಮೋದಿಸಿದ ವಿಳಾಸಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ ಮತ್ತು ಅವುಗಳನ್ನು ನಿಯಮದ ಕಾಮೆಂಟ್‌ನಲ್ಲಿ ಬರೆಯಿರಿ.

ಸರಿಯಾದ ಗಡಿಯಲ್ಲಿ, ಸರಿಯಾದ ದಿಕ್ಕಿನಲ್ಲಿ ಪರಿಶೀಲಿಸಿ

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

ಇದನ್ನು ಸರಿಪಡಿಸುವುದು ಹೋಸ್ಟ್‌ಗೆ ನಿಜವಾಗಿ ಬೇಕಾದ DNS ವಿನಿಮಯವನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ. ಇದು ಹೋಸ್ಟ್ ಅನ್ನು ಸಾರ್ವಜನಿಕ ರೆಸಾಲ್ವರ್ ಆಗಿ ಮಾಡುವುದಿಲ್ಲ, ಮುಂದಕ್ಕೆ ರವಾನಿಸಿದ VPN ಹರಿವುಗಳಿಗೆ ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು DNS ಯಾವುದೋ ಸಂಬಂಧವಿಲ್ಲದ ಸುರಂಗ ಸಮಸ್ಯೆಯ ಕಾರಣ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.