Android VpnService: usomaji wa TUN uliokwama dhidi ya makosa ya uandishi ENOBUFS

Dalili mbili hutokea katika mzunguko mmoja wa VpnService na zote mbili zinalaumiwa kwa kitu kimoja: kisomaji kisichorejea kamwe, na uandishi unaoshindikana na ENOBUFS. Hizi si aina za hitilafu moja. Usomaji uliokwama ni kutokubaliana kuhusu udhibiti wa mtiririko na peer; uandishi ulioshindikana ni pakiti ambayo kiolesura hakitakubali. Ukizichukulia kama tatizo moja, utatumia siku moja kurekebisha bafa ambazo hazikuhusika kamwe. Mgawanyo ulio hapa chini ni jinsi ninavyoamua nusu ipi ya mzunguko kupima kwanza.

Mzunguko mmoja, sehemu mbili huru za kushindikana

Huduma yako inasoma pakiti ya IP kutoka kielekezi cha faili cha TUN, inaichunguza na inaandika jibu kurudi kwenye kielekezi hicho hicho. Kila kinachovunjika kwenye njia hiyo huonekana kwenye moja ya miito hiyo miwili, ndiyo sababu zote mbili zinaripotiwa kama handaki lililovunjika. Miito ina mikataba tofauti. Usomaji husubiri kerneli ikupatie pakiti, na uandishi humpa kerneli pakiti ambayo ina haki ya kuikataa.

Usomaji ni nusu rahisi kufikiria. Usomaji usiorejesha chochote ama husubiri trafiki isiyokuja kamwe au husubiri kwa sababu peer imeacha kutuma.

Usomaji uliokwama ni kutokubaliana kuhusu udhibiti wa mtiririko

Kusoma kifaa cha TUN huzuia hadi pakiti ipatikane. Hiyo ni tabia iliyoundwa, na ndiyo sababu uzi uliosimama ndani ya read huonekana kawaida kwenye kiungo kisichofanya kazi. Inakuwa kukwama wakati mrundikano wako wa TCP unaendelea kupokea data kutoka programu ya ndani lakini hautangazi kamwe dirisha la kutosha kwa peer ya mbali kutuma zaidi. Peer hujaza dirisha ulilotangaza, husubiri ACK na sasisho la dirisha, kisha husimama. Wakati huo kisomaji chako hakina cha kurejesha, na programu inaona muunganisho uliofunguliwa na wenye ukimya.

Sababu za kawaida ni mrundikano unaoandika kwenye soketi bila kufuatilia dirisha lililotangazwa, na mwingine unaosahau kutuma sasisho la dirisha baada ya kumwaga bafa yake. Kutoka nje huonekana sawa: baiti hutoka, hakuna kinachorudi, hakuna hitilafu inayoinuliwa. Kuzuia uzi wa usomaji kwenye uchanuzi, utatuzi wa DNS au I/O ya diski huzalisha umbo lile lile la dalili kwa sababu isiyohusiana, kwa hiyo thibitisha kuwa uzi uko ndani ya read kabla ya kulaumu udhibiti wa mtiririko.

Angalia foleni ya utumaji ya peer na dirisha aliloliona mwisho. Ikiwa peer inashikilia data kwa sababu dirisha lako ni sifuri, marekebisho yako kwenye njia yako ya ACK, si kwenye usomaji wa TUN.

ENOBUFS ni tatizo la ukubwa, si uhaba wa bafa

Uandishi unaorejesha ENOBUFS kwenye kiolesura cha TUN kwa kawaida hukataa urefu wa pakiti. Kiolesura kina MTU, pakiti kubwa kuliko hiyo haiwezi kuwekwa kwenye foleni, na kujaribu tena pakiti hiyo hiyo hushindikana vivyo hivyo kila mara. Uthabiti huo ndio kidokezo. Uhaba wa kweli wa bafa huondoka kadiri shinikizo linapungua, wakati kukataliwa kwa ukubwa hakujali ungoje kiasi gani.

