Android push pranešimai neveikia su VPN? Patikrinkite tai

Pranešimai nustoja ateiti telefone, kuris kitu atveju puikiai naršo per įmonės VPN. Tinklalapiai įkeliami, programėlė atsidaro, o žinutės pasirodo tik namuose arba išjungus tunelį. Programėlėje, sukurtoje su Firebase Cloud Messaging, push kanalas yra atskira ilgaamžė išeinanti jungtis, o ne HTTPS kelias, kurį naršyklė ką tik įrodė. Atlikite šiuos patikrinimus iš eilės ir sustokite ties pirmuoju, kuris nepavyksta.

Patvirtinkite, kad programėlė tikrai naudoja FCM

Ne kiekvienas pranešimas yra push. Kai kuriuos programėlė suplanuoja vietoje, kiti gaunami per HTTPS, o dar kiti ateina tiekėjo kanalu, neturinčiu nieko bendra su Firebase. Jei programėlės manifestas ir priklausomybės apima Firebase Messaging, jos pranešimai paprastai keliauja FCM jungtimi, o kliento biblioteka registraciją įrašo po nuspėjamu žymekliu.

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

Registracijos raktas žurnale patvirtina perdavimą. Be jo jūs derinate programėlės lygio pranešimų grandinę, o užkardos pakeitimai nepadės. Šis skirtumas svarbus, nes pristatytas, bet niekada neparodomas pranešimas ir niekada neatvykstantis pranešimas vartotojui atrodo vienodai.

Tikrinkite išeinančius portus, o ne svetainę

FCM įrenginio jungtys yra įrenginio inicijuojami TCP į 5228 portą, 5229 ir 5230 kaip atsarginiai, o 443 kaip paskutinė priemonė. Užkarda, leidžianti 443 naršymui, vis tiek gali sugadinti push, o taisyklė, leidžianti programėlės API domeną, neapima pranešimų siuntimo galinių taškų, kurie yra atskiros paslaugos.

Tai iš telefono išeinančios jungtys. Jūs neskelbiate įeinančio porto įrenginyje ar VPN šliuze, tad jei kas nors siūlo porto peradresavimą, projektas jau neteisingas. Tas pats galioja taisyklei, kuri atveria vieną portą visiems interneto adresams: apribokite ją dokumentuotais tikslais.

Firebase tinklo rekomendacijos taip pat teigia, kad FCM pristatymo protokolo negalima perduoti per įprastą HTTP tarpinį serverį. Todėl tai, kad naršyklė veikia per įmonės interneto tarpinį serverį, nieko neįrodo apie push lizdą: tai du skirtingi klientai su skirtingais keliais.

Patikrinkite neveiklumo laiko limitus, kurie užmuša lizdą

FCM jungtis lieka atidaryta tarp žinučių, todėl ji jautri NAT ir būsenos tikrinimo laiko limitams. Firebase rekomendacijos prašo bent 30 minučių neveiklumo tolerancijos ten, kur tokia politika galioja. Penkių minučių sesijos laiko limitas tyliai pašalina susiejimą, o telefonas prisijungia iš naujo tik kai kažkas jį pažadina, todėl žinutės ateina pliūpsniais arba visai neateina.

Perskaitykite sesijų lentelę užkardoje ar VPN šliuze ir raskite telefono jungtį į 5228-5230. Palyginkite jos likusį gyvavimo laiką su dokumentuota verte. Jei jis trumpesnis, padidinkite tų portų laiko limitą, o ne keiskite visas įrenginio politikas, nes pasaulinį laiko limito pakeitimą sunku pagrįsti ir dar sunkiau atšaukti.

Push pristatymas taip pat priklauso nuo to, ar galinio taško susiejimas išliks pereinant tarp Wi-Fi ir mobiliųjų tinklų. Susiejimas, susietas su viena sąsaja, gali būti atmestas perėjimo metu net kai abu tinklai leidžia portus.

Nuspręskite, ar VPN apėjimas yra priimtinas

Android VPN klientai gali leisti srautui apeiti tunelį, o FCM gali naudoti pagrindinį tinklą, kai toks apėjimas leidžiamas. Tuo atveju push kanalas lieka šifruotas, bet nebeperduoda tunelio adreso, todėl VPN IP maskavimas jam netaikomas. Tai politikos kompromisas, o ne gedimas.

Jei jūsų politika draudžia apėjimą, tunelio kelias turi perduoti jungtį: portai atidaryti, laiko limitai pakankamai ilgi, tarpinis serveris netrukdo. Netylomis neišskirkite valdomos paslaugos ir nesusilpninkite užraktų vien todėl, kad pranešimai veikia nevaldomame tinkle. VPN piktograma neparodo, kokį kelią pasirinko konkreti paslauga

Atskirkite pristatymą nuo rodymo, tada išbandykite vieną kartą

Leidimas, kanalo nustatymai, Netrukdyti ir jungikliai kiekvienai programėlei sprendžia, ar pristatytas pranešimas bus rodomas. Android 13 ir naujesnėse versijose pranešimų leidimas suteikiamas vykdymo metu, o atmestas leidimas sukuria tylą, kuri atrodo lygiai kaip užblokuotas portas. Pranešimas, kuris atėjo, bet nebuvo parodytas, yra pateikimo problema; spręskite ją atskirai.

Atlikite vieną kontroliuojamą testą, o ne siųskite žinučių bet kaip. Laikykite įrenginį, paskyrą ir programėlę nekintančius, išsiųskite vieną žinutę su žinomu laiko žymekliu ir palyginkite VPN būseną su patvirtintu tinklu be VPN. Užrašykite gavimo laiką logcat ir rodymo laiką kiekvienam paleidimui. Jei pristatymas skiriasi, o rodymas ne, tinklo kelias yra kintamasis; jei abu vienodi, toliau žiūrėkite į programėlę.

Perduokite tinklo savininkui portus, tarpinio serverio apribojimą, išmatuotą laiko limitą ir apėjimo sprendimą vienoje pastaboje. «Išjunk VPN» nėra išvada, o viso Google srauto leidimas nėra tikslinga pataisa.