OpenWrt ನೀತಿ ರೂಟಿಂಗ್: ಸ್ಥಳೀಯ DNS ಹಿಡಿಯುವ ಸರಪಳಿ

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

ಎರಡು ಫ್ಲೋ, ಒಂದು ರಿಜಾಲ್ವರ್ ವಿಳಾಸ

ಮೊದಲ ಫ್ಲೋ ಜನರು ಊಹಿಸುವಂತಹದ್ದು. ಕ್ಲೈಂಟ್ ರೌಟರ್ನ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಕೇಳುತ್ತದೆ, ರಿಜಾಲ್ವರ್ ಮೇಲಕ್ಕೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಆ ಫಾರ್ವರ್ಡ್ ಆದ ಪ್ಯಾಕೆಟ್ ಹೊರಹೋಗುವಾಗ ರೌಟರ್ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ. ಆ ಪ್ಯಾಕೆಟ್ ಫಾರ್ವರ್ಡ್ ಆದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ವೀಕ್ಷಿಸುವ ಯಾವುದಕ್ಕೂ ಗೋಚರಿಸುತ್ತದೆ.

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

ಎರಡೂ ಒಂದೇ ರಿಜಾಲ್ವರ್ ವಿಳಾಸವನ್ನು ಗುರಿಯಾಗಿಸಬಹುದು, ಮತ್ತು ಅದಕ್ಕೇ ವ್ಯತ್ಯಾಸವನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುವುದು ಸುಲಭ. ಅದೇ ಗಮ್ಯಸ್ಥಾನ, ಬೇರೆ ಮೂಲ, ಬೇರೆ ಸರಪಳಿ. ಮೂಲವನ್ನು ನೋಡಿದ ತಕ್ಷಣ ಉಳಿದ ರೋಗನಿರ್ಣಯ ಅನುಸರಿಸುತ್ತದೆ.

ಫಾರ್ವರ್ಡ್ ಆದ ಮತ್ತು ಸ್ಥಳೀಯವಾಗಿ ರಚಿಸಿದ ಪ್ಯಾಕೆಟ್ಗಳು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಪ್ರವೇಶಿಸುತ್ತವೆ

ಫಾರ್ವರ್ಡ್ ಆದ ಟ್ರಾಫಿಕ್ ಇನ್ನೊಂದು ಇಂಟರ್ಫೇಸ್ನಿಂದ ಬಂದಾಗ ಮೌಲ್ಯಮಾಪನವಾಗುತ್ತದೆ. ನೀತಿ ರೂಟಿಂಗ್ ಪ್ಯಾಕೇಜ್ಗಳು ಅದನ್ನು prerouting ಸರಪಳಿಯಾಗಿ ತೋರಿಸುತ್ತವೆ, ಮತ್ತು ಅಲ್ಲಿ ಇರಿಸಿದ ನಿಯಮ ರೌಟರ್ ದಾಟುವ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ನೋಡುತ್ತದೆ. ಅದಕ್ಕೇ ಕ್ಲೈಂಟ್ ಲುಕಪ್ಗಳು ನೀತಿ ವಿವರಿಸಿದಂತೆಯೇ ವರ್ತಿಸುತ್ತವೆ, ಮತ್ತು ಅದಕ್ಕೇ ರೌಟರ್ ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ನಿಯಮ ತಪ್ಪಲ್ಲ, ಅದು ರೌಟರ್ ಎಂದಿಗೂ ತಲುಪದ ಹುಕ್ಗೆ ಜೋಡಿಸಲಾಗಿದೆ ಅಷ್ಟೇ. ಅದನ್ನು ಸರಿಸಿ, ಅದೇ ಹೊಂದಾಣಿಕೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

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

ಇದು ಪ್ಯಾಕೆಟ್ಗಳು ಎಲ್ಲಿ ಹುಟ್ಟುತ್ತವೆ ಎಂಬ ಗುಣ, ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ಪ್ಯಾಕೇಜ್ನದಲ್ಲ. ಒಂದು ಸರಪಳಿಗೆ ಬರೆದ ನಿಯಮಕ್ಕೆ ಇನ್ನೊಂದರ ಬಗ್ಗೆ ಸರಳವಾಗಿ ಅಭಿಪ್ರಾಯವಿಲ್ಲ. ಯಾವುದೇ ನಿಯಮ ಟ್ಯೂನಿಂಗ್ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

ಔಟ್ಪುಟ್ ಸರಪಳಿ ಆಯ್ಕೆಮಾಡಿ, ನಂತರ ಹೊಂದಾಣಿಕೆ ಸಂಕುಚಿಸಿ

ಪರಿಹಾರ ಎಂದರೆ ಅದೇ ಉದ್ದೇಶವನ್ನು ಔಟ್ಪುಟ್ ಸರಪಳಿಗೂ ಜೋಡಿಸುವುದು, ಅಥವಾ ರೌಟರ್ನ ಸ್ವಂತ ಕ್ವೆರಿಗಳೇ ನಿಮಗೆ ಮುಖ್ಯವಾದರೆ ನಿಯಮವನ್ನು ಅಲ್ಲಿಗೆ ಸರಿಸುವುದು. ನೀತಿ ರೂಟಿಂಗ್ ಪ್ಯಾಕೇಜ್ ಮೇಲೆ ನಿರ್ಮಿಸಿದ OpenWrt ಸೆಟಪ್ನಲ್ಲಿ ಇದರರ್ಥ ನಿಯಮದ ಸರಪಳಿ ಸೆಟ್ಟಿಂಗ್ನಲ್ಲಿ prerouting ಬದಲಿಗೆ output ಆಯ್ಕೆಮಾಡುವುದು. ಎರಡೂ ಜನಸಂಖ್ಯೆಗಳಿಗೆ ಕವರೇಜ್ ಬೇಕಾದರೆ ಎರಡೂ ನಿಯಮಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ.

