Njoftimet push të Android nuk punojnë me VPN? Kontrollo këto

Njoftimet ndalojnë së ardhuri në një telefon që përndryshe shfleton mirë përmes VPN-së së korporatës. Faqet e internetit ngarkohen, aplikacioni hapet, dhe mesazhet shfaqen vetëm në shtëpi ose pasi tuneli fiket. Në një aplikacion të ndërtuar mbi Firebase Cloud Messaging, kanali push është një lidhje dalëse e veçantë dhe jetëgjatë, jo rruga HTTPS që sapo vërtetoi shfletuesi. Kalo këto kontrolle me radhë dhe ndalo në të parën që dështon.

Konfirmo që aplikacioni përdor vërtet FCM

Jo çdo njoftim është push. Disa i planifikon aplikacioni lokalisht, disa kërkohen përmes HTTPS-it, dhe disa vijnë përmes një kanali furnizuesi që nuk ka lidhje me Firebase. Nëse manifesti dhe varësitë e aplikacionit përfshijnë Firebase Messaging, njoftimet e tij zakonisht udhëtojnë përmes lidhjes FCM, dhe biblioteka e klientit regjistron regjistrimin nën një etiketë të parashikueshme.

adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebase

Një token regjistrimi në log konfirmon transportin. Pa të, po korrigjon një tubacion njoftimesh në nivel aplikacioni, dhe ndryshimet e murit të zjarrit nuk do të ndihmojnë. Ky dallim ka rëndësi sepse një mesazh i dorëzuar por i pashfaqur kurrë dhe një mesazh që nuk arrin kurrë duken njësoj për përdoruesin.

Kontrollo portat dalëse, jo faqen e internetit

Lidhjet e pajisjeve me FCM janë TCP të nisura nga pajisja drejt portës 5228, me 5229 dhe 5230 si rezervë dhe 443 si zgjidhja e fundit. Një mur i zjarrit që lejon 443 për shfletim mund të prishë prapë push-in, dhe një rregull që lejon domenin API të një aplikacioni nuk mbulon pikat fundore të mesazheve, të cilat janë shërbime të veçanta.

Këto janë lidhje dalëse nga telefoni. Nuk publikoni një port hyrës në pajisje ose në portën VPN, kështu që nëse dikush sugjeron përcjellje porti, dizajni tashmë ka dështuar. E njëjta gjë vlen për një rregull që hap një port për çdo adresë në internet: kufizoje te destinacionet e dokumentuara.

Udhëzimet e rrjetit të Firebase pohon gjithashtu se protokolli i dorëzimit të FCM nuk mund të transportohet përmes një proxy HTTP të zakonshëm. Prandaj fakti që një shfletues funksionon përmes proxy-t të internetit të korporatës nuk provon asgjë për socket-in push: janë dy klientë të ndryshëm me rrugë të ndryshme.

Kontrollo afatet e papunësisë që vrasin socket-in

Lidhja FCM qëndron e hapur mes mesazheve, gjë që e bën të ndjeshme ndaj afateve të NAT-it dhe të inspektimit me gjendje. Udhëzimet e Firebase kërkojnë të paktën 30 minuta tolerancë ndaj papunësisë aty ku zbatohen politika të tilla. Një afat sesioni prej pesë minutash e heq në heshtje hartëzimin, dhe telefoni rilidhet vetëm kur diçka e zgjon, prandaj mesazhet vijnë me valë ose nuk vijnë fare.

Lexo tabelën e sesioneve në murin e zjarrit ose në portën VPN dhe gjej lidhjen e telefonit drejt 5228-5230. Krahaso jetëgjatësinë e mbetur me vlerën e dokumentuar. Nëse është më e shkurtër, rrit afatin për ato porta në vend që të ndryshosh të gjitha politikat në pajisje, sepse një ndryshim global i afatit është i vështirë për t'u justifikuar dhe edhe më i vështirë për t'u anuluar.

Dorëzimi push varet edhe nga mbijetesa e hartëzimit të pikës fundore gjatë roaming-ut mes Wi-Fi dhe rrjetit celular. Një hartëzim i lidhur me një ndërfaqe të vetme mund të hidhet gjatë kalimit edhe kur të dy rrjetet i lejojnë portat.

Vendos nëse anashkalimi i VPN-së është i pranueshëm

Klientët VPN të Android mund të lejojnë trafikun të anashkalojë tunelin, dhe FCM mund të përdorë rrjetin nën të kur ai anashkalim lejohet. Në atë rast kanali push mbetet i kriptuar, por nuk mban më adresën e tunelit, prandaj maskimi IP i VPN-së nuk zbatohet për të. Është një kompromis politikash, jo defekt.

Nëse politika jote ndalon anashkalimin, rruga e tunelit duhet ta mbajë lidhjen: porta të hapura, afate mjaftueshëm të gjata, proxy jashtë rrugës. Mos e përjashto në heshtje një shërbim të menaxhuar dhe mos e liro bllokimin vetëm sepse njoftimet punojnë në një rrjet të pamenaxhuar. Ikona e VPN-së nuk tregon se cilën rrugë zgjodhi një shërbim i caktuar

Ndaj dorëzimin nga shfaqja, pastaj testo një herë

Leja, cilësimet e kanalit, Mos shqetëso dhe çelësat për çdo aplikacion vendosin nëse një mesazh i dorëzuar shfaqet. Në Android 13 e më pas leja e njoftimeve jepet në kohë ekzekutimi, dhe një leje e refuzuar prodhon heshtje që duket saktësisht si një port i bllokuar. Një mesazh që mbërriti por nuk u shfaq është problem paraqitjeje; trajtoje veçmas.

Bëj një test të kontrolluar në vend që të dërgosh mesazhe rastësisht. Mbaj pajisjen, llogarinë dhe aplikacionin të pandryshuara, dërgo një mesazh të vetëm me një vulë kohore të njohur dhe krahaso gjendjen me VPN me një rrjet pa VPN të miratuar. Regjistro kohën e marrjes në logcat dhe kohën e shfaqjes për çdo ekzekutim. Nëse dorëzimi ndryshon por shfaqja jo, rruga e rrjetit është variabla; nëse të dyja janë identike, vazhdo të shikosh aplikacionin.

Jepi pronarit të rrjetit portat, kufizimin e proxy-t, afatin e matur dhe vendimin për anashkalimin në një shënim të vetëm. «Fike VPN-në» nuk është gjetje, dhe lejimi i gjithë trafikut të Google nuk është rregullim i kufizuar.