Umeongeza kikoa kwenye orodha ya kuruhusiwa, swali linafika kwenye programu yako, kifananishi kinarudisha imeruhusiwa, na ukurasa bado haupaki kamwe. Wakati huo watu wengi huanza kuandika upya kifananishi na kuongeza ulinganisho wa wildcard. Kwa uzoefu wangu kifananishi huwa sahihi, na hitilafu iko tabaka moja chini: katika jibu la DNS ulilotengeneza, katika njia uliyoweka, au katika soketi uliyotumia kupeleka swali. Orodha ni sehemu rahisi; njia ya pakiti ndipo orodha za kuruhusiwa zinapovunjika.

Kifananishi ni mara chache ndiye mwenye kosa

Jambo la kwanza kutenganisha ni lililozuiwa na lililovunjika. Jina lililozuiwa linapaswa kushindwa haraka na kwa kuonekana, kwa sababu kivinjari kinapata jibu kwamba jina halipo na linasimama. Jina lililovunjika linasimama, linajaribu tena kupitia IPv6, linashuka kwenye usafiri mwingine, na linakuacha na kiashiria kinachozunguka. Ukiona kiashiria kinachozunguka, orodha yako ya kuruhusiwa huenda inajibu kitu ambacho mteja hawezi kufanya chochote nacho.

Rekodi tupu ya A ni kosa la kawaida. Kurudisha NOERROR na majibu sifuri inaonekana kama jibu halali, kwa hiyo kitatuzi cha stub kinakubali, kivinjari kinajaribu tena, kinajaribu AAAA, kinajaribu kitatuzi kingine, na kinakata tamaa baadaye sana. Msimbo wa jibu 3, yaani NXDOMAIN, pamoja na sehemu ya swali kurudiwa na kitambulisho cha muamala kunakiliwa, unamaliza mazungumzo mara moja. Itumie kwa kila jina unalokataa kwa makusudi.

IPv6 pia inastahili uamuzi huo badala ya chaguo-msingi. Ukipenda NXDOMAIN kwa A na kuruhusu AAAA kupita, mteja anaweza kufikia jina lililozuiwa kupitia IPv6 na kichujio kinavuja. Baadhi ya utekelezaji hujibu maswali ya AAAA yaliyozuiwa kwa anwani ya loopback ili muunganisho ushindwe mara moja badala ya kuanguka kwenye njia mbadala. Chagua sera moja, itumie kwa aina zote mbili za rekodi, na uandike zote mbili.

Njia inayokamata kila kitu inamiliki kila kitu

Muundo wa DNS pekee hauongezi kamwe addRoute("0.0.0.0", 0), kwa hiyo ni maswali tu yanayoungia kwenye kiolesura cha TUN na kila kitu kingine kinaendelea kutumia mtandao wa chini. Hiyo ndiyo umbo salama, na inaeleza pia kwa nini baadhi ya orodha za kuruhusiwa zinaonekana kufanya kazi kwenye Wi-Fi na kushindwa kwenye mtandao wa simu.

Wakati njia ya chaguo-msingi inakuwepo, kila mtiririko ni wako. Pakiti ya TCP inayofika kwenye kiolesura na haipelekwi wala haijibiwi hukaa kwenye foleni hadi muda wa mteja uishe, na hakuna hitilafu ya kuandika kwa sababu hakuna kilichoshindwa. Niliona mtu akitumia mchana mzima kwenye orodha ya kuruhusiwa iliyovunjika ambayo kwa kweli ilikuwa kipelekaji kilichokosekana kwa lango 443. Andika itifaki na lengwa la kila pakiti unayoamua kuiondoa.

Soketi ya kitatuzi lazima itoke kwenye handaki

Upelekaji ndipo mtego unaofuata unakaa. Vitatuzi vya mtoa huduma mara nyingi huishi kwenye anwani ya kibinafsi ambayo handaki haiwezi kufikia, kwa hiyo swali unalopeleka haliendi popote na programu inaripoti muda wa kusoma umeisha. Tuma maswali yaliyoidhinishwa kwa kitatuzi unachojua kinafikiwa, na kwanza ipe soketi hiyo VpnService.protect(). Soketi isiyolindwa inarudisha swali kwenye handaki yako mwenyewe, ambako linafika kwenye programu tena na kuzunguka hadi muda uishe.

Hitilafu inaonekana sawa na kukatika kwa mtandao, na ndiyo sababu inaishi muda mrefu hivyo katika ripoti za hitilafu. Weka vihesabu vya maswali yaliyotumwa na majibu yaliyopokelewa: ikiwa namba ya kwanza inapanda na ya pili inabaki sifuri, unaangalia soketi, si orodha.

