Transmetimi përmes VPN: zbulim, kontroll apo transmetim?
Një marrës që mungon, një sesion i refuzuar dhe një transmetim që bllokohet dështojnë në vende të ndryshme. Emërto fazën përpara se të ndryshosh politikën VPN të telefonit ose rrjetin.
Transmetimi prishet në tre vende që duken njësoj nga divani. Telefoni mund të mos e shohë kurrë marrësin, marrësi mund të shfaqet dhe më pas ta refuzojë sesionin, ose sesioni mund të nisë dhe të bllokohet një minutë më vonë. Tuneli në telefon e ndryshon secilën nga ato rrugë ndryshe, dhe për njërën prej tyre nuk ndryshon asgjë. Emërto së pari fazën që dështon, pastaj vendos nëse ndryshimi i politikës është me të vërtetë levë e duhur.
Emërto fazën që dështon përpara se të ndryshosh politikën
Vëzhgo çfarë bën telefoni menjëherë pasi prek ikonën e transmetimit. Një listë e zbrazët është rezultat i zbulimit, një prekje që raporton dështim është rezultat i kontrollit, dhe një sesion që niset para se të bllokohet është rezultat i riprodhimit. Këto të tre kanë pronarë të ndryshëm, dhe zakonisht vetëm të parët dy prekin cilësimet e tunelit të telefonit.
| 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 |
Shkruaje fazën përpara se të ndryshosh gjë. Një rregullim i aplikuar në fazën e gabuar e bën testin pasues të palexueshëm, dhe pjesa më e madhe e folklorit të transmetimit vjen pikërisht nga kjo ngatërresë.
Zbulimi është trafik lokal, dhe një tunel e fsheh atë
Marrësit reklamohen përmes njoftimeve lokale dhe telefoni i gjen me pyetje në të njëjtin lidhje, kështu që çdo gjë që e heq telefonin nga ajo lidhje e heq marrësin nga lista. Një tunel që i drejton të gjithë trafikun larg LAN-it mund t'i fshehë ato shkëmbime, dhe një leje e rrjetit lokal në nivel aplikacioni mund t'i bllokojë ato edhe kur rruga ekziston. Wi-Fi për vizitorë me izolim klientësh jep të njëjtën listë të zbrazët pa asnjë VPN. Vërteto që dy pajisjet ndajnë një segment përpara se të fajësosh tunelin.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRKomanda e parë rendit atë që reklamohet në segmentin e makinës ndihmëse, dhe e dyta e pyet drejtpërdrejt grupin multicast DNS. Një marrës që mungon në të dyja nuk do të shfaqet as në një aplikacion telefoni, cilido qoftë gjendja e tunelit. Nëse marrësi shihet nga një pajisje me tunelin e fikur dhe nuk shihet nga një me tunelin e ndezur, ke gjetur fazën dhe shkakun së bashku.
Një përjashtim LAN e mban tunelin aktiv
Shumë klientë ofrojnë një përjashtim të rrjetit lokal që e lë tunelin aktiv duke lejuar adresa lokale. Përdor atë cilësim të dokumentuar në vend që të fikësh kill switch-in ose gjithë firewall-in, sepse ato ndryshojnë shumë më tepër sesa i nevojitet transmetimit. Nëse rrjeti i ndan me qëllim pajisjet inteligjente, kërko nga pronari trafikun konkret të zbulimit, kontrollit dhe kthimit, jo akses të sheshtë.
nc -vz 192.168.1.50 8009Një test kontrolli drejt marrësit e ndan lejen nga arritshmëria: një port që përgjigjet do të thotë se rruga ekziston, ndërsa një refuzim do të thotë se telefonit iu lejua ta zbulojë pajisjen dhe ende nuk mund të flasë me të. Portat 8008 dhe 8009 janë portat e zakonshme të transmetimit, dhe një aplikacion mund të përdorë të tjera, prandaj trajto një port të refuzuar si të dhënë dhe jo si verdikt. Përjashtimi dhe leja e aplikacionit mbeten të pavarura, sepse dhënia e aksesit lokal nuk krijon rrugë, dhe shtimi i një rruge nuk jep leje. Kill switch-i gjithashtu mund të hedhë trafikun lokal pas një rilidhjeje, prandaj zbulimi duhet të ritestohet kur tuneli kthehet.
Riprodhimi mund të mos e përdorë lidhjen e telefonit
Në një sesion të drejtuar nga aplikacioni, telefoni i jep marrësit një adresë mediaje dhe marrësi e merr përmes lidhjes së vet, kështu që ndryshimi i adresës publike të telefonit nuk bën asgjë për transmetimin. Një titull i kufizuar nga llogaria mund të dështojë ende për arsye të vetat, dhe kërkesat e Google për transmetimin mbulojnë përputhshmërinë e aplikacionit dhe të pajisjes, jo rrugën e rrjetit. Drejtimi i vetë televizorit përmes një tuneli është konfigurim i veçantë me pyetjet e veta të politikës.
Dy të dhëna i dallojnë mënyrat. Një transmetim që vazhdon edhe pas kyçjes së ekranit të telefonit drejtohet nga aplikacioni, sepse marrësi e merr vetë; një pasqyrim që ndalon kur kyçet ekrani i dërguesit është transmetim i vazhdueshëm nga telefoni. Kur zbulimi dhe kontrolli uspejnë por riprodhimi bllokohet, shiko në vend të kësaj lidhjen Wi-Fi të marrësit dhe rrugën e tij në internet, sepse testi i shpejtësisë në telefon përshkruan telefonin dhe jo televizorin.
Hiq përjashtimin dhe ritesto
Çdo ndryshim i përkohshëm ka nevojë për një rrugë kthimi, dhe radha ka rëndësi. Hiq përjashtimin LAN, rilidh tunelin që klienti ta zbatojë përsëri politikën e vet, pastaj përsërit hapin e zbulimit dhe shëno nëse marrësi zhduket përsëri. Ai sekuencë të tregon nëse përjashtimi po bënte punën apo nëse diçka tjetër ndryshoi në mes.
# 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'Më pas verifiko tre fazat veçmas, sepse suksesi në njërën nuk thotë asgjë për të tjerat. Pastaj kontrollo nëse aplikacionet e tjera të telefonit vazhdojnë të ndjekin rrugën e synuar, sepse një përjashtim lokal që u bë në heshtje një anashkalim i plotë është rezultat më i keq sesa një transmetim që kërkon një prekje shtesë.