ტრანსლაცია 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'
შემდეგ სამი ეტაპი ცალ-ცალკე შეამოწმეთ, რადგან ერთში წარმატება დანარჩენებზე არაფერს ამბობს. შემდეგ შეამოწმეთ, რომ ტელეფონის უკავშირო აპლიკაციები კვლავ განკუთვნილ მარშრუტს მიჰყვებიან, რადგან ჩუმად სრულ გვერდის ავლად ქცეული ლოკალური გამონაკლისი უარესი შედეგია, ვიდრე ერთი დამატებითი შეხების მოთხოვნა ტრანსლაცია.