Kwa nini IKEv2 kwenye Android inashindikana kwenye lango la UDP lisilo la kawaida

Fomu asilia ya IKEv2 inachukua anwani, si lango. Hakikisha mteja anaunga mkono, weka lango zote mbili za seva, kisha angalia ufumo na kumbukumbu.

Lango linajibu IKEv2 kwenye UDP 4443 kwa sababu fulani, wasifu una sehemu inayoitwa Server, unaandika jina la mwenyeji na lango, na simu inaripoti kuwa haiwezi kufikia seva au haiwezi kutatua anwani. Hakuna kinachozuiliwa. Fomu asilia ya Android inatarajia mwenyeji, na ni hivyo hivyo kwenye Windows. Lango maalum ni uwezo wa mteja kabla ya kuwa mpangilio wa seva, na ni wateja wachache tu wanaokuruhusu kulieleza. Pitia sehemu tatu kwa mpangilio: mteja anaweza kusema nini, seva inasikiliza kitu gani, na je, pande zote mbili zinafuma pakiti kwa namna moja.

Simu ilituma nini kwa hakika

Mfuatano wa host:port katika sehemu iliyokusudiwa jina hutatuliwa kama jina. Kitatuzi hakirudishi kitu kwa vpn.example.net:4443, na hitilafu unayoona si muda wa kusubiri kwenye lango, bali ni kushindikana kwa utatuzi wa jina au kutofikika. Tofauti hiyo ni muhimu, kwa sababu kujaribu tena kwa jina fupi au mtandao mwingine hakutarekebisha kamwe mfuatano ambao fomu haiwezi kuuchanganua.

Wasifu asilia wa IKEv2 kwenye Android, kama mteja wa VPN aliyejengwa ndani ya Windows, umefungwa kwenye lango za kawaida za IKE. Hakuna hata moja inayoonyesha sehemu ya lango, na uhariri wowote wa wasifu hauongezi moja. Iwapo msikilizaji wa mwendeshaji yuko kweli kwenye 4443, mteja aliyejengwa ndani ni chombo kisichofaa, si kile kilichowekwa vibaya.

Tumia mteja anayeonyesha lango

Mteja wa strongSwan wa Android unaandika lango la seva linaloweza kupangwa katika mipangilio ya juu ya wasifu, ndiyo sababu inaonekana katika karibu kila kichocheo kinachofanya kazi kwa muundo huu. Msaada huo ni wa mteja huyo: programu nyingine ya IKEv2, au tawi la msambazaji la programu hiyo hiyo, huenda isionyeshe sehemu hiyo hiyo ingawa daemon ya strongSwan ya msingi inaunga mkono.

Omba mwendeshaji seti yote kwa mara moja: jina la lango, lango la UDP, mbinu ya uthibitishaji, na utambulisho wa seva ambao mteja anapaswa kuutarajia. Lango maalum si sababu ya kuzima ukaguzi wa vyeti au kubadilisha itifaki. Weka lango mahali ambapo mteja aliyesakinishwa analitarajia, na ikiwa mteja huyo hana sehemu kama hiyo, jibu ni mteja mwingine aliyeidhinishwa, si mbinu ya kubahatisha.

Seva ina lango mbili, na zote mbili lazima zilingane

IKE huanza kwenye UDP 500, na upitishaji wa NAT kwa kawaida huhamisha IKE na ESP iliyofungwa kwenda UDP 4500. Hizi ni mipangilio tofauti katika strongSwan, kwa hiyo seva iliyohamishwa kwenda lango moja maalum lazima ibadilishe zote mbili kwenda thamani moja:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

Lango moja linapohudumia majukumu yote mawili, daemon lazima itofautishe IKE na ESP-ndani-ya-UDP kwenye soketi hiyo hiyo, jambo ambalo hufanya kwa alama ya baiti nne isiyo ESP inayotangulia ujumbe wa IKE. Ndiyo sababu mteja hawezi kujadiliana kwenye lango maalum kisha kuendelea kimya kwenye 4500, na ndiyo sababu kifungu “badilisha lango tu” kinaficha sharti la ufumo.

Uelekezaji si msikilizaji

Kuelekeza 4443 kwa msikilizaji wa kawaida wa IKE ni hali ya kushindikana inayoonekana karibu kufanikiwa. Mabadilishano ya kwanza yanafika, seva inajibu, kisha muunganisho unakwama au huzalisha funguo upya kwa kitu chochote, kwa sababu jibu linatoka kwenye lango lingine na trafiki iliyofungwa baadaye kamwe hailingani na hali ambayo pande mbili ziliunda. Kanuni inayoandika upya lango lengwa bila kuhamisha msikilizaji hutoa matokeo haya hasa ya nusu-wazi.

Njia lazima pia iruhusu UDP kutoka mwanzo hadi mwisho. Kupita kwa TCP 443 kupitia mtandao wa hoteli au wa mwendeshaji hakusemi kitu kuhusu IKEv2 kwenye lango la UDP, hata kama namba ni moja. Mahali panaporuhusiwa TCP 443 pekee, lango maalum la UDP halifanyi IKEv2 kuwa HTTPS, na jibu sahihi linaweza kuwa njia nyingine ya kufikia, si jaribio lingine la lango.

Tenganisha hatua tatu unapojaribu

Nasa kwenye seva wakati mteja anajaribu mara moja. Ombi lisilofika kamwe ni swali la kituo cha mwisho au ukuta wa moto; ombi linalofika bila jibu ni swali la msikilizaji au sera; jibu linalofuatiwa na ukimya ni swali la ufumo au utambulisho.

tcpdump -ni eth0 -vv udp port 4443

Kisha soma ujumbe wa mteja badala ya kiashiria chake kinachozunguka. Hitilafu ya pendekezo inamaanisha algoriti hazilingani, kushindikana kwa uthibitishaji kunamaanisha utambulisho au vyeti hazilingani, na utumaji upya unaorudiwa bila jibu unamaanisha hakuna kinachojibu kwenye lango hilo. Jaribu hatua moja kwa wakati na badilisha sehemu moja kati ya majaribio; nyaraka za strongSwan kuhusu upitishaji wa NAT zinaeleza alama na tabia ya lango ambayo nasa inakuonyesha.

Makala zinazohusiana