Android-ის push შეტყობინებები VPN-ით არ მუშაობს? შეამოწმეთ ეს
FCM ინარჩუნებს საკუთარ გამავალ კავშირს 5228-5230 პორტებზე. შეტყობინებების პარამეტრებამდე შეამოწმეთ proxy-ს წესი, NAT-ის ვადა და VPN-ის გვერდის ავლა.
შეტყობინებები წყვეტს მოსვლას იმ ტელეფონზე, რომელიც სხვა მხრივ კორპორატიული VPN-ით კარგად ბრაუზერდება. ვებ გვერდები იტვირთება, აპი იხსნება, ხოლო შეტყობინებები მხოლოდ სახლში ან გვირაბის გამორთვის შემდეგ ჩნდება. Firebase Cloud Messaging-ზე აგებულ აპში push არხი ცალკე, ხანგრძლივი გამავალი კავშირია და არა ის HTTPS მარშრუტი, რომელიც ბრაუზერმა ახლახან დაამტკიცა. გაიარეთ ეს შემოწმებები თანმიმდევრობით და გაჩერდით პირველზე, რომელიც ვერ გაივლის.
დაადასტურეთ, რომ აპი ნამდვილად იყენებს FCM-ს
ყოველი შეტყობინება push არ არის. ზოგს აპი ადგილობრივად გეგმავს, ზოგი HTTPS-ით იკითხება, ზოგიც მოდის მომწოდებლის არხით, რომელსაც Firebase-თან საერთო არაფერი აქვს. თუ აპის manifest და დამოკიდებულებები მოიცავს Firebase Messaging-ს, მისი შეტყობინებები ჩვეულებრივ FCM კავშირით გადადის, და კლიენტის ბიბლიოთეკა რეგისტრაციას პროგნოზირებადი ტეგის ქვეშ აღრიცხავს.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebaseლოგში რეგისტრაციის token ადასტურებს გადაცემას. მის გარეშე თქვენ აპის დონის შეტყობინებების მილსადენს ამუშავებთ და firewall-ის ცვლილებები არ დაგეხმარებათ. ეს განსხვავება მნიშვნელოვანია, რადგან მიწოდებული, მაგრამ არასდროს ნაჩვენები შეტყობინება და არასდროს მომსვლელი შეტყობინება მომხმარებლისთვის ერთნაირად გამოიყურება.
შეამოწმეთ გამავალი პორტები და არა ვებსაიტი
FCM მოწყობილობის კავშირები მოწყობილობიდან წამოსული TCP არის 5228 პორტისკენ, 5229 და 5230 სარეზერვო, ხოლო 443 უკანასკნელ საშუალებად. firewall, რომელიც ბრაუზინგისთვის 443-ს უშვებს, მაინც შეიძლება push-ს ამტვრიოს, და აპის API დომენის დამტკიცება არ ფარავს შეტყობინებათა ბოლო წერტილებს, რომლებიც ცალკე სერვისებია.
ეს ტელეფონიდან გამავალი კავშირებია. თქვენ არ აქვეყნებთ შემავალ პორტს მოწყობილობაზე ან VPN კარიბჭეზე, ამიტომ თუ ვინმე პორტის გადამისამართებას გთავაზობთ, დიზაინი უკვე არასწორია. იგივე ეხება წესს, რომელიც ერთ პორტს ინტერნეტის ყველა მისამართისთვის ხსნის: შეზღუდეთ ის დოკუმენტირებული დანიშნულებებით.
| Port | Role | What to verify |
|---|---|---|
| 5228 | Primary FCM connection | Outbound allowed and session state kept |
| 5229, 5230 | Fallback ports | Often missing from hand-written allowlists |
| 443 | Last-resort fallback | Works only if the client actually falls back |
| HTTP proxy | Not a supported FCM transport | Proxy exclusion or bypass, not a port rule |
Firebase-ის ქსელური სახელმძღვანელო ასევე ამბობს, რომ FCM-ის მიწოდების პროტოკოლი ჩვეულებრივი HTTP proxy-ით ვერ გადაიცემა. ამიტომ ბრაუზერის მუშაობა კორპორატიული ვებ proxy-ით push socket-ის შესახებ არაფერს ამტკიცებს: ეს ორი სხვადასხვა კლიენტია განსხვავებული მარშრუტებით.
შეამოწმეთ უმოქმედობის ვადები, რომლებიც socket-ს კლავს
FCM კავშირი შეტყობინებებს შორის ღია რჩება, რაც მას NAT-ისა და მდგომარეობითი შემოწმების ვადების მიმართ მგრძნობიარეს ხდის. Firebase-ის სახელმძღვანელო ითხოვს მინიმუმ 30 წუთის უმოქმედობის შეწყნარებას იქ, სადაც ასეთი პოლიტიკა მოქმედებს. ხუთწუთიანი სესიის ვადა ჩუმად შლის რუკებას და ტელეფონი მხოლოდ მაშინ უკავშირდება ხელახლა, როცა რაღაც აღვიძებს, ამიტომ შეტყობინებები პორციებად მოდის ან საერთოდ არ მოდის.
წაიკითხეთ სესიების ცხრილი firewall-ზე ან VPN კარიბჭეზე და იპოვეთ ტელეფონის კავშირი 5228-5230-თან. შეადარეთ მისი დარჩენილი სიცოცხლე დოკუმენტირებულ მნიშვნელობას. თუ უფრო მოკლეა, გაზარდეთ ვადა ამ პორტებისთვის და არა მოწყობილობის ყველა პოლიტიკა შეცვალეთ, რადგან გლობალური ვადის ცვლილება ძნელად დასაბუთებადია და კიდევ უფრო ძნელად გასაუქმებელი.
push-ის მიწოდება ასევე დამოკიდებულია იმაზე, გადაურჩება თუ არა ბოლო წერტილის რუკება Wi-Fi-სა და მობილურ ქსელს შორის როუმინგს. ერთ ინტერფეისზე მიბმული რუკება შეიძლება დაიკარგოს გადაცემისას მაშინაც, როცა ორივე ქსელი პორტებს უშვებს.
გადაწყვიტეთ, მისაღებია თუ არა VPN-ის გვერდის ავლა
Android VPN კლიენტებს შეუძლიათ დაუშვან ტრაფიკის გვირაბის გვერდის ავლა, და FCM-მა შეიძლება გამოიყენოს ქვედა ქსელი, როცა ეს გვერდის ავლა დაშვებულია. ამ შემთხვევაში push არხი დაშიფრული რჩება, მაგრამ აღარ ატარებს გვირაბის მისამართს, ამიტომ VPN-ის IP ნიღაბი მასზე არ ვრცელდება. ეს პოლიტიკური კომპრომისია და არა გაუმართაობა.
თუ თქვენი პოლიტიკა კრძალავს გვერდის ავლას, გვირაბის მარშრუტმა უნდა ატაროს კავშირი: პორტები ღია, ვადები საკმარისად გრძელი, proxy გზაში არ არის. ნუ გამორიცხავთ ჩუმად მართულ სერვისს და ნუ მოხსნით ბლოკირებას მხოლოდ იმიტომ, რომ შეტყობინებები არამართულ ქსელში მუშაობს. VPN-ის ხატულა არ გეუბნებათ, რომელი მარშრუტი აირჩია კონკრეტულმა სერვისმა
გამოყავით მიწოდება ჩვენებისგან და ერთხელ გამოსცადეთ
ნებართვა, არხის პარამეტრები, ნუ შემაწუხებთ და თითოეული აპის გადამრთველები წყვეტენ, გამოჩნდება თუ არა მიწოდებული შეტყობინება. Android 13-სა და უფრო ახალში შეტყობინებების ნებართვა გაშვების დროს გაიცემა, და უარყოფილი ნებართვა ქმნის სიჩუმეს, რომელიც ზუსტად დაბლოკილი პორტის მსგავსია. მოსული, მაგრამ არნაჩვენები შეტყობინება ჩვენების პრობლემაა; ცალკე განიხილეთ.
გააკეთეთ ერთი კონტროლირებადი ცდა შეტყობინებების შემთხვევით გაგზავნის ნაცვლად. დააფიქსირეთ მოწყობილობა, ანგარიში და აპი, გაგზავნეთ ერთი შეტყობინება ცნობილი დროის ნიშნით და შეადარეთ VPN-ის მდგომარეობა დამტკიცებულ VPN-ის გარეშე ქსელს. ჩაწერეთ logcat-ის მიღების დრო და ჩვენების დრო ყოველი გაშვებისთვის. თუ მიწოდება განსხვავდება, ხოლო ჩვენება არა, ქსელური მარშრუტია ცვლადი; თუ ორივე ერთნაირია, განაგრძეთ აპის ყურება.
მიეცით ქსელის პატრონს პორტები, proxy-ს შეზღუდვა, გაზომილი ვადა და გვერდის ავლის გადაწყვეტილება ერთ ჩანაწერში. «გამორთე VPN» აღმოჩენა არ არის, და ყველა Google ტრაფიკის დაშვება შეზღუდული გამოსწორება არ არის.