Зошто IKEv2 на Android не работи на нестандарден UDP порт

Изворниот IKEv2 образец прима адреса, а не порт. Проверете дали клиентот го поддржува, поставете ги двата порта на серверот, потоа погледнете рамкирањето и дневниците.

Порталот одговара на IKEv2 на UDP 4443 со причина, профилот има поле наречено Server, внесувате име на домаќин и порт, а телефонот известува дека не може да го достигне серверот или не може да ја реши адресата. Ништо не се блокира. Изворниот образец на Android очекува домаќин, и истото важи на Windows. Прилагодениот порт е можност на клиентот пред да биде поставка на серверот, и само некои клиенти ви дозволуваат да го изразите. Поминете ги трите дела по ред: што може да каже клиентот, на што слуша серверот и дали двата краја ги рамкираат пакетите на ист начин.

Што всушност испрати телефонот

Низата host:port во поле наменето за име се решава како име. Решавачот не враќа ништо за vpn.example.net:4443, а грешката што ја гледате е неуспех при решавање на име или недостапност, а не истекување на време на порт. Таа разлика е важна, бидејќи повторувањето со покусо име или друга мрежа никогаш нема да ја поправи низата што образецот не може да ја анализира.

Изворниот IKEv2 профил на Android, како и вградениот Windows VPN клиент, е фиксиран на стандардните IKE портови. Ниту еден од нив не прикажува поле за порт, и никакво уредување на профилот не додава такво. Ако слушателот на операторот навистина е на 4443, вградениот клиент е погрешен алат, а не погрешно конфигуриран.

Користете клиент што го прикажува портот

Клиентот strongSwan за Android документира конфигуриран серверски порт во напредните поставки на профилот, затоа се појавува во речиси секој работен рецепт за овој дизајн. Таа поддршка му припаѓа на тој клиент: друга IKEv2 апликација или доставувачка гранка на истата апликација може да не го прикажува истото поле, иако основниот strongSwan демон го поддржува.

Побарајте од операторот целиот сет одеднаш: име на порталот, UDP порт, метод на автентикација и идентитетот на серверот што клиентот треба да го очекува. Прилагодениот порт не е причина да ја исклучите проверката на сертификати или да ги смените протоколите. Внесете го портот таму каде што го очекува инсталираниот клиент, и ако тој клиент нема такво поле, одговорот е друг одобрен клиент, а не претпоставено заобиколување.

Серверот има два порта, и двата мора да се совпаѓаат

IKE започнува на UDP 500, а NAT преминот обично ги преместува IKE и инкапсулираниот ESP на UDP 4500. Тоа се одделни поставки во strongSwan, па сервер преместен на еден прилагоден порт мора да ги смени двата на иста вредност:

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

Кога еден порт служи за двете улоги, демонот мора да го разликува IKE од ESP-in-UDP на истиот сокет, што го прави преку четирибајтниот маркер што не е ESP и што претходи на IKE порака. Затоа клиентот не може да преговара на прилагодениот порт и потоа тивко да продолжи на 4500, и затоа фразата „само сменете го портот“ крие барање за рамкирање.

Пренасочувањето не е слушател

Пренасочувањето на 4443 кон обичен IKE слушател е режимот на неуспех што изгледа речиси успешен. Првата размена пристигнува, серверот одговара, а потоа врската запира или ги обновува клучевите во ништо, бидејќи одговорот излегува од друг порт и подоцнежниот инкапсулиран сообраќај никогаш не се совпаѓа со состојбата што ја создале двата краја. Правило што го препишува одредишниот порт без да го премести слушателот дава точно овој полуотворен резултат.

Патеката мора да дозволува и UDP од крај до крај. Тоа што TCP 443 поминува низ хотелска или операторска мрежа не кажува ништо за IKEv2 на UDP порт, дури и со ист број. Таму каде што е дозволен само TCP 443, прилагодениот UDP порт не го претвора IKEv2 во HTTPS, и точниот одговор може да е друг пристапен пат, а не уште еден експеримент со порт.

Одвојте ги трите фази при тестирање

Снимајте на серверот додека клиентот се обидува еднаш. Барањето што никогаш не пристигнува е прашање на крајна точка или огнен ѕид; барањето што пристигнува без одговор е прашање на слушател или политика; одговорот по кој следи тишина е прашањето за рамкирање или идентитет.

tcpdump -ni eth0 -vv udp port 4443

Потоа читајте ја пораката на клиентот, а не неговиот вртлив показател. Грешка во предлогот значи дека алгоритмите не се совпаѓаат, неуспех при автентикација значи дека идентитетите или сертификатите не се совпаѓаат, а повторените препраќања без одговор значат дека ништо не одговара на тој порт. Тестирајте една фаза одеднаш и менувајте едно поле меѓу обидите; документацијата на strongSwan за NAT преминот ги опишува маркерот и однесувањето на портот што ви ги покажува снимката.

Поврзани статии