VPN ನಲ್ಲಿ ಕಾಸ್ಟಿಂಗ್ ನಿಲ್ಲುತ್ತದೆ: ಶೋಧನೆ, ನಿಯಂತ್ರಣ ಅಥವಾ ಸ್ಟ್ರೀಮ್?
ಕಾಣೆಯಾದ ರಿಸೀವರ್, ತಿರಸ್ಕರಿಸಿದ ಸೆಷನ್ ಮತ್ತು ನಿಂತುಕೊಳ್ಳುವ ಸ್ಟ್ರೀಮ್ ಬೇರೆ ಬೇರೆ ಕಡೆ ವಿಫಲವಾಗುತ್ತವೆ. ಫೋನ್‌ನ VPN ನೀತಿ ಅಥವಾ ನೆಟ್ವರ್ಕ್ ಬದಲಿಸುವ ಮೊದಲು ಹಂತವನ್ನು ಗುರುತಿಸಿ.
ಕಾಸ್ಟಿಂಗ್ ಸೋಫಾದಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುವ ಮೂರು ಕಡೆ ಮುರಿಯುತ್ತದೆ. ಫೋನ್ ರಿಸೀವರ್ ಅನ್ನು ಎಂದಿಗೂ ನೋಡದಿರಬಹುದು, ರಿಸೀವರ್ ಕಾಣಿಸಿಕೊಂಡು ನಂತರ ಸೆಷನ್ ಅನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು, ಅಥವಾ ಸೆಷನ್ ಆರಂಭವಾಗಿ ಒಂದು ನಿಮಿಷದ ನಂತರ ನಿಲ್ಲಬಹುದು. ಫೋನ್‌ನಲ್ಲಿನ ಟನಲ್ ಆ ಮಾರ್ಗಗಳ ಪ್ರತಿಯೊಂದನ್ನೂ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ. ಮೊದಲು ವಿಫಲವಾಗುವ ಹಂತವನ್ನು ಗುರುತಿಸಿ, ನಂತರ ನೀತಿ ಬದಲಾವಣೆಯೇ ಸರಿಯಾದ ಹತೋಟಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ.
ನೀತಿ ಬದಲಿಸುವ ಮೊದಲು ವಿಫಲವಾಗುವ ಹಂತವನ್ನು ಗುರುತಿಸಿ
ಕಾಸ್ಟ್ ಐಕಾನ್ ಒತ್ತಿದ ತಕ್ಷಣ ಫೋನ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಖಾಲಿ ಪಟ್ಟಿ ಶೋಧನೆಯ ಫಲಿತಾಂಶ, ವೈಫಲ್ಯ ವರದಿ ಮಾಡುವ ಒತ್ತುವಿಕೆ ನಿಯಂತ್ರಣದ ಫಲಿತಾಂಶ, ಮತ್ತು ನಿಲ್ಲುವ ಮೊದಲು ಆರಂಭವಾಗುವ ಸೆಷನ್ ಪ್ಲೇಬ್ಯಾಕ್‌ನ ಫಲಿತಾಂಶ. ಈ ಮೂರಕ್ಕೆ ಬೇರೆ ಬೇರೆ ಮಾಲೀಕರಿದ್ದಾರೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಮೊದಲ ಎರಡು ಮಾತ್ರ ಫೋನ್‌ನ ಟನಲ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿವೆ.
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಹಂತವನ್ನು ಬರೆದಿಡಿ. ತಪ್ಪು ಹಂತಕ್ಕೆ ಅನ್ವಯಿಸಿದ ಸರಿಪಡಿಸುವಿಕೆ ಮುಂದಿನ ಪರೀಕ್ಷೆಯನ್ನು ಓದಲಾಗದಂತೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಕಾಸ್ಟಿಂಗ್ ಬಗ್ಗೆ ಇರುವ ಬಹುಪಾಲು ಕಥೆಗಳು ನಿಖರವಾಗಿ ಆ ಗೊಂದಲದಿಂದ ಬರುತ್ತವೆ.
ಶೋಧನೆ ಸ್ಥಳೀಯ ಸಂಚಾರ, ಮತ್ತು ಟನಲ್ ಅದನ್ನು ಮರೆಮಾಡುತ್ತದೆ
ರಿಸೀವರ್‌ಗಳು ಸ್ಥಳೀಯ ಘೋಷಣೆಗಳ ಮೂಲಕ ತಮ್ಮನ್ನು ಪ್ರಕಟಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಫೋನ್ ಅದೇ ಕೊಂಡಿಯ ಮೇಲಿನ ಪ್ರಶ್ನೆಗಳಿಂದ ಅವನ್ನು ಹುಡುಕುತ್ತದೆ, ಆದ್ದರಿಂದ ಫೋನ್ ಅನ್ನು ಆ ಕೊಂಡಿಯಿಂದ ತೆಗೆಯುವ ಯಾವುದೇ ವಿಷಯ ರಿಸೀವರ್ ಅನ್ನೂ ಪಟ್ಟಿಯಿಂದ ತೆಗೆಯುತ್ತದೆ. ಎಲ್ಲಾ ಸಂಚಾರವನ್ನು LAN ನಿಂದ ದೂರ ಕಳುಹಿಸುವ ಟನಲ್ ಆ ವಿನಿಮಯಗಳನ್ನು ಮರೆಮಾಡಬಹುದು, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ ಅನುಮತಿ ಮಾರ್ಗ ಇದ್ದರೂ ಅವನ್ನು ತಡೆಯಬಹುದು. ಕ್ಲೈಂಟ್ ಪ್ರತ್ಯೇಕತೆಯಿರುವ ಅತಿಥಿ Wi-Fi ಯಾವುದೇ VPN ಇಲ್ಲದೆಯೇ ಅದೇ ಖಾಲಿ ಪಟ್ಟಿಯನ್ನು ನೀಡುತ್ತದೆ. ಟನಲ್ ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಎರಡೂ ಸಾಧನಗಳು ಒಂದೇ ವಿಭಾಗವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ ಎಂದು ಸಾಬೀತು ಮಾಡಿ.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRಮೊದಲ ಆಜ್ಞೆ ಸಹಾಯಕ ಯಂತ್ರದ ವಿಭಾಗದಲ್ಲಿ ಯಾರು ತಮ್ಮನ್ನು ಘೋಷಿಸಿಕೊಳ್ಳುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯದು ಮಲ್ಟಿಕಾಸ್ಟ್ DNS ಗುಂಪನ್ನು ನೇರವಾಗಿ ಕೇಳುತ್ತದೆ. ಎರಡರಲ್ಲೂ ಇಲ್ಲದ ರಿಸೀವರ್ ಫೋನ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿಯೂ ಕಾಣಿಸುವುದಿಲ್ಲ, ಫೋನ್‌ನ ಟನಲ್ ಸ್ಥಿತಿ ಏನೇ ಇರಲಿ. ರಿಸೀವರ್ ಟನಲ್ ಆಫ್ ಇರುವ ಸಾಧನದಿಂದ ಕಾಣಿಸಿ, ಟನಲ್ ಆನ್ ಇರುವ ಸಾಧನದಿಂದ ಕಾಣಿಸದಿದ್ದರೆ, ನೀವು ಹಂತ ಮತ್ತು ಕಾರಣ ಎರಡನ್ನೂ ಒಟ್ಟಿಗೆ ಕಂಡುಕೊಂಡಿದ್ದೀರಿ.
LAN ವಿನಾಯಿತಿ ಟನಲ್ ಅನ್ನು ಆನ್ ಆಗಿ ಇಡುತ್ತದೆ
ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳು ಸ್ಥಳೀಯ ವಿಳಾಸಗಳಿಗೆ ಅನುಮತಿ ನೀಡುತ್ತಲೇ ಟನಲ್ ಸಕ್ರಿಯವಾಗಿರಿಸುವ ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ ವಿನಾಯಿತಿಯನ್ನು ನೀಡುತ್ತವೆ. ಕಿಲ್ ಸ್ವಿಚ್ ಅಥವಾ ಇಡೀ ಫೈರ್‌ವಾಲ್ ಆಫ್ ಮಾಡುವ ಬದಲು ಆ ದಾಖಲಿತ ಸೆಟ್ಟಿಂಗ್ ಬಳಸಿ, ಏಕೆಂದರೆ ಅವು ಕಾಸ್ಟಿಂಗ್‌ಗೆ ಬೇಕಾದುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಬದಲಿಸುತ್ತವೆ. ನೆಟ್ವರ್ಕ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸ್ಮಾರ್ಟ್ ಸಾಧನಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿದರೆ, ಸಮತಟ್ಟಾದ ಪ್ರವೇಶದ ಬದಲು ಮಾಲೀಕರಿಂದ ನಿರ್ದಿಷ್ಟ ಶೋಧನೆ, ನಿಯಂತ್ರಣ ಮತ್ತು ಹಿಂತಿರುಗುವ ಸಂಚಾರವನ್ನು ಕೇಳಿ.
nc -vz 192.168.1.50 8009ರಿಸೀವರ್ ವಿರುದ್ಧದ ನಿಯಂತ್ರಣ ಪರೀಕ್ಷೆ ಅನುಮತಿಯನ್ನು ತಲುಪುವಿಕೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ: ಉತ್ತರಿಸುವ ಪೋರ್ಟ್ ಮಾರ್ಗ ಇದೆ ಎಂದರ್ಥ, ಆದರೆ ನಿರಾಕರಣೆ ಎಂದರೆ ಫೋನ್‌ಗೆ ಸಾಧನವನ್ನು ಶೋಧಿಸಲು ಅನುಮತಿ ಇತ್ತು ಮತ್ತು ಆದರೂ ಅದರೊಂದಿಗೆ ಮಾತನಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. 8008 ಮತ್ತು 8009 ಪೋರ್ಟ್‌ಗಳು ಸಾಮಾನ್ಯ ಕಾಸ್ಟ್ ಪೋರ್ಟ್‌ಗಳು, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಬೇರೆ ಬಳಸಬಹುದು, ಆದ್ದರಿಂದ ಒಂದು ನಿರಾಕರಿಸಿದ ಪೋರ್ಟ್ ಅನ್ನು ತೀರ್ಪಲ್ಲ, ಸುಳಿವು ಎಂದು ಪರಿಗಣಿಸಿ. ವಿನಾಯಿತಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನುಮತಿ ಸ್ವತಂತ್ರವಾಗಿ ಉಳಿಯುತ್ತವೆ, ಏಕೆಂದರೆ ಸ್ಥಳೀಯ ಪ್ರವೇಶ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ ಮತ್ತು ಮಾರ್ಗ ಸೇರಿಸುವುದು ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ. ಕಿಲ್ ಸ್ವಿಚ್ ಮರುಸಂಪರ್ಕದ ನಂತರ ಸ್ಥಳೀಯ ಸಂಚಾರವನ್ನೂ ಬೀಳಿಸಬಹುದು, ಆದ್ದರಿಂದ ಟನಲ್ ಮರಳಿದ ಕೂಡಲೇ ಶೋಧನೆಯನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಬೇಕು.
ಪ್ಲೇಬ್ಯಾಕ್ ಫೋನ್‌ನ ಸಂಪರ್ಕವನ್ನು ಬಳಸದಿರಬಹುದು
ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ದೇಶಿಸುವ ಸೆಷನ್‌ನಲ್ಲಿ ಫೋನ್ ರಿಸೀವರ್‌ಗೆ ಮಾಧ್ಯಮ ವಿಳಾಸವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ರಿಸೀವರ್ ಅದನ್ನು ತನ್ನ ಸ್ವಂತ ಸಂಪರ್ಕದ ಮೂಲಕ ಪಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಫೋನ್‌ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಬದಲಿಸುವುದು ಸ್ಟ್ರೀಮ್‌ಗೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ. ಖಾತೆಯಿಂದ ಸೀಮಿತಗೊಳಿಸಿದ ಶೀರ್ಷಿಕೆ ತನ್ನ ಕಾರಣಗಳಿಗಾಗಿ ವಿಫಲವಾಗಬಹುದು, ಮತ್ತು Google ನ ಕಾಸ್ಟಿಂಗ್ ಅಗತ್ಯಗಳು ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಸಾಧನದ ಹೊಂದಾಣಿಕೆಯನ್ನು ಒಳಗೊಳ್ಳುತ್ತವೆ, ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗವನ್ನಲ್ಲ. ಟೆಲಿವಿಷನ್ ಅನ್ನೇ ಟನಲ್ ಮೂಲಕ ಕಳುಹಿಸುವುದು ತನ್ನದೇ ನೀತಿ ಪ್ರಶ್ನೆಗಳಿರುವ ಪ್ರತ್ಯೇಕ ಸಂರಚನೆ.
ಎರಡು ಸುಳಿವುಗಳು ಈ ಮೋಡ್‌ಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತವೆ. ಫೋನ್‌ನ ಪರದೆ ಲಾಕ್ ಆದರೂ ಮುಂದುವರಿಯುವ ಕಾಸ್ಟ್ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ದೇಶಿತ, ಏಕೆಂದರೆ ರಿಸೀವರ್ ತಾನೇ ಪಡೆಯುತ್ತದೆ; ಕಳುಹಿಸುವವರ ಪರದೆ ಲಾಕ್ ಆದಾಗ ನಿಲ್ಲುವ ಮಿರರ್ ಫೋನ್‌ನಿಂದ ಬರುವ ನಿರಂತರ ಸ್ಟ್ರೀಮ್. ಶೋಧನೆ ಮತ್ತು ನಿಯಂತ್ರಣ ಯಶಸ್ವಿಯಾಗಿ ಪ್ಲೇಬ್ಯಾಕ್ ನಿಂತರೆ, ಬದಲಿಗೆ ರಿಸೀವರ್‌ನ Wi-Fi ಕೊಂಡಿ ಮತ್ತು ಅದರ ಇಂಟರ್ನೆಟ್ ಮಾರ್ಗವನ್ನು ನೋಡಿ, ಏಕೆಂದರೆ ಫೋನ್‌ನಲ್ಲಿ ಮಾಡಿದ ವೇಗ ಪರೀಕ್ಷೆ ಟೆಲಿವಿಷನ್ ಅನ್ನಲ್ಲ, ಫೋನ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ.
ವಿನಾಯಿತಿಯನ್ನು ರದ್ದುಗೊಳಿಸಿ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ
ಪ್ರತಿ ತಾತ್ಕಾಲಿಕ ಬದಲಾವಣೆಗೂ ಹಿಂತಿರುಗುವ ದಾರಿ ಬೇಕು, ಮತ್ತು ಕ್ರಮ ಮುಖ್ಯ. LAN ವಿನಾಯಿತಿ ತೆಗೆದುಹಾಕಿ, ಕ್ಲೈಂಟ್ ತನ್ನ ನೀತಿಯನ್ನು ಮತ್ತೆ ಅನ್ವಯಿಸುವಂತೆ ಟನಲ್ ಮರುಸಂಪರ್ಕಿಸಿ, ನಂತರ ಶೋಧನೆಯ ಹಂತವನ್ನು ಪುನರಾವರ್ತಿಸಿ ಮತ್ತು ರಿಸೀವರ್ ಮತ್ತೆ ಮಾಯವಾಗುತ್ತದೆಯೇ ಎಂದು ಗಮನಿಸಿ. ಆ ಕ್ರಮವು ಕೆಲಸವನ್ನು ವಿನಾಯಿತಿ ಮಾಡುತ್ತಿತ್ತೇ ಅಥವಾ ಮಧ್ಯೆ ಬೇರೆ ಏನಾದರೂ ಬದಲಾಯಿತೇ ಎಂದು ಹೇಳುತ್ತದೆ.
# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'ನಂತರ ಮೂರೂ ಹಂತಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಒಂದರಲ್ಲಿ ಉತ್ತೀರ್ಣರಾದರೆ ಉಳಿದವುಗಳ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ. ನಂತರ ಫೋನ್‌ನ ಸಂಬಂಧವಿಲ್ಲದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಇನ್ನೂ ಉದ್ದೇಶಿತ ಮಾರ್ಗದಲ್ಲಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಮೌನವಾಗಿ ಸಂಪೂರ್ಣ ಬೈಪಾಸ್ ಆಗಿ ಬದಲಾದ ಸ್ಥಳೀಯ ವಿನಾಯಿತಿ ಒಂದು ಹೆಚ್ಚುವರಿ ಟ್ಯಾಪ್ ಬೇಕಾಗುವ ಕಾಸ್ಟ್‌ಗಿಂತ ಕೆಟ್ಟ ಫಲಿತಾಂಶ.