Chromecast ಮತ್ತು DLNA ಶೋಧನೆ ಎಂದಿಗೂ ರೂಟ್ ಮಾಡಿದ VPN ದಾಟುವುದಿಲ್ಲ

ಕಾಸ್ಟ್ ಬಟನ್ ಏನನ್ನೂ ಪಟ್ಟಿ ಮಾಡುವುದಿಲ್ಲ, VLC DLNA ಖಾಲಿಯಾಗಿ ಉಳಿಯುತ್ತದೆ, ಮತ್ತು ಇನ್ನೊಂದು ತುದಿಯಲ್ಲಿರುವ ಯಂತ್ರ ದೂರಿಲ್ಲದೆ ping ಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಈ ಸಂಯೋಜನೆ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಸಮಸ್ಯೆಯಲ್ಲ, ಫೈರ್‌ವಾಲ್ ಒಗಟೂ ಅಲ್ಲ. ಈ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ ಶೋಧನೆ ಎಂದರೆ ಸ್ಥಳೀಯ ಸೆಗ್‌ಮೆಂಟ್‌ನಲ್ಲಿ ಗುಂಪು ವಿನಿಮಯ, ಮತ್ತು ರೂಟ್ ಮಾಡಿದ ಸುರಂಗ ಗುಂಪು-ವಿಳಾಸದ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುವುದಿಲ್ಲ. ನೀವು ಆರಂಭಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಅವಧಿ ಎಂದಿಗೂ ನೀಡಲ್ಪಡುವುದಿಲ್ಲ.

ತಲುಪುವಿಕೆ ಸರಿಯಾಗಿದೆ. ಶೋಧನೆ ಕಾಣೆಯಾಗಿದೆ.

ಪುರಾಣ: ಸುರಂಗಕ್ಕೆ ಒಂದು ಸೆಟ್ಟಿಂಗ್ ಅಥವಾ ಹೆಚ್ಚು ಸಾಮರ್ಥ್ಯ ಬೇಕು

ಸಾಮಾನ್ಯ ಸಲಹೆಗಳೆಂದರೆ ಪೀರ್-ಟು-ಪೀರ್ ಸಂಚಾರ ಸಕ್ರಿಯಗೊಳಿಸುವುದು, MTU ಹೆಚ್ಚಿಸುವುದು, ಅಥವಾ ಸುರಂಗ ಸಾಧನದ ಪ್ರಕಾರ ಬದಲಾಯಿಸುವುದು. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಪ್ರಸಾರ ಕ್ಷೇತ್ರ ಸೇರಿಸುವುದಿಲ್ಲ. ಮಲ್ಟಿಕಾಸ್ಟ್ ಅನ್ನು ಸ್ವಿಚ್‌ಗಳು ಮತ್ತು ಸ್ಥಳೀಯ ಜಾಲ ಸ್ಟ್ಯಾಕ್ ತಲುಪಿಸುತ್ತವೆ, ಮತ್ತು ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ TUN ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ತುಂಬಿಸಲು ಗುಂಪು ವಿಳಾಸವಿಲ್ಲ.

ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುವುದು ವೈಫಲ್ಯವನ್ನು ಇನ್ನಷ್ಟು ಗಟ್ಟಿಯಾಗಿಸಬಹುದು. ಪ್ರೋಟೋಕಾಲ್ ಎಂದಿಗೂ ಕಳುಹಿಸದ ಪ್ರಕಟಣೆಯನ್ನು ಅದು ಕಾಣಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಶೋಧನಾ ವಿನಿಮಯ ವಾಸ್ತವವಾಗಿ ಏನು

ನೀವು ಎದುರಿಸುವ ಬಹುತೇಕ ಎಲ್ಲವನ್ನೂ ಮೂರು ಮಾದರಿಗಳು ಒಳಗೊಳ್ಳುತ್ತವೆ. mDNS 224.0.0.251 ಗೆ UDP 5353 ಮೂಲಕ ಕಳುಹಿಸುತ್ತದೆ, SSDP 239.255.255.250 ಗೆ UDP 1900 ಮೂಲಕ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಹಳೆಯ SMB ಬ್ರೌಸ್ ಪಟ್ಟಿಗಳು ಉಪಜಾಲದ ಪ್ರಸಾರ ವಿಳಾಸಕ್ಕೆ ಹೋಗುತ್ತಿದ್ದವು. ಪ್ರತಿಯೊಂದೂ ಹೋಸ್ಟ್‌ಗಲ್ಲದೆ ಗುಂಪಿಗೆ ಉದ್ದೇಶಿಸಲಾಗಿದೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಅದೇ ಸೆಗ್‌ಮೆಂಟ್‌ನಲ್ಲಿ ಶ್ರೋತೃವನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ. ರೂಟ್ ಮಾಡಿದ ಸುರಂಗದ ಆಚೆಗಿನ ಗ್ರಾಹಕ ಆ ಸೆಗ್‌ಮೆಂಟ್‌ನಲ್ಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಏನೂ ತಲುಪುವುದಿಲ್ಲ.

ರಿಲೇ ಆದ ಪ್ರಕಟಣೆಯೂ ಪೇಲೋಡ್ ಸಾಗಿಸುತ್ತದೆ: ಸಾಮಾನ್ಯವಾಗಿ ಕಳುಹಿಸುವವರ LAN ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್, ಅಲ್ಲಿಗೆ ದೂರದ ವೀಕ್ಷಕರು ತಲುಪಬೇಕಾಗುತ್ತದೆ.

