dnsmasq ಪೋರ್ಟ್ 53 ಅನ್ನು ಬೈಂಡ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ: ಅದನ್ನು ಹಿಡಿದಿರುವ ಸಾಕೆಟ್ ಅನ್ನು ಹುಡುಕಿ

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

ಈ ಕ್ರಮದಲ್ಲಿ ಐದು ಹಂತಗಳು: ದೋಷವನ್ನು ಮರುಸೃಷ್ಟಿಸಿ, ಶ್ರೋತೃಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ, wildcard ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ, ಕೆಲಸವನ್ನು ನಿಯೋಜಿಸಿ, ನಂತರ ಪರಿಶೀಲಿಸಿ.

ಹಂತ 1: ದೋಷವನ್ನು ಮರುಸೃಷ್ಟಿಸಿ ಓದಿ

ಸೇವೆ ಬಳಸುವ ಅದೇ ಸಂರಚನೆಯೊಂದಿಗೆ dnsmasq ಅನ್ನು ಮುಂಭಾಗದಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿ, ಇದರಿಂದ ದೋಷವು ಊಹಿಸಬೇಕಾದ ಲಾಗ್‌ನಲ್ಲಿ ಅಲ್ಲ, ನಿಮ್ಮ ಟರ್ಮಿನಲ್‌ನಲ್ಲಿ ಕಾಣುತ್ತದೆ. ಸಂದೇಶದಲ್ಲಿ ವಿಳಾಸ ಕುಟುಂಬ ಮತ್ತು ಸ್ಥಳೀಯ ವಿಳಾಸವನ್ನು ಗಮನಿಸಿ. ನಿರ್ದಿಷ್ಟ ವಿಳಾಸಕ್ಕೆ ಬೈಂಡ್ ಮತ್ತು wildcard ಗೆ ಬೈಂಡ್ ಬೇರೆ ಬೇರೆ ಮಾಲೀಕರಿರುವ ಬೇರೆ ಬೇರೆ ವೈಫಲ್ಯಗಳು.

ನಿಖರ ಪಠ್ಯವನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ. ವಿಳಾಸ ಬಳಕೆಯಲ್ಲಿದೆ, ಅನುಮತಿ ವೈಫಲ್ಯ ಮತ್ತು ಕಾಣೆಯಾದ ಇಂಟರ್ಫೇಸ್ ಎಲ್ಲವೂ ಪ್ರಾರಂಭ ವೈಫಲ್ಯವಾಗಿ ಬರುತ್ತವೆ, ಮತ್ತು ಅವು ಮೂರು ಬೇರೆ ಬೇರೆ ದುರಸ್ತಿಗಳನ್ನು ಸೂಚಿಸುತ್ತವೆ.

ಹಂತ 2: ಮಾಲೀಕರನ್ನು ಪಟ್ಟಿ ಮಾಡಿ

ಮೊದಲು ಸಾಕೆಟ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ. ಮೂಲ ಪೋರ್ಟ್ 53 ಮೇಲಿನ ಫಿಲ್ಟರ್ ನೋಡುವ ಅಧಿಕಾರವಿದ್ದಾಗ ಎರಡೂ ಸಾಗಣೆಗಳನ್ನು ಮತ್ತು ಒಡೆತನದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ತೋರಿಸುತ್ತದೆ:

ss -lntup 'sport = :53'

ಔಟ್‌ಪುಟ್ ಅನ್ನು ಕಾಲಮ್‌ಗಳಲ್ಲಿ ಓದಿ: ಸಾಗಣೆ, ಸ್ಥಳೀಯ ವಿಳಾಸ, ಪೋರ್ಟ್, ಪ್ರಕ್ರಿಯೆ. TCP ಶ್ರೋತೃ ಮತ್ತು UDP ಶ್ರೋತೃ ಪ್ರತ್ಯೇಕ ಸಾಕೆಟ್‌ಗಳು, ಆದ್ದರಿಂದ ಒಂದನ್ನು ನಿಲ್ಲಿಸಿದರೆ ಇನ್ನೊಂದು ಬಿಡುಗಡೆಯಾಗುವುದಿಲ್ಲ. wildcard ವಿಳಾಸವು ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಆವರಿಸುತ್ತದೆ, ಅಂದರೆ ಯಾವುದೇ ಸಾಲು ಹೆಸರಿನಿಂದ ಉಲ್ಲೇಖಿಸದಿದ್ದರೂ VPN ವಿಳಾಸ ಈಗಾಗಲೇ ಆಕ್ರಮಿಸಲ್ಪಟ್ಟಿದೆ. ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯ ಹೆಸರು ಇದು ವಿತರಣೆ-ನಿರ್ವಹಿತ ರಿಸಾಲ್ವರ್, ಕಂಟೇನರ್, ಅಥವಾ ಹಿಂದಿನ ಪ್ರಯೋಗ ಚಾಲನೆಯಲ್ಲಿ ಬಿಟ್ಟದ್ದು ಎಂದು ತಿಳಿಸುತ್ತದೆ.

