Androidi tõuketeated ei tööta VPN-iga? Kontrolli neid asju

Teated lakkavad saabumast telefonis, mis muidu liigub ettevõtte VPN-i kaudu probleemideta. Veebilehed laadivad, rakendus avaneb ja sõnumid ilmuvad ainult kodus või pärast tunnelist väljalülitamist. Firebase Cloud Messagingul põhinevas rakenduses on tõukekanal eraldi pikaajaline väljuv ühendus, mitte HTTPS-tee, mida brauser äsja tõestas. Käi need kontrollid järjekorras läbi ja peatu esimesel, mis ebaõnnestub.

Kinnita, et rakendus kasutab tõesti FCM-i

Iga teade ei ole tõuge. Mõned ajastab rakendus kohapeal, mõned küsitakse HTTPS-i kaudu ja mõned saabuvad tarnija kanali kaudu, millel pole Firebase'iga midagi pistmist. Kui rakenduse manifest ja sõltuvused sisaldavad Firebase Messagingut, liiguvad selle teated tavaliselt FCM-i ühenduse kaudu ja klienditeek logib registreerimise etteaimatava sildi all.

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

Registreerimistõend logis kinnitab transpordi. Ilma selleta silud rakenduse tasandi teavituste torustikku ja tulemüüri muudatused ei aita. See vahe on oluline, sest kohale toimetatud sõnum, mida kunagi ei näidata, ja sõnum, mis kunagi ei saabu, näevad kasutaja jaoks ühesugused välja.

Kontrolli väljuvaid porte, mitte veebisaiti

FCM-i seadmeühendused on seadmest algatatud TCP pordile 5228, varuvariantidena 5229 ja 5230 ning viimase abinõuna 443. Tulemüür, mis lubab sirvimiseks 443, võib tõuke ikkagi katki teha, ja reegel, mis lubab rakenduse API-domeeni, ei kata sõnumsidesõlmi, mis on eraldi teenused.

Need on telefonist väljuvad ühendused. Sa ei avalda sissetulevat porti ei seadmes ega VPN-i lüüsis, nii et kui keegi pakub pordi edasijuhtimist, on projekt juba valesti läinud. Sama kehtib reegli kohta, mis avab ühe pordi kõikidele internetiaadressidele: piira see dokumenteeritud sihtkohtadega.

Firebase'i võrgujuhis ütleb samuti, et FCM-i kohaletoimetamisprotokolli ei saa tavalise HTTP-puhverserveri kaudu kanda. See, et brauser töötab ettevõtte veebipuhverserveri kaudu, ei tõesta seega tõukepesa kohta midagi: need on kaks erinevat klienti erinevate teedega.

Kontrolli jõudeaegu, mis pesa sulgevad

FCM-i ühendus jääb sõnumite vahel avatuks, mis teeb selle tundlikuks NAT-i ja olekupõhise kontrolli aegumiste suhtes. Firebase'i juhis nõuab vähemalt 30 minutit jõudeaja talumist, kus sellised põhimõtted kehtivad. Viie minuti sessiooni aegumine eemaldab vastenduse vaikselt ja telefon ühendub uuesti alles siis, kui miski selle äratab, nii et sõnumid saabuvad pursetena või üldse mitte.

Loe tulemüüri või VPN-i lüüsi sessioonitabelit ja leia telefoni ühendus portidele 5228-5230. Võrdle selle järelejäänud eluiga dokumenteeritud väärtusega. Kui see on lühem, suurenda nende portide aegumist, selle asemel et muuta kõiki seadme põhimõtteid, sest globaalset aegumise muutust on raske põhjendada ja veelgi raskem tagasi võtta.

Tõuke kohaletoimetamine sõltub ka sellest, kas lõpp-punkti vastendus jääb Wi-Fi ja mobiilside vahelisel rändlusel püsima. Ühe liidese külge seotud vastendus võib üleandmisel kaduda isegi siis, kui mõlemad võrgud porte lubavad.

Otsusta, kas VPN-i möödaviik on vastuvõetav

Androidi VPN-kliendid võivad lubada liiklusel tunnelist mööda minna ja FCM võib sellise möödaviigu lubamisel kasutada alusvõrku. Tõukekanal jääb sel juhul krüpteerituks, kuid ei kanna enam tunneli aadressi, nii et VPN-i IP-maskeerimine sellele ei kehti. See on põhimõtteline kompromiss, mitte rike.

Kui sinu põhimõte möödaviiku keelab, peab tunnelitee ühendust kandma: pordid avatud, aegumised piisavalt pikad, puhverserver teel ees ei seisa. Ära jäta hallatavat teenust vaikselt välja ega lõdvenda lukustust ainult seetõttu, et teated haldamata võrgus töötavad. VPN-i ikoon ei näita, millise tee konkreetne teenus valis

Eralda kohaletoimetamine kuvamisest ja testi üks kord

Luba, kanali seaded, Mitte segada ja rakendusepõhised lülitid otsustavad, kas kohale toimetatud sõnum kuvatakse. Androidis 13 ja uuemates on teavituste luba käitusaegne andmine ja keeldutud andmine tekitab vaikuse, mis näeb täpselt välja nagu blokeeritud port. Sõnum, mis saabus, kuid mida ei kuvatud, on esitlusprobleem; käsitle seda eraldi.

Tee üks kontrollitud test, selle asemel et sõnumeid juhuslikult saata. Hoia seade, konto ja rakendus muutumatuna, saada üks sõnum teadaoleva ajatempliga ja võrdle VPN-i olukorda kinnitatud VPN-ita võrguga. Kirjuta üles logcat vastuvõtuaeg ja kuvamisaeg iga katse kohta. Kui kohaletoimetamine erineb, kuid kuvamine mitte, on muutuja võrgutee; kui mõlemad on identsed, vaata edasi rakendust.

Anna võrguomanikule portid, puhverserveri piirang, mõõdetud aegumine ja möödaviigu otsus ühes märkuses. „Lülita VPN välja” ei ole leid ja kogu Google'i liikluse lubamine ei ole piiritletud parandus.