Përcjellja e porteve në hotspot Android: tre pika hyrjeje

Ndezët hotspotin, lidhët VPN-në, hapët një port në aplikacion dhe pajisja tjetër ende nuk mund të lidhet. Pjesa që mungon pothuajse kurrë nuk është vetë porti. Është pyetja se cila makinë zotëron socketin e dëgjimit dhe cila adresë duhet të arrijë pajisja tjetër. Unë e ndjek këtë nga telefoni drejt jashtë, sepse ekrani ku ndodheni ju tregon se cilën nga tre pikat e hyrjes po testoni në të vërtetë.

Filloni aty ku shërbimi funksionon vërtet

Hapni aplikacionin që duhet të pranojë lidhjen dhe lexoni faqen e tij të statusit. Nëse thotë se po dëgjon, shënoni adresën ku është lidhur, sepse ai detaj i vetëm vendos shumicën e rasteve më poshtë. Një aplikacion i lidhur me 127.0.0.1 arrihet vetëm nga vetë telefoni dhe asnjë klient hotspot, hartëzim operatori apo dalje VPN nuk do ta ndryshojë këtë.

Pastaj konfirmoni cila pajisje ekzekuton shërbimin. Është ose telefoni, dhe në atë rast socketi i përket atij aplikacioni, ose një laptop pas hotspotit, dhe në atë rast dëgjuesi dhe firewali i tij i përkasin laptopit dhe telefoni vetëm përcjell paketa. Këto janë dizajne të ndryshme me pronarë të ndryshëm, dhe përzierja e tyre është arsyeja pse një port i hapur në një vend nuk bën asgjë në tjetrin.

Në një ndërtim të debugueshëm, adb shell mund të listojë socketët përmes /proc/net/tcp, por për shumicën e njerëzve statusi i vetë aplikacionit është burimi i ndershëm. Kjo shmang edhe kurthin e testimit të një socketi që aplikacioni e hapi në një adresë që nuk e prisnit.

Pika e parë e hyrjes: një pajisje tjetër në hotspot

Ky është rasti lokal dhe më i lehtë për t'u bërë si duhet. Pajisja tjetër e arrin telefonin në adresën që e sheh si gateway të vet, në portin ku aplikacioni dëgjon, dhe asgjë jashtë hotspotit nuk duhet të përfshihet. Nuk nevojitet hartëzim operatori dhe asnjë veçori e ofruesit nuk duhet të ekzistojë, sepse trafiku nuk largohet kurrë nga segmenti lokal.

Dy gjëra e prishin. Aplikacioni i lidhur me loopback, ose politika e klientit në telefon nuk lejon lidhjen lokale. Testoni me protokollin e vetë aplikacionit në vend të një lidhjeje TCP të thjeshtë nëse aplikacioni bën vërtetim, sepse një dëgjues që pranon dhe më pas refuzon duket identik me një port të mbyllur nga larg.

Nëse shërbimi funksionon në një laptop të lidhur me telefonin, adresa e hotspotit të telefonit nuk është aspak destinacioni. Ju nevojitet adresa e laptopit në ndërfaqen e hotspotit dhe një dëgjues në laptop, dhe telefoni nuk është më pronar i asgjëje përveç përcjelljes.

Pika e dytë e hyrjes: rruga e operatorit

Arritja e telefonit nga rrjeti celular është problem tjetër dhe shumicën e kohës thjesht nuk funksionon për IPv4. Operatorët i vendosin aparatet pas përkthimit të përbashkët, prandaj RFC 6598 rezervoi një gamë adresash të përbashkëta pikërisht për atë rregullim. Një lidhje hyrëse e pakërkuar nuk ka hartëzim përmes të cilit të vijë, dhe asnjë konfigurim lokal nuk e krijon një, sepse përkthyesi nuk është pajisja juaj.

Qasja root as nuk e ndryshon këtë. Të jep kontroll mbi stackun e telefonit, jo mbi përkthyesin e operatorit, dhe recetat që premtojnë të kundërtën zakonisht supozojnë një adresë publike që operatori nuk e ka caktuar kurrë. Aty ku operatori ofron një prefiks IPv6 publik, një rrugë hyrëse mund të ekzistojë, por dëgjuesi dhe firewali i telefonit ende kanë nevojë për autorizim të qëllimshëm përpara se diçka të përgjigjet.

Pika e tretë e hyrjes: dalja e VPN

Adresa që raporton një faqe interneti ndërsa tuneli është aktiv është adresa e daljes për trafikun dalës të mbuluar. Kjo nuk është e njëjta gjë me një adresë që pranon lidhje hyrëse në emrin tuaj. Përdorimi i saj për hyrje kërkon një veçori që ofruesi e ofron vërtet, si një port i përcjellë ose një hartëzim hyrës i lidhur me llogarinë tuaj, plus një rrugë të përdorshme nga dalja te klienti.

Një rregull lokal lejimi nuk mund të krijojë atë hartëzim. Ajo që mund të bëjë është të ndryshojë se cilën rrugë marrin përgjigjet e aplikacionit, dhe kjo ka rëndësi kur aplikacioni përjashtohet nga tuneli: kërkesa dhe përgjigja mund të përfundojnë në kontekste të ndryshme rrjeti, dhe lidhja dështon në një mënyrë që duket si problem firewali.

Testoni një rrugë nga fillimi në fund, pastaj emërtoni pronarin

Shkruani tuple-in para testimit: burimi i synuar, adresa e destinacionit, transporti, porti dhe makina që zotëron socketin e dëgjimit. Nëse ndonjë element është hamendje, testi nuk do t'ju thotë asgjë të dobishme, dhe në fund do të ndryshoni një shtresë të dytë për të shpjeguar të parën.

Pastaj testoni atë rrugë të vetme të autorizuar me vërtetimin e aplikacionit të paprekur. Shmangni publikimin e një dëgjuesi të gjerë ose çaktivizimin e kontrolleve të palidhura vetëm që një kontroll i paqartë i adresës publike të përgjigjet, sepse të dyja ndryshimet i mbijetojnë testit dhe asnjëra nuk provon që dizajni funksionon.

Nënsistemi i tethering-ut të Android përcjell trafikun në zbritje në rrugën e vet, ndarë nga kapja normale e VPN-së nga aplikacionet, kështu që një shfletues që funksionon në një laptop të lidhur nuk thotë asgjë për qasjen hyrëse në një shërbim në telefon. Përpara se ta quani funksional:

• Socketi i dëgjimit është në një adresë që pala e synuar mund ta arrijë, jo në loopback.
• Pala po përdor adresën që i përket asaj pike hyrjeje, jo adresën e daljes nga një faqe statusi.
• Çdo hartëzim në anën e operatorit ose ofruesit është veçori e mbështetur, jo një rregull që e shtuat lokalisht.
• Kërkesa dhe përgjigja kalojnë në të njëjtin kontekst rrjeti, dhe vërtetimi i aplikacionit ende kalon.