ಹಂತ 3: wildcard ಬಲೆ

bind-interfaces ಆಯ್ಕೆಯು dnsmasq wildcard ಸಾಕೆಟ್ ಅನ್ನು ಬೈಂಡ್ ಮಾಡುತ್ತದೆಯೇ ಅಥವಾ ಪ್ರತಿ ಸಂರಚಿತ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಒಂದು ಸಾಕೆಟ್ ಅನ್ನು ಬೈಂಡ್ ಮಾಡುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, dnsmasq ಉಲ್ಲೇಖ ವಿವರಿಸುವಂತೆ. ಅದಿಲ್ಲದೆ dnsmasq wildcard ಅನ್ನು ಬೈಂಡ್ ಮಾಡಿ ಬದಲಿಗೆ ವಿನಂತಿಗಳನ್ನು ಇಂಟರ್ಫೇಸ್ ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಬಹುದು, ಇದು ಇನ್ನೊಂದು ಡೀಮನ್ wildcard ಹಿಡಿದಾಗ ತಕ್ಷಣ ವಿಫಲವಾಗುತ್ತದೆ. Linux bind-dynamic ಸೇರಿಸುತ್ತದೆ, ಅದು ಪ್ರಾರಂಭದ ನಂತರ ರಚಿಸಿದ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, VPN ಇಂಟರ್ಫೇಸ್ ಸಂಪರ್ಕದಲ್ಲಷ್ಟೇ ಕಾಣಿಸಿಕೊಂಡಾಗ ಇದು ನಿಜವಾದ ಕಾಳಜಿ.

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

ಹಂತ 4: ಕೆಲಸವನ್ನು ನಿಯೋಜಿಸಿ

ಯಾವ ಡೀಮನ್ VPN ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಮತ್ತು ಯಾವುದು ಹೋಸ್ಟ್‌ಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ. ಸುರಂಗದ ವಿಳಾಸದಲ್ಲಿ ಕೇಳಿ ಮೇಲಕ್ಕೆ ಮುಂದಕ್ಕೆ ರವಾನಿಸುವ ಒಂದು ರಿಸಾಲ್ವರ್ ಸಾಮಾನ್ಯ ವ್ಯವಸ್ಥೆ; ಪ್ರತಿಯೊಂದೂ ತಾನೇ ಪೋರ್ಟ್ 53 ಅನ್ನು ಹೊಂದಿದೆ ಎಂದು ಭಾವಿಸುವ ಎರಡು ರಿಸಾಲ್ವರ್‌ಗಳು ವ್ಯವಸ್ಥೆಯೇ ಅಲ್ಲ.

ನಂತರ ಆ ನಿರ್ಧಾರವನ್ನು ಪ್ರತಿ ಸೇವೆಯ ಸ್ವಂತ ಸಂರಚನೆಯಲ್ಲಿ ವ್ಯಕ್ತಪಡಿಸಿ: ಆಲಿಸುವ ವಿಳಾಸಗಳು, ಇಂಟರ್ಫೇಸ್ ಫಿಲ್ಟರ್‌ಗಳು ಮತ್ತು ರವಾನೆ. ಸೇವೆಯ ಮಾಲೀಕರ ಮೂಲಕ ಅವುಗಳನ್ನು ಬದಲಾಯಿಸಿ, ಅದು ವಿತರಣಾ ಘಟಕ, ನೆಟ್‌ವರ್ಕ್ ನಿರ್ವಾಹಕ ಅಥವಾ ಕಂಟೇನರ್ ರನ್‌ಟೈಮ್ ಆಗಿರಲಿ, ಬದಲಾವಣೆ ಮರುಪ್ರಾರಂಭವನ್ನೂ ದಾಟಿ ಉಳಿಯಲಿ.

ಹಂತ 5: ಸಾಕೆಟ್ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಮಾರ್ಗ

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

ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡಬೇಕಾದ ಮೂರು ಫಲಿತಾಂಶಗಳು: ಸಾಕೆಟ್ ಇದೆ, ಕ್ಲೈಂಟ್ ಅದನ್ನು ತಲುಪುತ್ತದೆ, ಉತ್ತರ ಸರಿಯಾಗಿದೆ.

ಏನು ಮಾಡಬಾರದು

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

ಯಂತ್ರವನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ಮಾಲೀಕತ್ವದ ನಿರ್ಧಾರವನ್ನು ಮುಂದಿನ ನಿರ್ವಾಹಕರು ಕಂಡುಕೊಳ್ಳುವ ಸ್ಥಳದಲ್ಲಿ ದಾಖಲಿಸಿ. ಇಮೇಜ್ ಮತ್ತೆ ನಿರ್ಮಾಣವಾದಾಗಲೆಲ್ಲಾ ಪೋರ್ಟ್ ಘರ್ಷಣೆಗಳು ಮರಳುತ್ತವೆ.