TAP neu TUN? Cleientiaid OpenVPN Android a gweinyddwyr pont
Mae TAP yn cario fframiau Ethernet, mae TUN yn cario pecynnau IP, a dim ond yr ail fath y mae ap Android yn ei gael. Cymharwch y ddau, yna trwsiwch yr ochr weinydd.
Mae proffil sy'n gweithio ar liniadur yn methu ar y ffôn. Y cam amlwg yw newid un gair yng nghyfluniad y cleient. Ni fydd y gair hwnnw'n helpu, oherwydd nid yw'r ddau ben yn sôn am yr un math o draffig.
Mae TAP yn cario fframiau Ethernet. Mae TUN yn cario pecynnau IP. Rhoddir rhyngwyneb IP i ap VPN Android, sy'n gwneud un o'r ddau drefniant yn bosibl a'r llall yn amhosibl, beth bynnag mae'r cyfluniad yn ei ddweud.
Mae'r gymhariaeth yn fyr, ond mae'n penderfynu a allwch chi drwsio hyn ar y ffôn neu a oes rhaid ichi newid y gwasanaeth.
Dau fath o dwnnel â llwythi gwahanol
Mae rhyngwyneb TAP yn ymddwyn fel addasydd Ethernet. Mae'n cario fframiau, sy'n golygu ARP, darllediad a phopeth arall y mae LAN yn ei gario o dan IP. Dyna sy'n gwneud pontio'n bosibl: mae'r twnnel yn ymestyn parth darlledu, ac mae cleientiaid yn ymddwyn fel petaent wedi'u plwgio i swits.
Mae rhyngwyneb TUN yn cario pecynnau IP a gyfeirir ato. Nid oes haen gyswllt i'w thrafod, dim ARP, a dim darllediad. Llwybro sy'n penderfynu beth sy'n mynd i mewn i'r twnnel, ac mae cyfluniad yr ochr weinydd yn defnyddio is-rwydwaith yn hytrach na phont.
Rhaid i'r ddau ben gytuno pa un o'r rhain maen nhw'n ei wneud. Nid yw newid dev tap i dev tun ar un ochr yn troi'r gwasanaeth; mae'n cynhyrchu cleient sy'n disgwyl twnnel wedi'i lwybro a gweinydd sy'n dal i wthio fframiau, a gall yr ysgwyd llaw lwyddo tra nad oes dim defnyddiadwy yn croesi.
Beth mae Android yn ei roi i'r ap mewn gwirionedd
Mae API VpnService y platfform yn rhoi rhyngwyneb rhithwir ar gyfer pecynnau IP i ap, wedi'i ffurfweddu gyda chyfeiriadau, llwybrau ac MTU. Nid oes addasydd Ethernet yn yr API hwnnw, ac nid oes ffordd i'r ap ddychmygu un.
Dyna pam mae OpenVPN Connect yn dogfennu cefnogaeth ar gyfer cysylltiadau TUN wedi'u llwybro ar Android yn hytrach na phontio TAP. Cwestiynau cyffredin Android yw datganiad ochr y cleient am y ffin hon, ac mae'n cyfateb i API'r platfform.
Mae offer rhwydwaith root, firmware addasedig, neu gynnyrch sy'n gweithredu haen cyfieithu benodol yn drefniadau gwahanol. Yr achos cyffredin yw'r un i gynllunio o'i gwmpas: ap sy'n gallu mewnforio eich ffeil a rhedeg fel defnyddiwr arferol, gyda rhyngwyneb IP a dim byd o dano.
Sut mae'n edrych pan geisiwch beth bynnag
Mae'r cysylltiad yn sefydlu fel arfer. Dyna sy'n gwneud y methiant yn ddryslyd: mae'r cleient yn adrodd ei fod wedi cysylltu, mae log y gweinydd yn dangos cymar, ac nid oes unrhyw ap yn gweithio.
Nid yw traffig a gyfeirir at gyfeiriad neilltuedig y ffôn yn cyrraedd, oherwydd mae'r gweinydd yn pontio fframiau i gyfeiriad MAC nad oedd gan y ffôn erioed. Mae darganfod sy'n dibynnu ar ddarllediad yn aros yn wag. Os yw'r LAN yn dibynnu ar DHCP dros y bont, ni fydd y ffôn yn cael les felly, ac nid yw cyfeiriad a neilltuwyd â llaw yn yr is-rwydwaith bontio yn creu'r rhyngwyneb coll.
Mae rhai cleientiaid yn methu'n gynt, wrth fewnforio'r proffil, pan welant fath o ddyfais na allant ei gweithredu. Mae'r naill ymddygiad a'r llall yn golygu'r un peth, ac ni thrwsir y naill na'r llall drwy ychwanegu llwybrau, newid DNS, nac ehangu ystod cyfeiriadau'r twnnel.
Beth sy'n rhaid i'r ochr weinydd ei newid
Mae'r trwsiad yn perthyn i bwy bynnag sy'n rhedeg y gwasanaeth VPN, ac fel arfer mae'n ychwanegiad yn hytrach na mudo. Rhedwch ail enghraifft OpenVPN â dyfais wedi'i llwybro, ei his-rwydwaith cleientiaid ei hun, a chyfluniad ochr gweinydd sy'n neilltuo cyfeiriadau ac yn gwthio'r llwybrau sydd eu hangen ar y ffonau. Mae'r enghraifft bontio bresennol yn parhau i wasanaethu'r dyfeisiau sydd wir angen Ethernet.
Mae dau fanylyn yn gwneud hyn yn gweithio yn ymarferol. Mae angen llwybr dychwelyd ar y LAN ar gyfer is-rwydwaith newydd y cleientiaid, yn pwyntio at y gwesteiwr VPN, neu ni fydd atebion byth yn dod yn ôl. Ac mae'n rhaid i'r mur tanio ar westeiwr y twnnel anfon ymlaen rhwng rhyngwyneb y twnnel a'r LAN, sef y cam a gollir amlaf pan fo prawf o'r gwesteiwr ei hun yn llwyddo.
Os na all yr gweithredwr ychwanegu gwasanaeth, y dewis arall yw dyfais sy'n gallu ymuno â'r bont, hynny yw liniadur neu lwybrydd sy'n gweithredu ar ran y ffôn. Mae hynny'n ateb dros dro â'i gost reoli ei hun, nid cyfluniad Android.
Penderfynwch o'r ap, nid o'r twnnel
Gofynnwch beth y mae'n rhaid i'r ffôn ei gyrraedd mewn gwirionedd, yna mapiwch ef. Mae cyfrannu ffeil neu safle fewnrwyd y cyrchir ato drwy enw neu gyfeiriad yn ofyniad IP, ac mae twnnel wedi'i lwybro yn ei fodloni unwaith y bydd DNS yn datrys yr enw a'r llwybr yn bodoli. Nid yw teclyn darganfod sy'n pori'r parth darlledu lleol yn ofyniad IP, ac ni fydd unrhyw faint o lwybro yn ei lenwi.
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
Mae'r tabl hwnnw hefyd yn y cais i'w anfon. Enwch yr ap, y cyfeiriad neu'r enw y mae'n ei ddefnyddio, ac a yw'n dibynnu ar ddarganfod. Gall gweithredwr weithredu ar y disgrifiad hwnnw mewn ffordd na all neb weithredu ar ffôn na fydd yn cysylltu.
Yn olaf, cadwch y gwasanaeth TAP ar gyfer y dyfeisiau sydd ei angen, yn lle gwneud i bob cleient efelychu addasydd LAN. Mae dau wasanaeth ag amcanion clir yn haws eu cynnal nag un sy'n gweithio'n hanner i bawb.