Leáll a vetítés VPN alatt: felderítés, vezérlés vagy adatfolyam?
Egy hiányzó fogadó, egy elutasított munkamenet és egy elakadó adatfolyam más-más ponton hibázik. Nevezze meg a szakaszt, mielőtt módosítja a telefon VPN-szabályát vagy a hálózatot.
A vetítés három helyen törik el, amelyek a kanapéról egyformának látszanak. A telefon lehet, hogy soha nem látja a fogadót, a fogadó megjelenhet, majd elutasíthatja a munkamenetet, vagy a munkamenet elindulhat és egy perccel később elakadhat. A telefonon lévő alagút mindegyik utat másképp változtatja meg, és az egyiknél semmit sem változtat. Először nevezze meg a hibázó szakaszt, aztán döntse el, hogy a szabálymódosítás egyáltalán a megfelelő kar-e.
Nevezze meg a hibázó szakaszt, mielőtt módosítja a szabályt
Figyelje, mit tesz a telefon közvetlenül a vetítés ikon megérintése után. Az üres lista felderítési eredmény, a hibát jelző érintés vezérlési eredmény, az elakadás előtt induló munkamenet pedig lejátszási eredmény. Ennek a háromnak különböző a gazdája, és általában csak az első kettő érinti a telefon alagútbeállításait.
| 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 |
Írja fel a szakaszt, mielőtt bármit módosít. A rossz szakaszra alkalmazott javítás olvashatatlanná teszi a következő próbát, és a vetítésről szóló mendemondák többsége épp ebből a zavarból ered.
A felderítés helyi forgalom, és az alagút elrejti
A fogadók helyi hirdetésekkel jelentkeznek be, a telefon pedig ugyanazon a kapcsolaton lévő lekérdezésekkel találja meg őket, tehát bármi, ami eltávolítja a telefont erről a kapcsolatról, a fogadót is eltávolítja a listáról. Az alagút, amely minden forgalmat a LAN-tól elfelé irányít, elrejtheti ezeket a cseréket, és az alkalmazásszintű helyi hálózati engedély akkor is blokkolhatja őket, ha az útvonal létezik. A vendég Wi-Fi kliensizolációval ugyanezt az üres listát adja, VPN nélkül. Bizonyítsa, hogy a két eszköz egy szegmenst oszt meg, mielőtt az alagutat okolná.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRAz első parancs felsorolja, mi hirdeti magát a segédgép szegmensében, a második pedig közvetlenül a többesküldéses DNS-csoportot kérdezi. Az a fogadó, amelyik egyikben sem szerepel, a telefon alkalmazásában sem fog megjelenni, bármilyen is a telefon alagútjának állapota. Ha a fogadó látható egy kikapcsolt alagútú eszközről, és nem látható egy bekapcsoltéról, egyszerre találta meg a szakaszt és az okot.
A LAN-kivétel működésben tartja az alagutat
Sok kliens kínál helyi hálózati kivételt, amely működésben hagyja az alagutat, miközben engedi a helyi címeket. Használja ezt a dokumentált beállítást, ne kapcsolja ki a kill switch-et vagy az egész tűzfalat, mert azok sokkal többet változtatnak, mint amire a vetítésnek szüksége van. Ha a hálózat szándékosan választja el az intelligens eszközöket, kérje a tulajdonostól a konkrét felderítési, vezérlési és visszatérő forgalmat, ne lapos hozzáférést.
nc -vz 192.168.1.50 8009A fogadó felé irányuló vezérlési teszt elválasztja az engedélyt az elérhetőségtől: a válaszoló port azt jelenti, hogy létezik az útvonal, az elutasítás pedig azt, hogy a telefon felderíthette az eszközt, és mégsem tud beszélni vele. A 8008 és 8009 port a szokásos vetítési port, és egy alkalmazás másokat is használhat, ezért az egyetlen elutasított portot nyomnak tekintse, ne ítéletnek. A kivétel és az alkalmazásengedély független marad, mert a helyi hozzáférés nem hoz létre útvonalat, és az útvonal hozzáadása nem ad engedélyt. A kill switch újracsatlakozás után a helyi forgalmat is eldobhatja, ezért az újracsatlakozás után a felderítést újra kell tesztelni, amint az alagút visszatér.
Lehet, hogy a lejátszás nem a telefon kapcsolatát használja
Az alkalmazás vezérelte munkamenetben a telefon média címet ad a fogadónak, és a fogadó a saját kapcsolatán tölti le, így a telefon nyilvános címének módosítása semmit sem tesz az adatfolyamért. A fiókhoz kötött cím saját okokból így is meghiúsulhat, és a Google vetítési követelményei az alkalmazás és az eszköz kompatibilitását fedik le, nem a hálózati útvonalat. Magát a televíziót alagúton át vezetni külön beállítás, saját szabálykérdésekkel.
Két nyom megkülönbözteti a módokat. A vetítés, amely túléli a telefon képernyőjének lezárását, alkalmazásvezérelt, mert a fogadó maga tölti le; a tükrözés, amely a küldő képernyőjének lezárásakor megáll, folyamatos adatfolyam a telefonról. Amikor a felderítés és a vezérlés sikerül, de a lejátszás elakad, inkább a fogadó Wi-Fi-kapcsolatát és internetes útvonalát nézze, mert a telefonon végzett sebességteszt a telefont írja le, nem a televíziót.
Vonja vissza a kivételt, és tesztelje újra
Minden ideiglenes változtatásnak kell visszaút, és a sorrend számít. Távolítsa el a LAN-kivételt, csatlakoztassa újra az alagutat, hogy a kliens újra alkalmazza a szabályát, majd ismételje meg a felderítési lépést, és jegyezze fel, eltűnik-e újra a fogadó. Ez a sorrend megmondja, a kivétel végezte-e a munkát, vagy közben más változott.
# 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'Utána ellenőrizze a három szakaszt külön, mert az egyik sikere semmit sem mond a többiről. Aztán ellenőrizze, hogy a nem kapcsolódó telefonos alkalmazások még a tervezett útvonalon járnak-e, mert a csendben teljes megkerüléssé vált helyi kivétel rosszabb eredmény, mint egy vetítés, amelyhez egy plusz érintés kell.