Miért nem működik az IKEv2 az Androidon nem szabványos UDP-porton

A natív IKEv2 űrlap címet vár, nem portot. Ellenőrizze, hogy az ügyfél támogatja-e, állítsa be a kiszolgáló mindkét portját, majd vizsgálja a keretezést és a naplókat.

Az átjáró okkal válaszol IKEv2-re az UDP 4443-on, a profilban van egy Server nevű mező, beírja a gazdagépnevet és a portot, a telefon pedig azt jelenti, hogy nem éri el a kiszolgálót, vagy nem tudja feloldani a címet. Semmit nem blokkol a rendszer. Az Android natív űrlapja gazdagépet vár, és ugyanez igaz Windows alatt is. Az egyéni port az ügyfél képessége, mielőtt kiszolgálóbeállítás lenne, és csak néhány ügyfél engedi kifejezni. Járja végig a három részt sorrendben: mit mondhat az ügyfél, mire figyel a kiszolgáló, és hogy mindkét vég ugyanúgy keretezi-e a csomagokat.

Mit küldött valójában a telefon

A névre szánt mezőben lévő host:port karakterlánc névként oldódik fel. A feloldó semmit nem ad vissza a vpn.example.net:4443 értékre, és a látott hiba névfeloldási vagy elérhetetlenségi hiba, nem porton bekövetkező időtúllépés. Ez a különbség számít, mert egy rövidebb névvel vagy más hálózattal való újrapróbálkozás soha nem javít egy olyan karakterláncot, amelyet az űrlap nem tud elemezni.

Az Android natív IKEv2-profilja, akárcsak a beépített Windows VPN-ügyfél, a szabványos IKE-portokhoz van rögzítve. Egyik sem mutat portmezőt, és semmilyen profil szerkesztése nem ad hozzá egyet. Ha az üzemeltető figyelője valóban a 4443-on van, a beépített ügyfél a rossz eszköz, nem pedig rosszul beállított.

Használjon olyan ügyfelet, amely megmutatja a portot

A strongSwan Android-ügyfele konfigurálható kiszolgálóportot dokumentál a speciális profilbeállításokban, ezért szinte minden működő receptben szerepel ehhez a kialakításhoz. Ez a támogatás ahhoz az ügyfélhez tartozik: egy másik IKEv2-alkalmazás vagy ugyanazon alkalmazás gyártói elágazása lehet, hogy nem mutatja ugyanazt a mezőt, pedig az alapul szolgáló strongSwan-démon támogatja.

Kérje el az üzemeltetőtől a teljes készletet egyszerre: átjárónév, UDP-port, hitelesítési módszer és a kiszolgáló identitása, amelyre az ügyfélnek számítania kell. Az egyéni port nem ok a tanúsítványellenőrzés kikapcsolására vagy a protokollok váltására. Írja be a portot oda, ahol a telepített ügyfél várja, és ha annak az ügyfélnek nincs ilyen mezője, a válasz egy másik jóváhagyott ügyfél, nem pedig kitalált kerülőút.

A kiszolgálónak két portja van, és mindkettőnek egyeznie kell

Az IKE az UDP 500-on indul, és a NAT-átjárás általában az UDP 4500-ra helyezi az IKE-t és a beágyazott ESP-t. Ezek külön beállítások a strongSwanban, ezért az egyetlen egyéni portra áthelyezett kiszolgálónak mindkettőt ugyanarra az értékre kell állítania:

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

Ha egy port szolgálja mindkét szerepet, a démonnak ugyanazon a socketen meg kell különböztetnie az IKE-t az ESP-in-UDP-től, amit a négybájtos, nem ESP jelölővel tesz, amely megelőzi az IKE-üzenetet. Ezért az ügyfél nem tárgyalhat az egyéni porton, majd folytathatja csendben a 4500-on, és ezért rejt a „csak cserélje ki a portot” mondat keretezési követelményt.

Az átirányítás nem figyelő

A 4443 átirányítása egy közönséges IKE-figyelőre az a hibaállapot, amely majdnem sikeresnek látszik. Az első csere megérkezik, a kiszolgáló válaszol, majd a kapcsolat megakad vagy kulcsokat újít a semmibe, mert a válasz másik portról indul, és a későbbi beágyazott forgalom soha nem egyezik a két vég által létrehozott állapottal. Az a szabály, amely átírja a célportot anélkül, hogy elmozdítaná a figyelőt, pontosan ezt a félig nyitott eredményt adja.

Az útvonalnak UDP-t is engednie kell végponttól végpontig. Az, hogy a TCP 443 átjut egy szállodai vagy szolgáltatói hálózaton, semmit nem mond az IKEv2-ről UDP-porton, még azonos sorszám mellett sem. Ahol csak a TCP 443 engedélyezett, ott az egyéni UDP-port nem teszi HTTPS-sé az IKEv2-t, és a helyes válasz inkább egy másik hozzáférési útvonal lehet, mint egy újabb portkísérlet.

Teszteléskor válassza szét a három szakaszt

Rögzítsen a kiszolgálón, miközben az ügyfél egyszer próbálkozik. A soha meg nem érkező kérés végpont- vagy tűzfal-kérdés; a válasz nélkül megérkező kérés figyelő- vagy házirend-kérdés; a csenddel követett válasz a keretezés vagy az identitás kérdése.

tcpdump -ni eth0 -vv udp port 4443

Ezután az ügyfél üzenetét olvassa, ne a pörgő jelzőjét. A javaslathiba azt jelenti, hogy az algoritmusok nem egyeznek, a hitelesítési hiba azt jelenti, hogy az identitások vagy a tanúsítványok nem egyeznek, az ismételt, válasz nélküli újraküldések pedig azt, hogy semmi nem válaszol azon a porton. Egyszerre egy szakaszt teszteljen, és a kísérletek között egy mezőt változtasson; a strongSwan NAT-átjárásról szóló dokumentációja leírja a jelölőt és a port viselkedését, amelyet a rögzítés mutat.

Kapcsolódó cikkek