Android પુશ સૂચનાઓ VPN સાથે કામ કરતી નથી? આ બાબતો તપાસો
FCM પોતાનું આઉટબાઉન્ડ કનેક્શન 5228-5230 પોર્ટ પર રાખે છે. સૂચના સેટિંગ્સ બદલતા પહેલા પ્રોક્સી નિયમ, NAT ટાઇમઆઉટ અને VPN બાયપાસ તપાસો.
એવા ફોન પર સૂચનાઓ આવવાનું બંધ થઈ જાય છે જે બાકીના કિસ્સામાં કોર્પોરેટ VPN દ્વારા સરળતાથી બ્રાઉઝ કરે છે. વેબ પૃષ્ઠો લોડ થાય છે, એપ ખૂલે છે, અને સંદેશા ફક્ત ઘરે અથવા ટનલ બંધ કર્યા પછી દેખાય છે. Firebase Cloud Messaging પર બનેલી એપમાં, પુશ ચેનલ એ અલગ, લાંબા સમય ચાલતું આઉટબાઉન્ડ કનેક્શન છે, બ્રાઉઝરે હમણાં સાબિત કરેલો HTTPS રસ્તો નહીં. આ તપાસો ક્રમમાં કરો અને પહેલી નિષ્ફળ તપાસ પર અટકો.
ખાતરી કરો કે એપ ખરેખર FCM વાપરે છે
દરેક સૂચના પુશ નથી. કેટલીક એપ સ્થાનિક રીતે શેડ્યૂલ કરે છે, કેટલીક HTTPS દ્વારા મેળવવામાં આવે છે, અને કેટલીક વેન્ડર ચેનલ દ્વારા આવે છે જેનો Firebase સાથે કોઈ સંબંધ નથી. જો એપનું મેનિફેસ્ટ અને ડિપેન્ડન્સીમાં Firebase Messaging હોય, તો તેની સૂચનાઓ સામાન્ય રીતે FCM કનેક્શન પર જાય છે, અને ક્લાયન્ટ લાઇબ્રેરી નોંધણીને અનુમાનિત ટેગ હેઠળ લોગ કરે છે.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebaseલોગમાં નોંધણી ટોકન પરિવહનની પુષ્ટિ કરે છે. તેના વિના, તમે એપ-સ્તરીય સૂચના પાઇપલાઇન ડિબગ કરી રહ્યા છો, અને ફાયરવોલ ફેરફારો મદદ નહીં કરે. આ ભેદ મહત્વનો છે કારણ કે પહોંચાડાયેલો પણ ક્યારેય ન દેખાતો સંદેશ અને ક્યારેય ન આવતો સંદેશ વપરાશકર્તાને એકસમાન લાગે છે.
આઉટબાઉન્ડ પોર્ટ તપાસો, વેબસાઇટ નહીં
FCM ઉપકરણ કનેક્શન એ ઉપકરણથી શરૂ થતા TCP છે જે પોર્ટ 5228 પર જાય છે, 5229 અને 5230 બેકઅપ તરીકે અને 443 છેલ્લા વિકલ્પ તરીકે. બ્રાઉઝિંગ માટે 443 ને મંજૂરી આપતો ફાયરવોલ પણ પુશ તોડી શકે છે, અને એપના 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 પ્રોક્સી પર લઈ જઈ શકાતો નથી. તેથી કોર્પોરેટ વેબ પ્રોક્સી દ્વારા બ્રાઉઝરનું કામ કરવું પુશ સોકેટ વિશે કંઈ સાબિત કરતું નથી: તે બે અલગ ક્લાયન્ટ છે જેમના રસ્તા અલગ છે.
સોકેટને બંધ કરતા નિષ્ક્રિય ટાઇમઆઉટ તપાસો
FCM કનેક્શન સંદેશાઓ વચ્ચે ખુલ્લું રહે છે, જે તેને NAT અને સ્ટેટફુલ-ઇન્સ્પેક્શન ટાઇમઆઉટ પ્રત્યે સંવેદનશીલ બનાવે છે. Firebase નું માર્ગદર્શન જ્યાં આવી નીતિઓ લાગુ પડે છે ત્યાં ઓછામાં ઓછા 30 મિનિટની નિષ્ક્રિય સહનશીલતા માંગે છે. પાંચ મિનિટનો સેશન ટાઇમઆઉટ મેપિંગને ચૂપચાપ દૂર કરે છે, અને ફોન ફરી ત્યારે જ જોડાય છે જ્યારે કંઈક તેને જગાડે, તેથી સંદેશા જથ્થામાં આવે છે અથવા આવતા જ નથી.
ફાયરવોલ કે VPN ગેટવે પરનું સેશન ટેબલ વાંચો અને ફોનનું 5228-5230 સાથેનું કનેક્શન શોધો. તેની બાકી રહેલી આયુને દસ્તાવેજી મૂલ્ય સાથે સરખાવો. જો તે ટૂંકી હોય, તો ઉપકરણ પરની બધી નીતિઓ બદલવાને બદલે તે પોર્ટ માટે ટાઇમઆઉટ વધારો, કારણ કે વૈશ્વિક ટાઇમઆઉટ ફેરફારને વાજબી ઠેરવવો મુશ્કેલ છે અને પાછો ફેરવવો વધુ મુશ્કેલ.
પુશ ડિલિવરી એના પર પણ આધાર રાખે છે કે એન્ડપોઇન્ટ મેપિંગ Wi-Fi અને મોબાઇલ વચ્ચેના રોમિંગમાં ટકી રહે. એક ઇન્ટરફેસ સાથે જોડાયેલું મેપિંગ હેન્ડઓવર વખતે ખસી શકે છે, ત્યારે પણ જ્યારે બંને નેટવર્ક પોર્ટને મંજૂરી આપે છે.
નક્કી કરો કે VPN બાયપાસ સ્વીકાર્ય છે કે નહીં
Android VPN ક્લાયન્ટ ટ્રાફિકને ટનલ છોડવા દઈ શકે છે, અને જ્યારે આ બાયપાસ મંજૂર હોય ત્યારે FCM અંતર્ગત નેટવર્ક વાપરી શકે છે. તે સ્થિતિમાં પુશ ચેનલ એન્ક્રિપ્ટેડ રહે છે, પણ હવે ટનલનું સરનામું લઈ જતી નથી, તેથી VPNનું IP માસ્કિંગ તેના પર લાગુ પડતું નથી. તે નીતિનો વેપાર છે, ખામી નહીં.
જો તમારી નીતિ બાયપાસ પર પ્રતિબંધ મૂકે છે, તો ટનલ માર્ગે કનેક્શન લઈ જવું પડશે: પોર્ટ ખુલ્લા, ટાઇમઆઉટ પૂરતા લાંબા, પ્રોક્સી રસ્તામાં નહીં. મેનેજ્ડ સેવાને ચૂપચાપ બહાર ન રાખો અને ફક્ત એટલા માટે લોકડાઉન ઢીલું ન કરો કે સૂચનાઓ બિન-મેનેજ્ડ નેટવર્ક પર કામ કરે છે. VPN આઇકન એ નથી કહેતું કે કોઈ સેવાએ કયો રસ્તો પસંદ કર્યો
ડિલિવરીને ડિસ્પ્લેથી અલગ કરો, પછી એક વાર પરીક્ષણ કરો
પરવાનગી, ચેનલ સેટિંગ્સ, પરેશાન ન કરો અને પ્રતિ-એપ ટોગલ નક્કી કરે છે કે પહોંચાડાયેલો સંદેશ દેખાશે કે નહીં. Android 13 અને તે પછીની આવૃત્તિઓમાં સૂચના પરવાનગી રનટાઇમ પ્રદાન છે, અને નકારેલી પરવાનગી એવી ચૂપકીદી પેદા કરે છે જે બ્લોક્ડ પોર્ટ જેવી જ દેખાય છે. આવેલો પણ ન દેખાયેલો સંદેશ પ્રસ્તુતિની સમસ્યા છે; તેને અલગથી સંભાળો.
સંદેશા અવ્યવસ્થિત રીતે મોકલવાને બદલે એક નિયંત્રિત પરીક્ષણ કરો. ઉપકરણ, ખાતું અને એપ સ્થિર રાખો, જાણીતા ટાઇમસ્ટેમ્પ સાથે એક જ સંદેશ મોકલો, અને VPN સ્થિતિને મંજૂર બિન-VPN નેટવર્ક સાથે સરખાવો. દરેક રન માટે logcat પ્રાપ્તિ સમય અને ડિસ્પ્લે સમય નોંધો. જો ડિલિવરી અલગ હોય પણ ડિસ્પ્લે નહીં, તો નેટવર્ક માર્ગ ચલ છે; જો બંને સમાન હોય, તો એપ તરફ જોતા રહો.
નેટવર્ક માલિકને પોર્ટ, પ્રોક્સી મર્યાદા, માપેલ ટાઇમઆઉટ અને બાયપાસ નિર્ણય એક જ નોંધમાં આપો. «VPN બંધ કરો» એ કોઈ શોધ નથી, અને બધો Google ટ્રાફિક મંજૂર કરવો એ મર્યાદિત ઉપાય નથી.