Հեռարձակումը կանգ է առնում VPN-ով. բացահայտում, կառավարում, թե հոսք?
Բացակայող ընդունիչը, մերժված նստաշրջանը և կանգ առնող հոսքը ձախողվում են տարբեր տեղերում: Անվանեք փուլը նախքան հեռախոսի VPN քաղաքականությունը կամ ցանցը փոխելը:
Հեռարձակումը կոտրվում է երեք տեղերում, որոնք բազկաթոռից նույնն են թվում: Հեռախոսը կարող է երբեք չտեսնել ընդունիչը, ընդունիչը կարող է հայտնվել և հետո մերժել նստաշրջանը, կամ նստաշրջանը կարող է սկսվել և մեկ րոպե անց կանգ առնել: Հեռախոսի թունելը յուրաքանչյուր այդ ուղին փոխում է տարբեր կերպ, և դրանցից մեկի համար ընդհանրապես ոչինչ չի փոխում: Նախ անվանեք ձախողվող փուլը, ապա որոշեք՝ արդյոք քաղաքականության փոփոխությունը ճիշտ լծակն է:
Անվանեք ձախողվող փուլը նախքան քաղաքականությունը փոխելը
Դիտեք, թե հեռախոսն ինչ է անում հեռարձակման պատկերակը սեղմելուց անմիջապես հետո: Դատարկ ցանկը բացահայտման արդյունք է, ձախողում հայտնող սեղմումը՝ կառավարման արդյունք, իսկ կանգ առնելուց առաջ սկսվող նստաշրջանը՝ նվագարկման արդյունք: Այս երեքն ունեն տարբեր տերեր, և սովորաբար միայն առաջին երկուսն են առնչվում հեռախոսի թունելի կարգավորումներին:
| 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 |
Գրեք փուլը նախքան որևէ բան փոխելը: Սխալ փուլի վրա կիրառված ուղղումը հաջորդ փորձարկումը դարձնում է անընթեռնելի, և հեռարձակման մասին պատմությունների մեծ մասը գալիս է հենց այդ շփոթությունից:
Բացահայտումը տեղական երթևեկություն է, և թունելը թաքցնում է այն
Ընդունիչները հայտարարում են իրենց տեղական հայտարարություններով, և հեռախոսը գտնում է նրանց նույն կապուղու հարցումներով, ուստի այն ամենը, ինչ հեռացնում է հեռախոսին այդ կապուղուց, հեռացնում է նաև ընդունիչին ցանկից: Թունելը, որն ուղղում է ողջ երթևեկությունը LAN-ից դուրս, կարող է թաքցնել այդ փոխանակումները, և հավելվածի մակարդակի տեղական ցանցի թույլտվությունը կարող է արգելափակել դրանք նույնիսկ երբ ուղին գոյություն ունի: Հյուրային Wi-Fi-ը հաճախորդների մեկուսացմամբ ստեղծում է նույն դատարկ ցանկը առանց որևէ VPN-ի: Ապացուցեք, որ երկու սարքերը կիսում են սեգմենտը, նախքան թունելին մեղադրելը:
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRԱռաջին հրամանը թվարկում է, թե ինչ է հայտարարում իրեն օժանդակ մեքենայի սեգմենտում, իսկ երկրորդը ուղղակիորեն հարցնում է բազմահեռարձակ DNS խմբին: Երկուսում էլ բացակայող ընդունիչը չի հայտնվի նաև հեռախոսի հավելվածում, ինչ էլ լինի հեռախոսի թունելի վիճակը: Եթե ընդունիչը տեսանելի է անջատված թունելով սարքից և անտեսանելի՝ միացված թունելով սարքից, ապա գտել եք և՛ փուլը, և՛ պատճառը միասին:
LAN-ի բացառությունը թունելը պահում է միացված
Շատ հաճախորդներ առաջարկում են տեղական ցանցի բացառություն, որը թունելը թողնում է ակտիվ՝ միաժամանակ թույլատրելով տեղական հասցեներ: Օգտագործեք այդ փաստաթղթավորված կարգավորումը, փոխարենը մի անջատեք kill switch-ը կամ ամբողջ հրապատը, որովհետև դրանք փոխում են շատ ավելին, քան հեռարձակմանը պետք է: Եթե ցանցը դիտավորյալ առանձնացնում է խելացի սարքերը, ցանցի տիրոջից խնդրեք կոնկրետ բացահայտման, կառավարման և վերադարձի երթևեկությունը, ոչ թե հարթ մուտք:
nc -vz 192.168.1.50 8009Ընդունիչի դեմ կառավարման փորձարկումը բաժանում է թույլտվությունը հասանելիությունից. պատասխանող պորտը նշանակում է, որ ուղին գոյություն ունի, իսկ մերժումը՝ որ հեռախոսին թույլատրվել է հայտնաբերել սարքը և այնուամենայնիվ չի կարող խոսել դրա հետ: 8008 և 8009 պորտերը սովորական հեռարձակման պորտեր են, և հավելվածը կարող է օգտագործել ուրիշները, ուստի մեկ մերժված պորտը ընդունեք որպես ակնարկ, ոչ որպես դատավճիռ: Բացառությունը և հավելվածի թույլտվությունը մնում են անկախ, քանի որ տեղական մուտքը ուղի չի ստեղծում, և ուղի ավելացնելը թույլտվություն չի տալիս: Kill switch-ը կարող է նաև գցել տեղական երթևեկությունը վերամիացումից հետո, դրա համար էլ թունելի վերադառնալուն պես բացահայտումը պետք է նորից ստուգվի:
Նվագարկումը կարող է չօգտագործել հեռախոսի կապը
Հավելվածի ղեկավարած նստաշրջանում հեռախոսը ընդունիչին տալիս է մեդիա հասցե, և ընդունիչը ներբեռնում է այն իր սեփական կապով, ուստի հեռախոսի հանրային հասցեի փոփոխությունը հոսքի համար ոչինչ չի անում: Հաշվով սահմանափակված վերնագիրը դեռ կարող է ձախողվել իր պատճառներով, և Google-ի հեռարձակման պահանջները վերաբերում են հավելվածի և սարքի համատեղելիությանը, ոչ թե ցանցային ուղուն: Հեռուստացույցն ինքը թունելով անցկացնելը առանձին կոնֆիգուրացիա է՝ իր քաղաքականության հարցերով:
Երկու նշան տարբերում են ռեժիմները: Հեռախոսի էկրանի կողպումը վերապրող հեռարձակումը հավելվածով ղեկավարվող է, որովհետև ընդունիչն ինքն է ներբեռնում. հայելագրումը, որը կանգ է առնում ուղարկողի էկրանի կողպվելիս, հեռախոսից եկող շարունակական հոսք է: Երբ բացահայտումն ու կառավարումը հաջողվում են, բայց նվագարկումը կանգ է առնում, փոխարենը նայեք ընդունիչի Wi-Fi կապին և դրա ինտերնետ ուղուն, քանի որ հեռախոսի արագության թեստը նկարագրում է հեռախոսը, ոչ թե հեռուստացույցը:
Չեղարկեք բացառությունը և նորից փորձարկեք
Յուրաքանչյուր ժամանակավոր փոփոխություն պետք է վերադարձի ուղի, և հերթականությունը կարևոր է: Հեռացրեք LAN-ի բացառությունը, նորից միացրեք թունելը, որպեսզի հաճախորդը կրկին կիրառի իր քաղաքականությունը, ապա կրկնեք բացահայտման քայլը և նշեք՝ արդյոք ընդունիչը նորից անհետանում է: Այդ հաջորդականությունը ասում է՝ աշխատանքը բացառությունն էր անում, թե միջանկյալ այլ բան է փոխվել:
# 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'Հետո ստուգեք երեք փուլերն առանձին, որովհետև մեկում հաջողությունը ոչինչ չի ասում մյուսների մասին: Ապա ստուգեք, որ հեռախոսի անկապ հավելվածները դեռ գնում են նախատեսված ուղով, քանի որ լուռ ամբողջական շրջանցման վերածված տեղական բացառությունը ավելի վատ արդյունք է, քան մեկ լրացուցիչ սեղմում պահանջող հեռարձակումը: