Bakit nabibigo ang IKEv2 sa Android sa hindi pamantayang port ng UDP

Sumasagot ang gateway sa IKEv2 sa UDP 4443 dahil sa isang dahilan, may field ang profile na pinangalanang Server, itinatype mo ang pangalan ng host at ang port, at iniuulat ng telepono na hindi nito maabot ang server o hindi nito maresolba ang address. Walang hinaharangan. Inaasahan ng katutubong form ng Android ang isang host, at ganoon din sa Windows. Ang pasadyang port ay kakayahan ng kliyente bago maging setting ng server, at iilang kliyente lang ang nagpapahintulot sa iyong ipahayag ito. Daanan ang tatlong bahagi sa pagkakasunod-sunod: ano ang masasabi ng kliyente, ano ang pinakikinggan ng server at kung pareho ang pagbabalangkas ng mga pakete sa magkabilang dulo.

Ano talaga ang ipinadala ng telepono

Ang string na host:port sa field na inilaan para sa pangalan ay nireresolba bilang pangalan. Walang ibinabalik ang resolver para sa vpn.example.net:4443, at ang error na nakikita mo ay pagkabigo sa pagresolba ng pangalan o kawalan ng maabot, hindi pagkapaso ng oras sa isang port. Mahalaga ang pagkakaibang iyon, dahil ang muling pagsubok na may mas maikling pangalan o ibang network ay hindi kailanman magwawasto ng string na hindi kayang i-parse ng form.

Ang katutubong profile ng IKEv2 sa Android, tulad ng built-in na VPN client ng Windows, ay nakapirmi sa mga pamantayang port ng IKE. Wala sa kanila ang nagpapakita ng field ng port, at walang pag-edit ng profile ang nagdaragdag ng isa. Kung ang tagapakinig ng operator ay talagang nasa 4443, ang built-in na kliyente ang maling kasangkapan, hindi isang mali ang pagkakaayos.

Gumamit ng kliyenteng nagpapakita ng port

Dinodokumento ng kliyente ng strongSwan para sa Android ang naikokonfigurang port ng server sa mga advanced na setting ng profile, kaya lumilitaw ito sa halos lahat ng gumaganang recipe para sa disenyong ito. Ang suportang iyon ay pag-aari ng kliyenteng iyon: maaaring hindi ipakita ng ibang app na IKEv2, o ng fork ng vendor ng parehong app, ang parehong field kahit sinusuportahan ito ng pinagbabatayang daemon ng strongSwan.

Hilingin sa operator ang buong set nang sabay: pangalan ng gateway, port ng UDP, paraan ng pagpapatunay at ang pagkakakilanlan ng server na dapat asahan ng kliyente. Ang pasadyang port ay hindi dahilan para patayin ang pagsusuri ng sertipiko o palitan ang mga protocol. Ilagay ang port kung saan ito inaasahan ng naka-install na kliyente, at kung walang ganoong field ang kliyenteng iyon, ang sagot ay ibang aprubadong kliyente at hindi isang hinuang paraan.

May dalawang port ang server, at dapat magtugma ang dalawa

Nagsisimula ang IKE sa UDP 500, at kadalasang inililipat ng pagdaan ng NAT ang IKE at ang nakabalot na ESP sa UDP 4500. Magkahiwalay na setting ang mga ito sa strongSwan, kaya ang server na inilipat sa isang pasadyang port ay dapat baguhin ang dalawa sa parehong halaga:

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

Kapag isang port ang nagsisilbi sa dalawang tungkulin, kailangang ihiwalay ng daemon ang IKE mula sa ESP-sa-loob-ng-UDP sa parehong socket, na ginagawa nito gamit ang apat na byte na markang hindi ESP at nauuna sa isang mensahe ng IKE. Kaya hindi makipagnegosasyon ang kliyente sa pasadyang port at pagkatapos ay tahimik na magpatuloy sa 4500, at kaya itinatago ng pariralang “palitan lang ang port” ang isang pangangailangan sa pagbabalangkas.

Ang pagpapasa ay hindi tagapakinig

Ang pagpapasa ng 4443 sa ordinaryong tagapakinig ng IKE ay ang paraan ng pagkabigo na mukhang halos matagumpay. Dumating ang unang palitan, sumagot ang server, at pagkatapos ay humihinto ang koneksyon o muling gumagawa ng mga susi nang walang mapuntahan, dahil lumalabas ang sagot mula sa ibang port at kailanman hindi tumutugma ang nakabalot na trapiko mamaya sa kalagayang ginawa ng dalawang dulo. Ang tuntuning muling nagsusulat ng port ng patutunguhan nang hindi inililipat ang tagapakinig ay nagbubunga ng eksaktong kalahating-bukas na resultang ito.

Dapat ding payagan ng landas ang UDP mula dulo hanggang dulo. Ang pagdaan ng TCP 443 sa network ng hotel o ng operator ay walang sinasabi tungkol sa IKEv2 sa isang port ng UDP, kahit pareho ang bilang. Kung saan TCP 443 lang ang pinapayagan, hindi ginagawang HTTPS ng pasadyang port ng UDP ang IKEv2, at ang tamang sagot ay maaaring ibang landas ng pag-access sa halip na isa pang eksperimento sa port.

Paghiwalayin ang tatlong yugto kapag sumusubok

Kunin ang trapiko sa server habang sumusubok ang kliyente nang isang beses. Ang kahilingang hindi kailanman dumarating ay tanong ng dulong punto o firewall; ang kahilingang dumarating na walang sagot ay tanong ng tagapakinig o patakaran; ang sagot na sinusundan ng katahimikan ay ang tanong ng pagbabalangkas o pagkakakilanlan.

tcpdump -ni eth0 -vv udp port 4443

Pagkatapos ay basahin ang mensahe ng kliyente at hindi ang umiikot nitong tagapagpahiwatig. Ang error sa panukala ay nangangahulugang hindi magkatugma ang mga algorithm, ang pagkabigo sa pagpapatunay ay nangangahulugang hindi magkatugma ang mga pagkakakilanlan o sertipiko, at ang paulit-ulit na muling pagpapadala na walang sagot ay nangangahulugang walang sumasagot sa port na iyon. Subukan ang isang yugto sa isang pagkakataon at palitan ang isang field sa pagitan ng mga pagsubok; inilalarawan ng dokumentasyon ng strongSwan tungkol sa pagdaan ng NAT ang marka at pag-uugali ng port na ipinapakita sa iyo ng pagkuha.