Miksi IKEv2 epäonnistuu Androidissa epästandardilla UDP-portilla

Natiivi IKEv2-lomake ottaa osoitteen, ei porttia. Varmista, että asiakas tukee sitä, aseta palvelimen molemmat portit ja tarkastele sitten kehystystä ja lokeja.

Yhdyskäytävä vastaa IKEv2:een UDP 4443:ssa syystä, profiilissa on Server-niminen kenttä, kirjoitat isäntänimen ja portin, ja puhelin ilmoittaa, ettei se tavoita palvelinta tai ei pysty selvittämään osoitetta. Mitään ei estetä. Androidin natiivi lomake odottaa isäntää, ja sama pätee Windowsissa. Mukautettu portti on asiakkaan ominaisuus ennen kuin se on palvelimen asetus, ja vain jotkin asiakkaat antavat ilmaista sen. Käy kolme osaa järjestyksessä läpi: mitä asiakas voi sanoa, mitä palvelin kuuntelee ja kehystävätkö molemmat päät paketit samalla tavalla.

Mitä puhelin todella lähetti

Nimelle tarkoitettuun kenttään kirjoitettu host:port-merkkijono selvitetään nimenä. Selvittäjä ei palauta mitään vpn.example.net:4443 kohdalle, ja näkemäsi virhe on nimen selvityksen tai tavoitettavuuden virhe, ei portin aikakatkaisu. Tällä erolla on väliä, koska lyhyemmällä nimellä tai toisella verkolla yrittäminen ei koskaan korjaa merkkijonoa, jota lomake ei osaa jäsentää.

Androidin natiivi IKEv2-profiili on Windowsin sisäänrakennetun VPN-asiakkaan tapaan sidottu tavallisiin IKE-portteihin. Kumpikaan ei näytä porttikenttää, eikä mikään profiilin muokkaus lisää sellaista. Jos operaattorin kuuntelija todella on portissa 4443, sisäänrakennettu asiakas on väärä työkalu, ei väärin konfiguroitu.

Käytä asiakasta, joka näyttää portin

strongSwanin Android-asiakas dokumentoi määritettävän palvelinportin profiilin lisäasetuksissa, siksi se esiintyy lähes jokaisessa toimivassa ohjeessa tähän ratkaisuun. Tuki kuuluu juuri sille asiakkaalle: toinen IKEv2-sovellus tai saman sovelluksen toimittajahaarauma ei välttämättä näytä samaa kenttää, vaikka taustalla oleva strongSwan-daemon tukee sitä.

Pyydä operaattorilta koko sarja kerralla: yhdyskäytävän nimi, UDP-portti, todennusmenetelmä ja palvelimen identiteetti, jota asiakkaan on odotettava. Mukautettu portti ei ole syy kytkeä varmenteen tarkistusta pois tai vaihtaa protokollia. Syötä portti sinne, missä asennettu asiakas sitä odottaa, ja jos sillä asiakkaalla ei ole sellaista kenttää, vastaus on toinen hyväksytty asiakas, ei arvattu kiertotie.

Palvelimella on kaksi porttia, ja molempien on täsmättävä

IKE alkaa UDP 500:sta, ja NAT-läpäisy siirtää yleensä IKE:n ja kapseloidun ESP:n UDP 4500:aan. Ne ovat strongSwanissa erillisiä asetuksia, joten yhdelle mukautetulle portille siirretty palvelin tarvitsee molemmat samaan arvoon:

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

Kun yksi portti palvelee molempia rooleja, daemonin on erotettava IKE saman pistokkeen ESP-in-UDP:stä, minkä se tekee nelitavuisella merkitsimellä, joka ei ole ESP ja joka edeltää IKE-viestiä. Siksi asiakas ei voi neuvotella mukautetulla portilla ja jatkaa sitten hiljaa portissa 4500, ja siksi lause “vaihda vain portti” kätkee kehystysvaatimuksen.

Uudelleenohjaus ei ole kuuntelija

Portin 4443 uudelleenohjaus tavalliselle IKE-kuuntelijalle on se vikatila, joka näyttää melkein onnistuneelta. Ensimmäinen vaihto saapuu, palvelin vastaa, ja sitten yhteys pysähtyy tai avaa avaimet uudelleen tyhjyyteen, koska vastaus lähtee toisesta portista eikä myöhempi kapseloitu liikenne koskaan vastaa tilaa, jonka molemmat päät loivat. Sääntö, joka kirjoittaa kohdeportin uudelleen siirtämättä kuuntelijaa, tuottaa juuri tämän puoliavoimen tuloksen.

Polun on myös sallittava UDP päästä päähän. Se, että TCP 443 pääsee hotellin tai operaattorin verkosta läpi, ei kerro mitään IKEv2:sta UDP-portilla, ei edes samalla numerolla. Siellä, missä vain TCP 443 on sallittu, mukautettu UDP-portti ei tee IKEv2:sta HTTPS:ää, ja oikea vastaus voi olla toinen käyttöpolku eikä uusi porttikoe.

Erottele kolme vaihetta testatessasi

Tallenna palvelimella, kun asiakas yrittää kerran. Pyyntö, joka ei koskaan saavu, on päätepisteen tai palomuurin kysymys; pyyntö, joka saapuu ilman vastausta, on kuuntelijan tai käytännön kysymys; vastaus, jota seuraa hiljaisuus, on kehystyksen tai identiteetin kysymys.

tcpdump -ni eth0 -vv udp port 4443

Lue sitten asiakkaan viesti sen pyörivän ilmaisimen sijaan. Ehdotusvirhe tarkoittaa, että algoritmit eivät täsmää, todennusvirhe tarkoittaa, että identiteetit tai varmenteet eivät täsmää, ja toistuvat uudelleenlähetykset ilman vastausta tarkoittavat, ettei mikään vastaa sillä portilla. Testaa yhtä vaihetta kerrallaan ja vaihda yhtä kenttää yritysten välillä; strongSwanin dokumentaatio NAT-läpäisystä kuvaa merkitsimen ja portin käyttäytymisen, jotka tallenne näyttää sinulle.

Aiheeseen liittyvät artikkelit