Translēšana caur VPN: atklāšana, vadība vai straume?
Trūkstošs uztvērējs, atteikta sesija un iesprūdusi straume neizdodas dažādās vietās. Nosauciet posmu, pirms maināt tālruņa VPN politiku vai tīklu.
Translēšana salūzt trīs vietās, kas no dīvāna izskatās vienādi. Tālrunis var nekad neredzēt uztvērēju, uztvērējs var parādīties un pēc tam atteikt sesiju, vai arī sesija var sākties un pēc minūtes iesprūst. Tunelis tālrunī katru no šiem ceļiem maina citādi, un vienam no tiem tas nemaina neko. Vispirms nosauciet neizdevušos posmu un tad izlemiet, vai politikas maiņa vispār ir īstā svira, ko vilkt.
Nosauciet neizdevušos posmu pirms politikas maiņas
Vērojiet, ko tālrunis dara uzreiz pēc tam, kad pieskaraties translēšanas ikonai. Tukšs saraksts ir atklāšanas rezultāts, pieskāriens, kas ziņo par kļūdu, ir vadības rezultāts, un sesija, kas sākas un tikai pēc tam iesprūst, ir atskaņošanas rezultāts. Šiem trim ir dažādi saimnieki, un tikai pirmie divi parasti skar tālruņa tuneļa iestatījumus.
| 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 |
Pirms kaut ko mainīt, pierakstiet posmu. Nepareizajā posmā pielietots labojums padara nākamo testu neizlasāmu, un lielākā daļa translēšanas folkloras nāk tieši no šīs sajaukšanas.
Atklāšana ir vietējā satiksme, un tunelis to paslēpj
Uztvērēji sevi reklamē ar vietējiem paziņojumiem, un tālrunis tos atrod ar vaicājumiem tajā pašā posmā, tāpēc jebkas, kas izņem tālruni no šī posma, izņem uztvērēju no saraksta. Tunelis, kas novirza visu satiksmi prom no LAN, var paslēpt šīs apmaiņas, un programmas līmeņa vietējā tīkla atļauja var tos bloķēt pat tad, ja maršruts pastāv. Viesu Wi-Fi ar klientu izolāciju rada tādu pašu tukšu sarakstu bez VPN. Pirms vainot tuneli, pierādiet, ka abas ierīces dala vienu posmu.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRPirmā komanda uzskaita, kas sevi paziņo palīgmašīnas posmā, un otrā tieši jautā daudzapraides DNS grupai. Uztvērējs, kas nav redzams nevienā, neparādīsies arī tālruņa lietotnē, lai kāds būtu tālruņa tuneļa stāvoklis. Ja uztvērējs ir redzams no ierīces, kuras tunelis ir izslēgts, un nav redzams no ierīces, kuras tunelis ir ieslēgts, jūs esat atradis gan posmu, gan cēloni kopā.
LAN izņēmums saglabā tuneli ieslēgtu
Daudzi klienti piedāvā vietējā tīkla izņēmumu, kas atstāj tuneli aktīvu, bet atļauj vietējās adreses. Izmantojiet šo dokumentēto iestatījumu, nevis izslēdziet drošības slēdzi vai visu ugunsmūri, jo tie maina daudz vairāk, nekā translēšanai vajag. Ja tīkls apzināti atdala viedierīces, lūdziet īpašniekam konkrēto atklāšanas, vadības un atgriešanās satiksmi, nevis plakanu piekļuvi.
nc -vz 192.168.1.50 8009Vadības tests pret uztvērēju atdala atļauju no sasniedzamības: ports, kas atbild, nozīmē, ka ceļš pastāv, bet atteikums nozīmē, ka tālrunim tika ļauts atklāt ierīci un tas joprojām nevar ar to runāt. Porti 8008 un 8009 ir parastie translēšanas porti, un lietotne var izmantot citus, tāpēc vienu atteiktu portu uztveriet kā mājienu, nevis spriedumu. Izņēmums un lietotnes atļauja paliek neatkarīgi, jo vietējas piekļuves piešķiršana neizveido maršrutu, un maršruta pievienošana nepiešķir atļauju. Drošības slēdzis var arī nomest vietējo satiksmi pēc atkārtotas savienošanas, tāpēc atklāšana ir jāpārbauda vēlreiz, kad tunelis ir atpakaļ.
Atskaņošana var neizmantot tālruņa savienojumu
Lietotnes vadītā sesijā tālrunis nodod uztvērējam mediju adresi, un uztvērējs to iegūst pa savu savienojumu, tāpēc tālruņa publiskās adreses maiņa straumei neko nedod. Ar kontu saistīts nosaukums joprojām var neizdoties savu iemeslu dēļ, un Google translēšanas prasības aptver lietotnes un ierīces saderību, nevis tīkla ceļu. Televizora maršrutēšana caur tuneli ir atsevišķa konfigurācija ar saviem politikas jautājumiem.
Divi pavedieni atšķir režīmus. Translēšana, kas turpinās pēc tālruņa ekrāna bloķēšanas, ir lietotnes vadīta, jo uztvērējs saturu iegūst pats; spoguļošana, kas apstājas, kad sūtītāja ekrāns tiek bloķēts, ir nepārtraukta straume no tālruņa. Kad atklāšana un vadība izdodas, bet atskaņošana iesprūst, skatieties uz uztvērēja Wi-Fi saiti un tā interneta ceļu, jo ātruma tests tālrunī raksturo tālruni, nevis televizoru.
Atsauciet izņēmumu un pārbaudiet vēlreiz
Katrai pagaidu izmaiņai vajag ceļu atpakaļ, un secība ir svarīga. Noņemiet LAN izņēmumu, atkārtoti pievienojiet tuneli, lai klients no jauna piemērotu savu politiku, pēc tam atkārtojiet atklāšanas soli un atzīmējiet, vai uztvērējs atkal pazūd. Šī secība parāda, vai izņēmums darīja darbu, vai arī starplaikā mainījās kaut kas cits.
# 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'Pēc tam pārbaudiet trīs posmus atsevišķi, jo viena izturēšana neko nepasaka par pārējiem. Tad pārbaudiet, vai nesaistītas tālruņa lietotnes joprojām seko paredzētajam maršrutam, jo vietējs izņēmums, kas klusi kļuvis par pilnīgu apiešanu, ir sliktāks iznākums nekā translēšana, kurai vajag vienu papildu pieskārienu.