Android-ын push мэдэгдэл VPN-тэй ажиллахгүй байна уу? Эдгээрийг шалгаарай
FCM нь 5228-5230 портууд дээр өөрийн гарах холболтыг хадгалдаг. Мэдэгдлийн тохиргоонд хүрэхээс өмнө прокси дүрэм, NAT-ын хугацаа, VPN-ийг тойрох эсэхийг шалгана уу.
Бусад зүйлд корпорацийн VPN-ээр сайн ажилладаг утсан дээр мэдэгдэл ирэхээ болино. Вэб хуудсууд ачаалагдаж, апп нээгддэг ч мессежүүд зөвхөн гэртээ эсвэл туннелийг унтраасны дараа л гарч ирдэг. Firebase Cloud Messaging дээр бүтээсэн апп-д push суваг нь тусдаа, урт хугацааны гарах холболт бөгөөд хөтөч дөнгөж нотолсон HTTPS зам биш юм. Эдгээр шалгалтыг дарааллаар нь хийж, эхний бүтэлгүйтсэн дээр зогсоорой.
Апп үнэхээр FCM ашиглаж байгаа эсэхийг баталгаажуулна уу
Мэдэгдэл бүр push биш. Заримыг апп өөрөө локалаар төлөвлөдөг, заримыг 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-ыг зөвшөөрдөг галт хана push-ыг эвдэж болох бөгөөд апп-ын 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 проксигоор дамжуулж болохгүй гэж заасан. Иймд хөтөч корпорацийн вэб проксигоор ажиллаж байгаа нь push сокетын талаар юу ч нотлохгүй: эдгээр нь өөр өөр замтай хоёр өөр клиент юм.
Сокетыг устгадаг идэвхгүй байдлын хугацааг шалгана уу
FCM холболт мессежүүдийн хооронд нээлттэй үлддэг нь түүнийг NAT болон төлөв шалгах хугацаанд мэдрэмтгий болгодог. Firebase-н заавар ийм бодлого үйлчлэх газарт дор хаяж 30 минутын идэвхгүй байдлын тэсвэрлэхийг шаарддаг. Таван минутын сессийн хугацаа зураглалыг чимээгүй арилгаж, утас ямар нэгэн зүйл сэрээх үед л дахин холбогддог тул мессежүүд бөөгнөрч ирдэг эсвэл огт ирдэггүй.
Галт хана эсвэл VPN гарц дээрх сессийн хүснэгтийг уншиж, утасны 5228-5230 руу чиглэсэн холболтыг олоорой. Үлдсэн насжилтыг баримтжуулсан утгатай харьцуулна уу. Хэрэв богино бол төхөөрөмж дээрх бүх бодлогыг өөрчлөхийн оронд тэдгээр портын хугацааг нэмэгдүүлээрэй, учир нь глобал хугацааны өөрчлөлтийг зөвтгөхөд хэцүү, буцаахад бүр хэцүү.
Push хүргэлт нь мөн төгсгөлийн цэгийн зураглал Wi-Fi болон үүрэн сүлжээний хооронд роуминг хийхэд хадгалагдахаас хамаарна. Нэг интерфэйстэй холбогдсон зураглал нь хоёр сүлжээ портыг зөвшөөрч байсан ч шилжилтийн үед хасагдаж болно.
VPN-ийг тойрохыг зөвшөөрөх эсэхийг шийдээрэй
Android VPN клиентүүд урсгалыг туннелийг тойруулахыг зөвшөөрч болох ба энэ тойролтыг зөвшөөрсөн үед FCM доорх сүлжээг ашиглаж болно. Энэ тохиолдолд push суваг шифрлэгдсэн хэвээр байх боловч туннелийн хаягийг дахин зөөхгүй тул VPN-ийн IP далдлалт түүнд үйлчлэхгүй. Энэ бол бодлогын буулт, гэмтэл биш.
Хэрэв таны бодлого тойрохыг хоригловол туннелийн зам холболтыг зөөх ёстой: портууд нээлттэй, хугацаа хангалттай урт, прокси замд саад болохгүй. Удирддаг үйлчилгээг чимээгүй хасаж болохгүй, мэдэгдэл удирдлагагүй сүлжээнд ажиллаж байгаа учраас түгжээг сулруулж болохгүй. VPN-ийн дүрс аль үйлчилгээ ямар зам сонгосныг хэлэхгүй
Хүргэлтийг харуулалтаас тусгаарлаж, нэг удаа туршина уу
Зөвшөөрөл, сувгийн тохиргоо, Бүү саад бол жана апп тус бүрийн унтраалга нь хүргэгдсэн мессеж харагдах эсэхийг шийддэг. Android 13 ба түүнээс хойш мэдэгдлийн зөвшөөрөл нь ажиллах үеийн олголт бөгөөд татгалзсан олголт нь хаагдсан порттой яг адил харагдах чимээгүй байдлыг үүсгэдэг. Ирсэн боловч харагдаагүй мессеж нь харуулалтын асуудал; түүнийг тусад нь авч үзээрэй.
Мессежийг санамсаргүй илгээхийн оронд нэг хяналттай туршилт хий. Төхөөрөмж, бүртгэл, апп-ыг тогтмол байлгаж, мэдэгдэж буй цагийн тэмдэгтэй нэг мессеж илгээж, VPN-тэй нөхцөл байдлыг зөвшөөрсөн VPN-гүй сүлжээтэй харьцуул. Ажиллагаа бүрд logcat-ийн хүлээн авах цаг болон харуулах цагийг бүртгэ. Хэрэв хүргэлт ялгаатай боловч харуулалт биш бол сүлжээний зам хувьсагч; хэрэв хоёулаа ижил бол апп-ыг үргэлжлүүлэн ажигла.
Сүлжээний эзэмшигчид портууд, прокси-гийн хязгаарлалт, хэмжсэн хугацаа, тойролтын шийдвэрийг нэг тэмдэглэлд өг. «VPN-ийг унтраа» гэдэг нь олдвор биш, бүх Google урсгалыг зөвшөөрөх нь хязгаарлагдмал засвар биш.