Pse transmetimi ndalon së punuari pasi aktivizohet VPN i ruterit
Zbulimi kalon përmes multicast link-local, ndërsa televizori i shkarkon vetë mediat. Një rregull i parazgjedhur i politikës mund të kapë kërkesën LAN dhe ta dërgojë në tunel.
Transmetimi funksiononte para se të aktivizohej VPN i ruterit dhe dështon menjëherë pas, ndërsa shfletimi i zakonshëm në telefon vazhdon të funksionojë. Të dy faktet janë të qëndrueshme, sepse transmetimi nuk është një lidhje e vetme. Telefoni zbulon dhe kontrollon marrësin përmes rrjetit lokal, dhe pastaj marrësi i shkarkon mediat përmes lidhjes së vet.
Dy rrugë që dështojnë ndryshe
Rruga e kontrollit është lokale. Telefoni gjen një marrës duke pyetur rrjetin lokal, pastaj hap një lidhje kontrolli drejt adresës që mësoi. Nëse marrësi nuk shfaqet kurrë në listë, hapi i zbulimit dështoi para se të kërkohej ndonjë media.
Rruga e mediave nuk është domosdoshmërisht lokale. Shumë marrës e shkarkojnë rrjedhën vetë, përmes lidhjes së tyre dhe me kredencialet e tyre, prandaj rruga e telefonit nuk e përshkruan rrugën e marrësit. Një telefon që duket se përdor një dalje nuk thotë asgjë për atë se ku shkon trafiku i televizorit.
Kjo ndarje është arsyeja pse defekti duket i çuditshëm. Tuneli ndryshoi tabelën e rrugëzimit të telefonit dhe nuk ndryshoi atë të televizorit, prandaj një simptom që shfaqet në njërën anë të çiftit duhet të ndiqet në atë anë. Hetimi i pajisjes së gabuar është arsyeja e zakonshme pse një rregullim duket se nuk bën asgjë.
Pse zbulimi prishet i pari
Zbulimi zakonisht kalon përmes multicast link-local. mDNS dërgon te 224.0.0.251 në portën UDP 5353, dhe SSDP dërgon te 239.255.255.250 në portën UDP 1900. Të dyja janë të kufizuara në një lidhje sipas konstruksionit, prandaj ruteri nuk i përcjell midis segmenteve pa ndihmën e një përsëritësi ose përfaqësuesi. Një VPN i rrugëzuar nuk zgjeron një grup multicast, dhe një rrugë politike nuk mund ta bëjë një grup që nuk e la kurrë lidhjen të shfaqet në një tjetër.
Prandaj defekti i parë nuk ka asnjë lidhje me kriptimin. Multicast i telefonit largohet nga ndërfaqja ku u dërgua, marrësi ndodhet në një segment që nuk e sheh kurrë, dhe lista e pajisjeve kthehet bosh. Një listë bosh nuk është provë se televizori humbi aksesin në internet.
Izolimi prodhon një simptom identik pa asnjë VPN. Rrjetet e mysafirëve dhe izolimi i klientëve në pikën e aksesit i ndalojnë qëllimisht pajisjet të flasin me njëra-tjetrën, dhe aktivizimi i një VPN në ruter mbi një segment të izoluar nuk ndryshon asgjë në këtë. Kontrolloni cilësimin e izolimit përpara se të kontrolloni tunelin. Kjo është përgjigjja më e lirë dhe më e zakonshmja.
Rregullimi i segmenteve është gjysma tjetër. Një ruter i dytë, një nyje mesh në një modalitet tjetër ose një segment me kabllo pas një NAT tjetër e vendosin marrësin atje ku trafiku i zbulimit të telefonit nuk arrin.
Pse një rregull i parazgjedhur i politikës mund të gëlltisë një kërkesë lokale
Një ruter që e dërgon të gjithë trafikun në një tunel instalon një rrugë të parazgjedhur në ndërfaqen e tunelit. Nëse prefiksi LAN nuk përjashtohet nga ajo politikë, një paketë e adresuar për një pajisje dy metra larg tani përputhet me të parazgjedhurën, dhe ruteri e dërgon kërkesën e kontrollit në tunel në vend të çelësit.
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
Rendi i rregullave vendos rezultatin. Rrugëzimi sipas politikës i vlerëson rregullat sipas përparësisë, prandaj një përjashtim për prefiksin lokal duhet të qëndrojë përpara rregullit që zgjedh tabelën e tunelit. Shtimi i përjashtimit pas rregullit të tunelit nuk ka efekt, prandaj një konfigurim që duket i saktë mund të vazhdojë të dërgojë trafik LAN drejt një daljeje të largët.
Rregullimi është i ngushtë: lejoni destinacionet konkrete lokale që i nevojiten rrjedhës së transmetimit, dhe lini pjesën tjetër të izolimit në qetësi. Heqja e izolimit të klientëve si hap i parë e shëron simptomën, por hedh poshtë një kontroll që rrjeti ishte projektuar ta kishte.
Një vështrim i shpejtë në telefon përcakton se cili nga dy defektet është. Nëse rruga drejt marrësit tregon tunelin, problemi është politika. Nëse tregon LAN dhe zbulimi ende dështon, problemi është multicast ose izolimi, dhe asnjë ndryshim rruge nuk do të ndihmojë.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpProvoni hapin që ndryshoi, jo vendin
Vëzhgimet e shënuara mundin eksperimentet e përsëritura. Shënoni nëse marrësi shfaqet në listën e pajisjeve, nëse një kërkesë kontrolli arrin tek ai dhe nëse riprodhimi nis pasi zgjidhet një rrjedhë. Çdo përgjigje heq një hap nga dyshimi.
Pastaj provoni çdo hap drejtpërdrejt, në vend që të ndërroni vendndodhjet e daljes. Ndryshimi i vendit të VPN provon rrugën e mediave dhe i lë hapat e zbulimit e të kontrollit të paprekur, prandaj mund të duket se ndihmon rastësisht pa ju mësuar asgjë.
Në anën e marrësit, kontrolloni rrugën e tij dhe gjendjen e llogarisë së tij. Një televizor që i shkarkon mediat përmes një daljeje tjetër nga telefoni është një konstruksion normal, dhe një defekt atje është pyetje për politikën e rrjetit të marrësit, jo për tunelin e telefonit.
Shënojeni rezultatin si një fjali të vetme për atë se cili hap u prish dhe çfarë e ndryshoi. Ajo fjali vlen më shumë se një javë ndryshim vendesh dhe i mbijeton përditësimit të ardhshëm të firmuerit.
Transmetimi është një rast i mirë prove për një rregull të përgjithshëm për tunelet. Kur një i tillë shtohet në një rrjet, pyetja e parë është cilat destinacione nuk duhej të kishin hyrë kurrë në të, dhe e dyta është cilat prej tyre politika i pranoi gjithsesi në heshtje.