ಸುರಂಗ ಬದಲಾಯಿಸುವ ಮೊದಲು ಕ್ಯಾಪ್ಚರ್ ಓದಿ

ಅಪ್ಲಿಕೇಶನ್ ಸ್ಕ್ಯಾನ್ ಮಾಡುವಾಗ ಸುರಂಗ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಕ್ಯಾಪ್ಚರ್ ಮಾಡಿ. ಖಾಲಿ ಕ್ಯಾಪ್ಚರ್ ಎಂದರೆ ಪ್ರಕಟಣೆ ಎಂದಿಗೂ ಗಡಿ ದಾಟಿಲ್ಲ, ಮತ್ತು ಸುರಂಗದ ಯಾವುದೇ ಟ್ಯೂನಿಂಗ್ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ಏನನ್ನೂ ತೋರಿಸದಿರುವಾಗ ಕಾಣುವ ಪ್ಯಾಕೆಟ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಕಟಿತ ವಿಳಾಸ ವೀಕ್ಷಕರಿಗೆ ತಲುಪಲಾಗದು ಎಂದರ್ಥ — ಇದು ಶೋಧನೆಯ ವೇಷದಲ್ಲಿ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆ.

ಎರಡು ನಿಮಿಷಗಳ ಕ್ಯಾಪ್ಚರ್ ಪೋರ್ಟ್‌ಗಳ ಬಗ್ಗೆ ಒಂದು ಗಂಟೆಯ ಊಹೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ: tcpdump -ni tun0 udp port 5353 or udp port 1900.

ಮೂರು ಪರಿಹಾರಗಳು, ಅಗ್ಗದ್ದು ಮೊದಲು

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

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

ರೂಟಿಂಗ್ ಬದಲು ಬ್ರಿಡ್ಜ್ ಮಾಡಿ. ಸರ್ವರ್ tap ಸಾಧನವನ್ನು LAN ಗೆ ಬ್ರಿಡ್ಜ್ ಮಾಡುವ TAP ಸೆಗ್‌ಮೆಂಟ್ ಎರಡೂ ತುದಿಗಳನ್ನು ಒಂದೇ ಪ್ರಸಾರ ಕ್ಷೇತ್ರದಲ್ಲಿ ಇಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರಕಟಣೆಗಳು ಬದಲಾಗದೆ ದಾಟುತ್ತವೆ. ಇದು ಅತ್ಯಂತ ದುಬಾರಿ ಆಯ್ಕೆಯೂ ಆಗಿದೆ, ಏಕೆಂದರೆ ಒಂದು ಉಪಜಾಲ ಎಂದರೆ ಒಂದು ವೈಫಲ್ಯ ಕ್ಷೇತ್ರ ಮತ್ತು LAN ನ ಪ್ರತಿಯೊಂದು ಮಲ್ಟಿಕಾಸ್ಟ್ ಸೇವೆ ಈಗ ಪ್ರತಿಯೊಂದು ಪೀರ್ ತಲುಪುತ್ತದೆ.

ಸಹಾಯ ಮಾಡದಿರುವುದು, ಎಷ್ಟೇ ಸಲಹೆ ನೀಡಿದರೂ

ಬ್ರಿಡ್ಜ್ ಇಲ್ಲದೆ dev tun ಅನ್ನು dev tap ಗೆ ಬದಲಾಯಿಸಿದರೂ ರೂಟ್ ಆದ TAP ಸಾಧನ ಉಳಿಯುತ್ತದೆ, ಆದ್ದರಿಂದ ವರ್ತನೆ ಬದಲಾಗುವುದಿಲ್ಲ. client-to-client ಪೀರ್-ಟು-ಪೀರ್ ಯುನಿಕಾಸ್ಟ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರಸಾರವನ್ನು ತುಂಬಿಸುವುದಿಲ್ಲ. ಶೋಧನಾ ಪೋರ್ಟ್ ಅನ್ನು ಒಂದು ಹೋಸ್ಟ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದರಿಂದ ಗುಂಪು-ವಿಳಾಸದ ಸಂಚಾರ ತಲುಪುವುದಿಲ್ಲ. ಒಂದು ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ಮೀಡಿಯಾ ಸರ್ವರ್ ತನ್ನ ಸ್ವಂತ ಸಂರಚನೆ VPN ಇಂಟರ್‌ಫೇಸ್ ಪಟ್ಟಿ ಮಾಡುವವರೆಗೆ ಆ ವಿಳಾಸದಲ್ಲಿ ಉತ್ತರಿಸುತ್ತಲೇ ಇರುತ್ತದೆ.

ಒಂದು ನೇರ ಯುನಿಕಾಸ್ಟ್ ವಿನಂತಿ, ನಂತರ ಒಂದು ಪ್ರಕಟಿತ ವಿನಂತಿ ಪರೀಕ್ಷಿಸಿ. ಮೊದಲನೆಯದು ಕೆಲಸ ಮಾಡಿ ಎರಡನೆಯದು ಮಾಡದಿದ್ದರೆ, ಸುರಂಗ ಆರೋಗ್ಯಕರವಾಗಿದೆ ಮತ್ತು ಶೋಧನೆಯೇ ಇಡೀ ಸಮಸ್ಯೆ.