Anfon pyrth ymlaen ar hotspot Android: y tri phwynt mynediad

Fe wnaethoch chi droi’r hotspot ymlaen, cysylltu’r VPN, agor porth yn yr ap, ac eto ni all y ddyfais arall gysylltu. Anaml iawn mai’r porth ei hun yw’r darn sydd ar goll, ond pa beiriant sy’n berchen ar y soced sy’n gwrando a pha gyfeiriad y dylai’r ddyfais arall ei gyrraedd. Rwy’n mynd o’r ffôn tuag allan, oherwydd mae’r sgrin o’ch blaen yn dweud pa un o’r tri phwynt mynediad rydych chi’n ei brofi.

Dechreuwch lle mae’r gwasanaeth yn rhedeg mewn gwirionedd

Agorwch yr ap sy’n mynd i dderbyn y cysylltiad a darllenwch ei dudalen statws. Os yw’n dweud ei fod yn gwrando, nodwch y cyfeiriad y mae wedi’i rwymo iddo, oherwydd mae’r un manylyn hwnnw’n penderfynu’r rhan fwyaf o’r achosion isod. Nid yw ap sydd wedi’i rwymo i 127.0.0.1 yn cyrraedd ond o’r ffôn, ac ni fydd cleient hotspot, mapio’r gweithredwr na ffordd allan VPN yn newid hynny.

Yna cadarnhewch ba ddyfais sy’n rhedeg y gwasanaeth. Os mai’r ffôn yw hi, soced yr ap hwnnw yw’r soced; os mai gliniadur y tu ôl i’r hotspot yw hi, y gliniadur sy’n berchen ar y gwrandawr a’i wal dân, a’r ffôn yn unig yn trosglwyddo pecynnau. Dau ddyluniad gwahanol ydyn nhw, a’u cymysgu yw’r rheswm pam nad yw porth a agorwyd mewn un lle yn gwneud dim yn y llall.

Mewn adeilad dadfygol, mae adb shell yn rhestru socedi drwy /proc/net/tcp, ond i’r rhan fwyaf o bobl statws yr ap ei hun yw’r ffynhonnell onest.

Pwynt mynediad un: dyfais arall ar y hotspot

Dyma’r achos lleol a’r un hawsaf. Mae’r ddyfais arall yn cyrraedd y ffôn ar y cyfeiriad y mae’n ei weld fel ei chllwyd, ar y porth y mae’r ap yn gwrando, ac nid oes angen dim y tu allan i’r hotspot. Nid oes angen mapio’r gweithredwr, oherwydd nad yw’r traffig yn gadael y segment lleol.

Mae dau beth yn torri hyn: bod yr ap wedi’i rwymo i loopback, neu nad yw polisi cleient y ffôn yn caniatáu’r cysylltiad lleol. Profwch gyda phrotocol yr ap ei hun yn hytrach na TCP noeth, oherwydd mae gwrandawr sy’n derbyn ac yna’n gwrthod yn edrych fel porth caeedig o bell.

Os yw’r gwasanaeth ar liniadur wedi’i gysylltu, nid cyfeiriad hotspot y ffôn yw’r gyrchfan o gwbl; rydych chi angen cyfeiriad y gliniadur ar ryngwyneb y hotspot a gwrandawr yno.

Pwynt mynediad dau: llwybr y gweithredwr

Mae cyrraedd y ffôn o’r rhwydwaith symudol yn broblem wahanol, ac yn aml nid yw’n gweithio o gwbl ar gyfer IPv4. Mae gweithredwyr yn rhoi ffonau y tu ôl i gyfieithu a rennir, a dyna pam mae RFC 6598 yn neilltuo ystod gyfeiriadau a rennir ar gyfer y trefniant hwnnw. Nid oes gan gysylltiad sy’n dod i mewn heb ei ofyn unrhyw fapio i gyrraedd drwyddo, ac nid yw unrhyw ffurfweddiad lleol yn creu un, oherwydd nid eich dyfais chi yw’r cyfieithydd.

Nid yw mynediad root yn newid hynny chwaith; mae’n rhoi rheolaeth dros stac y ffôn, nid dros gyfieithydd y gweithredwr. Pan fydd y gweithredwr yn cynnig rhagddodiad IPv6 cyhoeddus, gall llwybr i mewn fodoli, ond mae angen awdurdodiad bwriadol ar y gwrandawr a wal dân y ffôn o hyd.

Pwynt mynediad tri: ffordd allan y VPN

Y cyfeiriad y mae gwefan yn ei adrodd tra mae’r twnnel i fyny yw cyfeiriad y ffordd allan ar gyfer traffig allan a gwmpesir. Nid yw’n gyfeiriad sy’n derbyn cysylltiadau i mewn ar eich rhan. I’w ddefnyddio i mewn mae angen nodwedd y mae’r darparwr yn ei chynnig mewn gwirionedd, fel porth a anfonwyd ymlaen, ynghyd â llwybr defnyddiadwy o’r ffordd allan i’r cleient.

Ni all rheol ganiatáu leol greu’r mapio hwnnw. Yr hyn y mae’n ei wneud yw newid pa lwybr y mae atebion yr ap yn ei gymryd, sy’n bwysig pan fydd yr ap wedi’i eithrio o’r twnnel: gall y cais a’r ateb fod mewn cyd-destunau rhwydwaith gwahanol ac mae’r cysylltiad yn methu fel problem wal dân.

Profwch un llwybr o’r dechrau i’r diwedd, yna enwch y perchennog

Ysgrifennwch y pedwarawd cyn profi: y ffynhonnell a fwriadwyd, y cyfeiriad cyrchfan, y cludiant, y porth, a’r peiriant sy’n berchen ar y soced sy’n gwrando. Os yw unrhyw elfen yn ddyfaliad, ni fydd y prawf yn dweud dim defnyddiol wrthych.

Yna profwch yr un llwybr awdurdodedig hwnnw gyda dilysiad yr ap yn gyfan. Peidiwch â chyhoeddi gwrandawr eang na diffodd rheolyddion diarffordd yn unig er mwyn i wirio cyfeiriad amwys ateb, oherwydd mae’r ddau newid yn goroesi’r prawf.

Mae is-system tethering Android yn anfon traffig i lawr ar ei lwybr ei hun, ar wahân i ddal VPN arferol, felly nid yw porwr sy’n gweithio ar liniadur wedi’i gysylltu yn dweud dim am fynediad i mewn i wasanaeth ar y ffôn. Cyn dweud ei fod yn gweithio:

• Mae’r gwrandawr ar gyfeiriad y gall y pen arall ei gyrraedd, nid ar loopback.
• Mae’r pen arall yn defnyddio cyfeiriad y pwynt mynediad hwnnw, nid cyfeiriad allan o dudalen statws.
• Mae unrhyw fapio ar ochr y gweithredwr neu’r darparwr yn nodwedd a gefnogir, nid rheol a ychwanegwyd yn lleol.
• Mae’r cais a’r ateb yn mynd drwy’r un cyd-destun ac mae’r dilysiad yn dal i basio.