Miks castimine lakkab töötamast pärast ruuteri VPN-i sisselülitamist
Avastamine käib lokaalse multicasti kaudu, samal ajal kui teler laadib meediumid ise alla. Vaikimisi poliitika võib LAN-i päringu kinni püüda ja tunnelisse saata.
Castimine töötas enne ruuteri VPN-i sisselülitamist ja ebaõnnestub kohe pärast seda, samal ajal kui tavaline veebilehitsemine telefonis töötab edasi. Need kaks fakti on kooskõlas, sest castimine ei ole üks ühendus. Telefon avastab ja juhib vastuvõtjat lokaalse võrgu kaudu ning seejärel laadib vastuvõtja meediumid omaenda ühenduse kaudu.
Kaks teed, mis ebaõnnestuvad erinevalt
Juhtimistee on lokaalne. Telefon leiab vastuvõtja, küsides lokaalset võrku, ja avab seejärel juhtimisühenduse aadressile, mille ta õppis. Kui vastuvõtja ei ilmu kunagi loendisse, ebaõnnestus avastamise samm enne, kui ühtegi meediumi küsiti.
Meediumitee ei ole tingimata lokaalne. Paljud vastuvõtjad laadivad voo ise alla, omaenda ühenduse ja omaenda volituste kaudu, seega telefoni marsruut ei kirjelda vastuvõtja marsruuti. Telefon, mis näiliselt kasutab üht väljapääsu, ei ütle midagi selle kohta, kuhu teleri liiklus läheb.
Just see lõhenemine teebki rikke kummaliseks. Tunnel muutis telefoni marsruutimistabelit ja ei muutnud teleri oma, seega paari ühel poolel ilmuv sümptom tuleb jälgida sellel poolel. Vale seadme jälgimine on tavaline põhjus, miks parandus näib mitte midagi tegevat.
Miks avastamine esimesena katkeb
Avastamine käib tavaliselt link-lokaalse multicastiga. mDNS saadab aadressile 224.0.0.251 UDP-pordil 5353 ja SSDP saadab aadressile 239.255.255.250 UDP-pordil 1900. Mõlemad on projekteerimise järgi piiratud ühe lingiga, mistõttu ruuter ei edasta neid segmentide vahel ilma kordaja või puhverserveri abita. Marsruuditud VPN ei laienda multicast-gruppi ja poliitika marsruut ei saa panna linki kunagi lahkunud gruppi teisel lingil ilmuma.
Seega esimesel rikkel pole krüptimisega mingit pistmist. Telefoni multicast lahkub liideselt, kuhu see saadeti, vastuvõtja on segmendis, mis ei näe seda kunagi, ja seadmete loend tuleb tühjalt tagasi. Tühi loend ei ole tõestus, et teler kaotas internetiühenduse.
Isoleerimine tekitab sama sümptomi ilma igasuguse VPN-ita. Külalisvõrgud ja juurdepääsupunktide kliendiisoleerimine takistavad sihilikult seadmetel omavahel rääkida ning ruuteri VPN-i sisselülitamine isoleeritud segmendi kohal ei muuda selles midagi. Kontrolli isoleerimise seadet enne, kui kontrollid tunnelit. See on odavam vastus ja tavalisem.
Segmentide paigutus on teine pool. Teine ruuter, teises režiimis mesh-sõlm või juhtmega segment veel ühe NAT-i taga panevad kõik vastuvõtja sinna, kuhu telefoni avastamisliiklus ei ulatu.
Miks vaikimisi poliitika võib lokaalse päringu alla neelata
Ruuter, mis suunab kogu liikluse tunnelisse, paigaldab tunneli liidesele vaikimisi marsruudi. Kui LAN-i prefiks ei ole sellest poliitikast välja jäetud, vastab kahe meetri kaugusel olevale seadmele adresseeritud pakett nüüd vaikimisi marsruudile ja ruuter saadab juhtimispäringu tunnelisse, mitte kommutaatorile.
| 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 |
Tulemuse otsustab reeglite järjekord. Poliitikapõhine marsruutimine hindab reegleid prioriteedi järjekorras, seega peab kohaliku prefiksi erand olema enne reeglit, mis valib tunneli tabeli. Erandi lisamine pärast tunneli reeglit ei avalda mõju, mistõttu õigena näiv konfiguratsioon võib ikkagi saata LAN-i liikluse kaugesse väljapääsu.
Parandus on kitsas: luba konkreetsed kohalikud sihtkohad, mida castimisvoog vajab, ja jäta ülejäänud isoleerimine puutumata. Kliendiisoleerimise eemaldamine esimese sammuna parandab sümptomi, kuid viskab ära kontrolli, mille jaoks võrk oli projekteeritud.
Kiire päring telefonis selgitab, milline kahest rikkest sul on. Kui marsruut vastuvõtjani osutab tunnelisse, on probleem poliitikas. Kui see osutab LAN-i ja avastamine ikka ebaõnnestub, on probleem multicastis või isoleerimises ning ükski marsruudi muudatus ei aita.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTesti sammu, mis muutus, mitte riiki
Üles tähendatud tähelepanekud on väärtuslikumad kui korduvad katsed. Pane kirja, kas vastuvõtja ilmub seadmete loendisse, kas juhtimispäring jõuab temani ja kas taasesitus algab, kui voog on valitud. Iga vastus eemaldab ühe sammu kahtluse alt.
Seejärel testi iga sammu otse, selle asemel et väljapääsude asukohti vahetada. VPN-i riigi vahetamine testib meediumiteed ja jätab avastamise ning juhtimise sammud puutumata, seega võib see juhuslikult aidata näida, õpetamata sulle midagi.
Vastuvõtja poolel kontrolli tema enda marsruuti ja tema konto olekut. Teler, mis laadib meediumid alla teisest väljapääsust kui telefon, on tavaline lahendus ning sealne rike on küsimus vastuvõtja võrgupoliitikast, mitte telefoni tunnelist.
Kirjuta tulemus ühe lausena sellest, milline samm katkes ja mis seda muutis. See lause on väärt rohkem kui nädal riikide vahetamist ja see elab üle järgmise püsivara uuenduse.
Castimine on hea testjuhtum üldise tunneli-reegli jaoks. Kui võrku lisatakse tunnel, on esimene küsimus millised sihtkohad ei oleks tohtinud sinna kunagi sattuda. Teine on, millised neist poliitika ikkagi vaikselt vastu võttis.