Kial IKEv2 en Android malsukcesas ĉe neordinara UDP-pordo

La enirejo respondas al IKEv2 ĉe UDP 4443 pro kialo, la profilo havas kampon nomatan Server, vi tajpas la gastigantan nomon kaj la pordon, kaj la telefono raportas, ke ĝi ne povas atingi la servilon aŭ ne povas solvi la adreson. Nenio estas blokata. La denaska formularo de Android atendas gastiganton, kaj same validas ĉe Windows. Propra pordo estas kapablo de la kliento antaŭ ol ĝi estas agordo de la servilo, kaj nur kelkaj klientoj lasas vin esprimi ĝin. Trairu la tri partojn laŭ ordo: kion la kliento povas diri, al kio la servilo aŭskultas, kaj ĉu ambaŭ finoj kadrigas la pakaĵojn same.

Kion la telefono fakte sendis

Ĉeno host:port en kampo destinita por nomo estas solvata kiel nomo. La solvilo redonas nenion por vpn.example.net:4443, kaj la eraro, kiun vi vidas, estas malsukceso de nomsolvado aŭ neatingebleco, ne tempolimo ĉe pordo. Tiu distingo gravas, ĉar reprovo kun pli mallonga nomo aŭ alia reto neniam riparos ĉenon, kiun la formularo ne povas analizi.

La denaska IKEv2-profilo en Android, same kiel la enkonstruita Windows VPN-kliento, estas fiksita al la normaj IKE-pordoj. Neniu el ili montras pordan kampon, kaj nenia profilredaktado aldonas unu. Se la aŭskultilo de la funkciigisto vere estas ĉe 4443, la enkonstruita kliento estas la malĝusta ilo, ne misagordita ilo.

Uzu klienton, kiu montras la pordon

La strongSwan-kliento por Android dokumentas agordeblan servilan pordon en siaj altnivelaj profilagordoj, tial ĝi aperas en preskaŭ ĉiu funkcianta recepto por ĉi tiu dezajno. Tiu subteno apartenas al tiu kliento: alia IKEv2-aplikaĵo, aŭ vendista forko de la sama aplikaĵo, eble ne montras la saman kampon, kvankam la suba strongSwan-demono subtenas ĝin.

Petu de la funkciigisto la tutan aron samtempe: enireja nomo, UDP-pordo, aŭtentiga metodo kaj la servila identeco, kiun la kliento devas atendi. Propra pordo ne estas kialo malŝalti certifikadan kontrolon aŭ ŝanĝi protokolojn. Enigu la pordon tie, kie la instalita kliento atendas ĝin, kaj se tiu kliento ne havas tian kampon, la respondo estas alia aprobita kliento, ne divenita ĉirkaŭvojo.

La servilo havas du pordojn, kaj ambaŭ devas kongrui

IKE komenciĝas ĉe UDP 500, kaj NAT-trapaso kutime movas IKE kaj ĝinkapsulitan ESP al UDP 4500. Tiuj estas apartaj agordoj en strongSwan, do servilo movita al unu propra pordo devas ŝanĝi ambaŭ al la sama valoro:

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

Kun unu pordo por ambaŭ roloj, la demono devas distingi IKE de ESP-en-UDP sur la sama ingo, kion ĝi faras per la kvar-bajta markilo, kiu ne estas ESP kaj antaŭas IKE-mesaĝon. Tial kliento ne povas negocadi ĉe la propra pordo kaj poste silente daŭrigi ĉe 4500, kaj tial la frazo “simple ŝanĝu la pordon” kaŝas postulon pri kadrigo.

Plusendo ne estas aŭskultilo

Plusendi 4443 al ordinara IKE-aŭskultilo estas la malsukcesa modo, kiu aspektas preskaŭ sukcesa. La unua interŝanĝo alvenas, la servilo respondas, kaj poste la konekto haltas aŭ reŝlosilas al nenio, ĉar la respondo eliras el alia pordo kaj la posta ĝinkapsulita trafiko neniam kongruas kun la stato, kiun la du finoj kreis. Regulo, kiu reskribas la celan pordon sen movi la aŭskultilon, produktas ĝuste ĉi tiun duone malfermitan rezulton.

La vojo ankaŭ devas permesi UDP de fino al fino. Tio, ke TCP 443 trapasas hotelan aŭ operatoran reton, diras nenion pri IKEv2 ĉe UDP-pordo, eĉ kun la sama numero. Tie, kie permesatas nur TCP 443, propra UDP-pordo ne igas IKEv2 HTTPS, kaj la ĝusta respondo povas esti alia alirvojo anstataŭ plia porda eksperimento.

Apartigu la tri etapojn kiam vi testas

Kaptu ĉe la servilo dum la kliento provas unufoje. Peto, kiu neniam alvenas, estas demando pri finpunkto aŭ fajroŝirmilo; peto, kiu alvenas sen respondo, estas demando pri aŭskultilo aŭ politiko; respondo, kiun sekvas silento, estas la demando pri kadrigo aŭ identeco.

tcpdump -ni eth0 -vv udp port 4443

Poste legu la mesaĝon de la kliento anstataŭ ĝian turniĝantan indikilon. Propona eraro signifas, ke la algoritmoj ne kongruas, aŭtentiga malsukceso signifas, ke la identecoj aŭ certifikatoj ne kongruas, kaj ripetaj resendoj sen respondo signifas, ke nenio respondas ĉe tiu pordo. Testu unu etapon samtempe kaj ŝanĝu unu kampon inter provoj; la dokumentaro de strongSwan pri NAT-trapaso priskribas la markilon kaj la pordan konduton, kiun la kaptaĵo montras al vi.