ನಂತರ ನಿಯಮ ಯಾವುದಕ್ಕೆ ಹೊಂದುತ್ತದೆ ಎಂಬುದನ್ನು ಸಂಕುಚಿಸಿ. ರಿಜಾಲ್ವರ್ ನಿಜವಾಗಿ ಬಳಸುವ ಪೋರ್ಟ್ನಲ್ಲಿ ಗಮ್ಯಸ್ಥಾನ ರಿಜಾಲ್ವರ್ ವಿಳಾಸಗಳು, ರೌಟರ್ ರಚಿಸುವ ಎಲ್ಲವನ್ನೂ ಟನೆಲ್ಗೆ ಕಳುಹಿಸುವುದಕ್ಕಿಂತ ಬಹಳ ಚಿಕ್ಕ ನಿರ್ಧಾರ.

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

ಟನೆಲ್ನ ಸ್ವಂತ ಸಾಗಣೆಯನ್ನು ನಿಯಮದ ಹೊರಗಿಡಿ

ಟನೆಲ್ನ ಹೊರ ಸಂಪರ್ಕವನ್ನೂ ರೌಟರ್ ರಚಿಸುತ್ತದೆ. ಸ್ಥಳೀಯವಾಗಿ ರಚಿಸಿದ ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಟನೆಲ್ಗೆ ಕಳುಹಿಸುವ ನಿಯಮ ಟನೆಲ್ ಅನ್ನು ತನ್ನ ಮೂಲಕವೇ ರೂಟ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಏಳುವುದಿಲ್ಲ.

ನಿರ್ವಹಣಾ ಪ್ರವೇಶ ಎರಡನೇ ಬಲಿ. ರೌಟರ್ನಿಂದ ಹುಟ್ಟಿದ ಆಡಳಿತಾತ್ಮಕ ಅಧಿವೇಶನಗಳು, ಅಥವಾ ಅವುಗಳಿಗೆ ಪ್ರತ್ಯುತ್ತರಗಳು, ತುಂಬಾ ಅಗಲವಾದ ಸ್ಥಳೀಯ ನಿಯಮದಿಂದ ಟನೆಲ್ಗೆ ಎಳೆಯಲ್ಪಟ್ಟು LAN ನಿಂದ ತಲುಪಲಾಗದಂತಾಗಬಹುದು.

ಟನೆಲ್ನ ಅಂತ್ಯ ಬಿಂದುವನ್ನು ಹೊಂದಾಣಿಕೆಯಿಂದ ಹೊರಗಿಡಿ, ಮತ್ತು ನಿಯಮವನ್ನು ರಿಜಾಲ್ವರ್ ವಿಳಾಸಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ. ಅದು DNS ಅಗತ್ಯಕ್ಕೆ ಸಾಕು ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಸಾಕಷ್ಟು ಚಿಕ್ಕದು.

ಎರಡೂ ಜನಸಂಖ್ಯೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ, ಒಂದನ್ನಲ್ಲ

ರೌಟರ್ ತನ್ನದೇ ಕ್ವೆರಿ ಮಾಡುವುದನ್ನು ಗಮನಿಸಿ ಮತ್ತು ಯಾವ ಇಂಟರ್ಫೇಸ್ ಅದನ್ನು ಒಯ್ದಿತು ಎಂದು ಗಮನಿಸಿ. LAN ಹೋಸ್ಟ್ನಿಂದ ಲುಕಪ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸಿ ಮತ್ತು ಅದು ತೆಗೆದುಕೊಂಡ ಮಾರ್ಗವನ್ನು ಗಮನಿಸಿ. ನೀತಿ ನಿಯಮಗಳ ಮೇಲಿನ ಕೌಂಟರ್ಗಳು ಊಹಿಸದೆಯೇ ಎರಡೂ ಉತ್ತರಗಳನ್ನು ಗೋಚರವಾಗಿಸುತ್ತವೆ.

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

ಪೋರ್ಟ್ ಅನ್ನೂ ಪರಿಶೀಲಿಸಿ: ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್ 53 ಗೆ ಹೊಂದುವ ನಿಯಮ 853 ನಲ್ಲಿ DNS over TLS ಅಥವಾ HTTPS ಅಂತ್ಯ ಬಿಂದುವಿನ ಮೂಲಕ ತಲುಪುವ ರಿಜಾಲ್ವರ್ ಅನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ upstream ನಿಜವಾಗಿ ಬಳಸುವ ಸಾಗಣೆಗೆ ಹೊಂದಿಸಿ, ಮತ್ತು ಸೋರಿಕೆ ಸರಿಯಾದ ಕಾರಣಕ್ಕೆ ಮುಚ್ಚುತ್ತದೆ.