Zašto emitovanje prestaje da radi nakon uključivanja VPN-a na ruteru
Otkrivanje ide preko link-local multicast-a, dok televizor sam preuzima medije. Podrazumevano pravilo politike može da uhvati LAN zahtev i pošalje ga u tunel.
Emitovanje je radilo pre uključivanja VPN-a na ruteru i prestaje da radi odmah nakon toga, dok obično pregledanje na telefonu i dalje radi. Ove dve činjenice su saglasne, jer emitovanje nije jedna veza. Telefon pronalazi i kontroliše prijemnik preko lokalne mreže, a zatim prijemnik preuzima medije preko sopstvene veze.
Dve putanje koje otkazuju na različit način
Putanja upravljanja je lokalna. Telefon pronalazi prijemnik pitajući lokalnu mrežu, zatim otvara upravljačku vezu ka naučenoj adresi. Ako se prijemnik nikada ne pojavi na listi, korak otkrivanja je propao pre nego što su zatraženi bilo kakvi mediji.
Putanja medija nije nužno lokalna. Mnogi prijemnici sami preuzimaju tok, preko sopstvene veze i sa sopstvenim akreditivima, pa putanja telefona ne opisuje putanju prijemnika. Telefon koji izgleda da koristi jedan izlaz ništa ne govori o tome kuda ide saobraćaj televizora.
Upravo ta podela čini kvar čudnim. Tunel je promenio tabelu rutiranja telefona i nije promenio onu televizora, pa simptom koji se pojavi na jednoj strani para mora da se prati na toj strani. Ispitivanje pogrešnog uređaja je uobičajen razlog zašto popravka izgleda da ništa ne radi.
Zašto otkrivanje prvo puca
Otkrivanje obično ide preko link-local multicast-a. mDNS šalje na 224.0.0.251 na UDP port 5353, a SSDP šalje na 239.255.255.250 na UDP port 1900. Oba su po konstrukciji ograničena na jednu vezu, zato ih ruter ne prosleđuje između segmenata bez pomoći ponavljača ili proksija. Rutirani VPN ne proširuje multicast grupu, a putanja politike ne može da natera grupu koja nikada nije napustila vezu da se pojavi na drugoj.
Zato prvi kvar nema veze sa šifrovanjem. Multicast telefona napušta interfejs sa kog je poslat, prijemnik je u segmentu koji ga nikada ne vidi, i lista uređaja se vraća prazna. Prazna lista nije dokaz da je televizor izgubio pristup internetu.
Izolacija daje identičan simptom i bez ikakvog VPN-a. Gostujuće mreže i izolacija klijenata na pristupnoj tački namerno sprečavaju uređaje da razgovaraju međusobno, a uključivanje VPN-a na ruteru preko izolovanog segmenta ništa u tome ne menja. Proverite podešavanje izolacije pre nego što proverite tunel. To je jeftiniji odgovor i češći.
Raspored segmenata je druga polovina. Drugi ruter, mesh čvor u drugom režimu ili žičani segment iza drugog NAT-a svi stavljaju prijemnik tamo gde saobraćaj otkrivanja telefona ne stiže.
Zašto podrazumevano pravilo politike može da proguta lokalni zahtev
Ruter koji sav saobraćaj šalje u tunel postavlja podrazumevanu putanju na tunelskom interfejsu. Ako LAN prefiks nije izuzet iz te politike, paket upućen uređaju na dva metra sada odgovara podrazumevanoj putanji, i ruter šalje upravljački zahtev u tunel umesto na svič.
| 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 |
Redosled pravila odlučuje ishod. Rutiranje po politici ocenjuje pravila po prioritetu, zato izuzetak za lokalni prefiks mora da stoji pre pravila koje bira tunelsku tabelu. Dodavanje izuzetka posle tunelskog pravila nema efekta, pa konfiguracija koja izgleda ispravno ipak može da šalje LAN saobraćaj ka udaljenom izlazu.
Popravka je uska: dozvolite konkretne lokalne odredišne tačke koje su potrebne toku emitovanja, a ostatak izolacije ostavite na miru. Uklanjanje izolacije klijenata kao prvi korak leči simptom, ali odbacuje kontrolu koju je mreža po konstrukciji trebalo da ima.
Brz pogled na telefon utvrđuje koji od dva kvara imate. Ako putanja do prijemnika pokazuje na tunel, problem je u politici. Ako pokazuje na LAN, a otkrivanje i dalje ne uspeva, problem je u multicast-u ili izolaciji, i nikakva promena putanje neće pomoći.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTestirajte korak koji se promenio, a ne zemlju
Zabeležena zapažanja pobeđuju ponovljene eksperimente. Zabeležite da li se prijemnik pojavljuje na listi uređaja, da li upravljački zahtev stiže do njega i da li se reprodukcija pokreće kada se izabere tok. Svaki odgovor uklanja jedan korak iz sumnje.
Zatim testirajte svaki korak direktno, umesto da menjate izlazne lokacije. Promena zemlje VPN-a testira putanju medija i ostavlja korake otkrivanja i upravljanja netaknutim, pa može slučajno da izgleda kao pomoć, ne naučivši vas ničemu.
Na strani prijemnika proverite njegovu sopstvenu putanju i stanje njegovog sopstvenog naloga. Televizor koji preuzima medije preko drugog izlaza od telefona je normalna konstrukcija, a kvar tamo je pitanje o mrežnoj politici prijemnika, ne o tunelu telefona.
Zapišite rezultat kao jednu rečenicu o tome koji se korak pokvario i šta ga je promenilo. Ta rečenica vredi više od nedelje menjanja zemalja i preživljava sledeće ažuriranje firmvera.
Emitovanje je dobar test slučaj za opšte pravilo o tunelima. Kada se tunel doda u mrežu, prvo pitanje je koje odredišne tačke nikada nisu trebalo da uđu u njega, a drugo koje je od njih politika ipak tiho prihvatila.