Ĉu puŝaj sciigoj de Android ne funkcias tra VPN? Kontrolu ĉi tion

Sciigoj ĉesas alveni sur telefono, kiu alie bone retumas tra la kompania VPN. Paĝoj ŝargiĝas, la aplikaĵo malfermiĝas, kaj mesaĝoj aperas nur hejme aŭ post malŝalto de la tunelo. Por aplikaĵo konstruita sur Firebase Cloud Messaging, la puŝa kanalo estas aparta longdaŭra elira konekto, ne la HTTPS-vojo kiun la retumilo ĵus pruvis. Trapasu ĉi tiujn kontrolojn laŭorde kaj haltu ĉe la unua, kiu malsukcesas.

Konfirmu, ke la aplikaĵo vere uzas FCM

Ne ĉiu sciigo estas puŝo. Iujn planas la aplikaĵo loke, iujn oni elpetas per HTTPS, kaj iuj alvenas per vendista kanalo sen rilato al Firebase. Se la manifestaĵo kaj dependaĵoj de la aplikaĵo enhavas Firebase Messaging, ĝiaj sciigoj kutime vojaĝas per la FCM-konekto, kaj la klienta biblioteko registras la aliĝon sub antaŭvidebla etikedo.

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

Registra ĵetono en la protokolo konfirmas la transporton. Sen ĝi vi sencimigas sciigĉenon je nivelo de aplikaĵo, kaj ŝanĝoj en la fajroŝirmilo ne helpos. Ĉi tiu distingo gravas, ĉar mesaĝo liverita sed neniam montrita kaj mesaĝo neniam alveninta aspektas same al la uzanto.

Kontrolu la elirajn pordojn, ne la retejon

La FCM-aparataj konektoj estas eliraj TCP de la telefono al pordo 5228, kun 5229 kaj 5230 kiel rezervoj kaj 443 kiel lasta eblo. Fajroŝirmilo, kiu permesas 443 por retumi, povas tamen rompi la puŝon, kaj regulo permesanta la API-domajnon de la aplikaĵo ne kovras la mesaĝajn finpunktojn, ĉar tiuj estas apartaj servoj.

Ĝi estas eliraj konektoj de la telefono. Vi ne publikigas envenan pordon sur la aparato aŭ la VPN-pordego, do se iu proponas pordan plusendadon, la dezajno jam malĝustas. La samo validas por regulo, kiu malfermas unu pordon al ĉiu adreso en la interreto: limigu ĝin al la dokumentitaj celoj.

La retaj gvidlinioj de Firebase ankaŭ diras, ke la FCM-liverprotokolo ne povas esti portata trans ordinara HTTP-prokso. Do tio, ke la retumilo trapasas la kompanian retprokson, pruvas nenion pri la puŝa ingo: temas pri du malsamaj klientoj kun malsamaj vojoj.

Kontrolu la senokupajn temporandojn, kiuj mortigas la ingon

La FCM-konekto restas malfermita inter mesaĝoj, kio igas ĝin sentema al temporandoj de NAT kaj stata inspektado. La gvidlinioj de Firebase postulas almenaŭ 30 minutojn da senokupa toleremo tie, kie tiaj politikoj validas. Sesio-temporando de kvin minutoj kviete forigas la mapadon, kaj la telefono rekonektiĝas nur kiam io vekas ĝin, do mesaĝoj alvenas en amasoj aŭ tute ne.

Legu la sesian tabelon sur la fajroŝirmilo aŭ VPN-pordego kaj trovu la konekton de la telefono al 5228-5230. Komparu ĝian restantan vivon kun la dokumentita valoro. Se ĝi estas pli mallonga, altigu la temporandon por tiuj pordoj anstataŭ ŝanĝi ĉiun politikon sur la aparato.

Liverado ankaŭ dependas de tio, ĉu la finpunkta mapado postvivas transiron inter Wi-Fi kaj poŝa reto. Mapado ligita al unu interfaco povas perdiĝi ĉe la transdono eĉ kiam ambaŭ retoj permesas la pordojn.

Decidu, ĉu VPN-evito estas akceptebla

Android-VPN-klientoj povas permesi al trafiko eviti la tunelon, kaj FCM povas tiam uzi la suban reton. La puŝa kanalo restas ĉifrita, sed ĝi ne plu portas la adreson de la tunelo, do la IP-kaŝado de la VPN ne rilatas al ĝi. Temas pri politika kompromiso, ne pri misfunkcio.

Se via politiko malpermesas eviton, la tunela vojo devas porti la konekton: pordoj malfermitaj, temporandoj sufiĉe longaj, prokso ne en la vojo. Ne ekskludu kviete administritan servon kaj ne malstreĉu la ŝlosadon nur ĉar sciigoj funkcias en neadministrata reto. La VPN-ikono ne diras, kiun vojon difinita servo elektis.

Apartigu liveradon de montrado, poste testu unufoje

Permeso, kanalaj agordoj, Ne ĝenu kaj ŝaltiloj por ĉiu aplikaĵo decidas, ĉu liverita mesaĝo estos montrita. Sur Android 13 kaj pli nova la sciiga permeso estas donata dum plenumo, kaj rifuzo produktas silenton kiu aspektas precize kiel blokita pordo. Mesaĝo alveninta sed ne montrita estas prezenta problemo; traktu ĝin aparte.

Faru unu kontrolitan teston anstataŭ hazarde sendi mesaĝojn. Tenu la aparaton, konton kaj aplikaĵon fiksaj, sendu unu mesaĝon kun konata tempindiko, kaj komparu la VPN-staton kun aprobita reto sen VPN. Notu la ricevotempon en logcat kaj la montrotempon por ĉiu rulo. Se liverado malsamas sed montrado ne, la reta vojo estas la variablo; se ambaŭ samas, daŭre rigardu la aplikaĵon.

Donu al la retposedanto la pordojn, la proksan limigon, la mezuritan temporandon kaj la evitan decidon en unu noto. Malŝalti la VPN ne estas konkludo, kaj permesi la tutan Google-trafikon ne estas limigita riparo.