TCP ina utaratibu kwa ajili ya hili hasa, na ndio hatua ambayo watu huiruka: mbano wa MSS. Unapounda sehemu katika nafasi ya mtumiaji wewe huchagua ukubwa wa mzigo, na kuuchukua kutoka MTU ya kiolesura cha ndani badala ya MTU ya handaki hutoa sehemu ambazo handaki haiwezi kuzibeba. Bana hadi ndogo kati ya hizo mbili. Mbano hufunika TCP pekee, kwa hiyo datagram ya UDP iliyo kubwa mno lazima igawanywe au itupwe na msimbo wako.

Rekodi urefu wa kila pakiti unayoandika wakati wa utatuzi. Urefu unaoshindikana ndio jibu, na hautabadilika kati ya majaribio.

Vipimo vitatu vinavyotenganisha visa

Hauhitaji kidadisi cha hitilafu kwa lolote la kushindikana hizo mbili. Uchunguzi tatu unatosha kukuelekeza kwenye sehemu sahihi, na huchukua muda mfupi kuliko kujenga upya.

Ikiwa safu ya tatu inalingana, mzunguko wenyewe uko sawa na tatizo liko mahali ambapo handaki haliwezi kuliona: soketi ya usafirishaji isiyolindwa inayorudisha trafiki yako ya VPN kwenye handaki, ambayo kwa kawaida huonekana kama muunganisho unaofanikiwa kisha usiwasilishe chochote.

Rekebisha mabomba ambayo njia zote mbili zinategemea

Hakuna dalili inayostahili kufuatiliwa hadi kiolesura kijengwe ipasavyo. Miito muhimu ya builder ni anwani, njia, MTU na ridhaa, kwa mpangilio huo:

Builder()
  .addAddress(10.8.0.2, 32)
  .addRoute(0.0.0.0, 0)
  .setMtu(1400)
  .establish()

Weka MTU kwenye thamani halisi ya handaki badala ya kuiacha kwenye ile ambayo mfano ulitumia. Kila unachoandika baadaye kinapunguzwa na nambari hiyo, na kutokupatana kati ya MTU unayoweka na MSS unayobana hadi hapo ndiyo njia ya kawaida ya kurudisha kosa la uandishi baada ya marekebisho. Kisha linda soketi inayobeba trafiki kwa seva ya VPN yenyewe. Bila protect pakiti hizo zinaelekezwa tena kwenye handaki lako na muunganisho haukamiliki kamwe, jambo ambalo linaonekana kama usomaji uliokwama lakini ni mzunguko wa uelekezaji.

Ridhaa haiwezi kuepukwa. Huduma inayoanzishwa bila prepare kurejesha null haipati kiolesura, na establish hurejesha null badala ya kutupa, kwa hiyo angalia kielekezi kabla ya kuanza mzunguko wako. Rejea ya VpnService ndio mahali pa kuthibitisha mkataba wa builder badala ya kunakili mfano.

Thibitisha mwelekeo mmoja kwa wakati

Tuma mwangwi wa UDP kupitia handaki na uangalie urefu wa pakiti kabla ya kugusa TCP. Kisha fungua kupeana mkono na uthibitisha kuwa sehemu zinabaki chini ya MSS uliyohesabu. Hesabu pakiti badala ya miunganisho, ili kukwama kuonekane kama pengo kwenye kihesabu badala ya soketi iliyoning'inia. Ikiwa usomaji unasimama baada ya mlipuko wa uandishi, dirisha ndilo linaloshukiwa; ikiwa uandishi unashindikana mara moja, ni urefu.

Kisha uanzishe upya kifaa na urudie mara moja, kwa sababu VpnService inayofanya kazi hadi mabadiliko ya kwanza ya mtandao ni tatizo la uelekezaji, si la udhibiti wa mtiririko.