Ukubwa na checksum hushindwa bila ujumbe

Kuondoa kwa kimya pia hutokana na ukubwa. Jibu la DNS lenye seti kubwa ya majibu, au kupeana mikono kwa TCP na chaguo za ukarimu, linaweza kuzidi MTU ya njia ambayo hukuiweka kamwe kwa uwazi; kipande kinatoweka juu na mteja ama anajaribu tena kwa kidogo au anaacha kujaribu. Kuweka MTU ya kiolesura kuwa 1280 ni chaguo la kihafidhina linalostahimili njia nyingi za simu, na kuwa wazi ni bora kuliko kurithi chaguo-msingi ambalo hakuna aliyelipima.

Ukijenga pakiti mwenyewe, checksum ni muuaji mwingine wa kimya. Checksum ya UDP inayohesabiwa juu ya kichwa bandia kinachoacha urefu wa UDP au uwanja wa itifaki huzalisha pakiti inayoonekana imeundwa vizuri kwako na kutupwa na mpokeaji bila alama. Linganisha kichwa chako bandia na vipimo uwanja kwa uwanja, na uchapishie checksum iliyohesabiwa kwa mtiririko mmoja unaojulikana unapotafuta hitilafu.

Kile ambacho VpnService haitafanya kwa ajili yako

Mipaka miwili inafaa kujulikana kabla ya kubuni kuzunguka. Hakuna programu ya kawaida inayoweza kusakinisha proksi ya mfumo mzima au faili ya PAC nje ya Wi-Fi, na sehemu hiyo haijabadilika. Njia ya programu moja moja imebadilika: kabla ya API 29, VpnService.Builder haikuweza kubeba proksi kabisa, na kutoka API 29 setHttpProxy(ProxyInfo.buildPacProxy(uri)) inakabidhi jukwaa script ya PAC ili itathminiwe kwa mtandao wa VPN. Tathmini kanuni katika msimbo wako mwenyewe unapolenga API za zamani au wakati muundo wa PAC hauwezi kueleza kanuni. UDP pia si bure: vivinjari hutuma TCP pekee kupitia proksi ya SOCKS, na wateja wengi wa SOCKS5 hawatekelezi kamwe UDP ASSOCIATE, kwa hiyo muundo unaotegemea proksi huondoa au huvujisha UDP wakati TCP inaonekana mzima.

Huo mpaka wa pili ni sababu itifaki inayotegemea UDP inaweza kufanya kazi kwenye mtandao wa kawaida na kushindwa wakati VPN yako inaunganishwa. Ikiwa handaki inatarajiwa kubeba UDP, kipelekaji lazima kitekeleze njia ya upelekaji kwa ajili yake, si njia ya TCP pekee yenye aina nyingine ya soketi.

Kagua kwa mfuatano huu

Fanya kazi ya orodha kwa mfuatano na usimame katika hatua ya kwanza inayoshindwa, kwa sababu kila ukaguzi wa baadaye ni kelele hadi ule wa awali usimame.

  1. Orodhesha njia zilizosakinishwa na uthibitishe kama pakiti zisizo za DNS zinaingia kwenye kiolesura cha TUN.
  2. Andika jina la swali, uamuzi na msimbo wa jibu kwa jina moja lililozuiwa na moja lililoidhinishwa.
  3. Thibitisha soketi ya kitatuzi imelindwa na kitatuzi kilichochaguliwa kinajibu kutoka ndani ya handaki.
  4. Thibitisha MTU ya kiolesura na checksum ya jibu moja ulilojenga kwa mkono.
  5. Rudia ukurasa huo huo kwenye Wi-Fi na mtandao wa simu, kwa sababu vivatuzi vya mtoa huduma na MTU ya njia vinatofautiana.

Ikiwa zote tano zinasimama na ukurasa bado unasimama, mtuhumiwa anayefuata ni kipelekaji chenyewe: linganisha ombi lililonaswa na jibu lililonaswa na utafute hesabu ya baiti inayokosekana au soketi iliyofungwa nusu. Marejeleo ya VpnService.Builder inashughulikia mikataba ya njia, DNS na MTU, na protect() ni mwito wa VpnService tofauti na si chaguo la builder; kiolesura kilichounganishwa kinamaanisha tu kwamba mkataba wa kwanza umetimizwa.

Makala zinazohusiana