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 ಸಂಚಾರವನ್ನು ಅನುಮತಿಸುವುದು ಸೀಮಿತ ಪರಿಹಾರವಲ್ಲ.