xl2tpd/strongSWAN и несколько клиентов за одним NAT

Что-то где-то не допилено с вашей стороны. Сейчас проверил ради интереса. Сервак Strongswan+xl2tpd. Два клиента за одним nat, все работает как и должно быть.
У вас случайно клиентам не одинаковый ip выдается?

Хм. Не могу выложить мои оригинальные конфиги, так как снес тот сервак и сейчас пытаюсь уломать заказчика на OpenVPN. Попробую настроить все заново. xl2tpd точно выдавал разные IP, там были два разных пользователя в ppp-secrets. А что за версии xl2tpd и StrongSWAN используете? Плагин connmark включен? IPSec-клиенты идентифицируются по паролю или сертификатам?

Вот набросал примерно предыдущий конфиг, но результат тот же - SA создаются, L2TP мучительно пытается подключиться (в логах флуд про «tty is not open yet», «bad control packet» и пакеты «out of order». Клиенты, если что, два роутера Mikrotik с последней RouterOS. По отдельности каждый подключается, а вместе - никак.

connmark не включал, так как он багует в strongSwan<5.6 (что-то там с правами в iptables), а у меня из коробки в дебиане только 5.5.1. В прошлый раз вручную собирал последний релиз с connmark, но картина была довольно похожая.

# /etc/ipsec.secrets
 : PSK "secret"

# /etc/ipsec.conf
config setup
        # strictcrlpolicy=yes
        # uniqueids = no

conn test
        type=transport
        esp=aes128-sha256
        ike=aes128-sha256-modp1024
        keyexchange=ikev1
        left=185.117.153.210/32
        leftsubnet=185.117.153.210/32[udp/1701]
        leftauth=psk
        rightsubnet=0.0.0.0/0[udp/1701]
        rightauth=psk
        # mark=%unique
        auto=start

include /var/lib/strongswan/ipsec.conf.inc

# /etc/xl2tpd.conf
[lns default]
ip range = 172.16.0.1-172.16.0.254
local ip = 172.16.0.1
refuse chap = yes
refuse pap = yes
require authentication = yes
name = ServerName
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

# /etc/ppp/options.xl2tpd
require-mschap-v2
noccp
auth
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
proxyarp
connect-delay 5000

# /etc/ppp/chap-secrets
client1         *       password1               172.16.0.2
client2         *       password2               172.16.0.3

Вывод «ipsec status»

Security Associations (2 up, 0 connecting):
        test[24]: ESTABLISHED 3 seconds ago, 185.117.153.210[185.117.153.210/32]...178.78.38.16[10.77.77.12]
        test{23}:  INSTALLED, TRANSPORT, reqid 2, ESP in UDP SPIs: c4f9b802_i 08a9158b_o
        test{23}:   185.117.153.210/32[udp/l2f] === 178.78.38.16/32[udp/l2f]
        test[23]: ESTABLISHED 63 seconds ago, 185.117.153.210[185.117.153.210/32]...178.78.38.16[10.77.77.13]
        test{22}:  INSTALLED, TRANSPORT, reqid 2, ESP in UDP SPIs: c0210d78_i 07793559_o
        test{22}:   185.117.153.210/32[udp/l2f] === 178.78.38.16/32[udp/l2f]

48: ppp0: <POINTOPOINT,MULTICAST,NOARP> mtu 1410 qdisc noop state DOWN group default qlen 3
    link/ppp
49: ppp1: <POINTOPOINT,MULTICAST,NOARP> mtu 1410 qdisc noop state DOWN group default qlen 3
    link/ppp

Проверил еще раз, теперь в варианте двойного nat, все работает.
Точкой доступа для клиентов использовал blackberry q10, опсос МТС. Т.е. получаеться первый nat на bb, потом второй nat у опсоса.
Три клиента, два мака и один ямобилка.

ppp-secrets

Эмм а почему не chap-secrets ?

А что за версии xl2tpd и StrongSWAN используете?

strongSwan - 5.3.5
xl2tpd - 1.3.2

Плагин connmark включен?

Это вы о чем? Не совсем понял о каком плагине речь.

IPSec-клиенты идентифицируются по паролю или сертификатам?

PSK
Но если интересно, на том же сервере у меня есть вариант без l2tp, только по сертификатам, тоже проверил, правда только на двух устройствах, ямобила и один из маков, в тех же условиях все работает.

В прошлый раз вручную собирал последний релиз

У меня слака, собирал из slackbuild добавив ключи к ./configure

./configure \
  --prefix=/usr \
  --libdir=/usr/lib${LIBDIRSUFFIX} \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --mandir=/usr/man \
  --docdir=/usr/doc/$PRGNAM-$VERSION \
  --enable-shared \
  --disable-static \
  --enable-xauth-noauth \
  --enable-swanctl \
  --with-urandom-device=/dev/urandom \
  --with-random-device=/dev/urandom \
  --enable-openssl \
  --enable-farp \
--enable-test-vectors \
--enable-curl \
--enable-ldap \
--enable-agent \
--enable-pkcs11 \
--enable-ctr \
--enable-ccm \
--enable-gcm \
--enable-farp \
--enable-dhcp \
--enable-led \
--enable-addrblock \
--enable-socket-dynamic \
  --build=$ARCH-slackware-linux

        leftprotoport=17/1701
        rightprotoport=17/%any

17 - это на самом деле udp.
Наискосок, в этом у вас проблема. Два занатных клиента не смогут работать по одному порту, поэтому и %any а не 1701.

Собстно у вас так и есть

test{23}: 185.117.153.210/32[udp/l2f] === 178.78.38.16/32[udp/l2f]
test{22}: 185.117.153.210/32[udp/l2f] === 178.78.38.16/32[udp/l2f]

Эмм а почему не chap-secrets ?

Да, ошибся, там chap-secrets.

Это вы о чем? Не совсем понял о каком плагине речь.

Вот об этом. Судя по описанию, это как раз то, что доктор прописал, специально для моего случая, но не работает даже с ним. Впрочем, последний абзац на той же странице намекает, что для виндового L2TP это и не должно работать по причине постоянного использования порта 1701 для исходящих клиентских подключений. Видимо, Mikrotik занимается тем же самым (судя по CHILD_SA, которые я скидывал, да и у них на форуме этот вопрос поднимался).

А вот маки и iOS как раз используют случайный порт для исходящего подключения, поэтому вам и требуется %any в качестве порта. Как следствие, данной проблемы не наблюдается. Мне же %any ничем не поможет, так как исходящее подключение начинается на одном и том же порту. NAT уже разруливает udp на 4500 и 500 портах, так как L2TP через него проходит уже энкапсулированным, но для сервака, когда он достает трафик из IPSec, конечный порт все равно 1701.

Сдается мне, что IPSec тут бессилен, по крайней мере на микротиках в связке с strongSWAN+xl2tpd.

Хм. Интересно. Чего это routerOS не дает изменить порт l2tp. Ранее забыл написать, на linux (как клиент) я прописываю специально другой порт. А вот винду, каюсь, не гонял, может и правда так и есть.
А вам вообще принципиально +l2tp? Одного ipsec не хватит?
ЗЫ Blackberry тоже рандомный порт пользует.

Упс, насчет bb нагнал как троцкий, у него же нет l2tp, простите :(

Я пытался подменить порт в RouterOS через src-nat. Пакеты в mangle маркировались корректно, но через правило с подменой порта в NAT не проходили (видимо IPSec хавал их раньше).

А вам вообще принципиально +l2tp? Одного ipsec не хватит?

Вообще, не принципиально (хотя возможно и необходимо для данного сетапа). Заказчик хочет IPSec, насчет туннелей это чисто моя задумка (я как-то привык к PPTP).

Давайте опишу подробнее. Подключение юзверских клиентов (типа телефонов и ПК) к этой сети не планируется, только роутеры Mikrotik и, возможно, какой-нибудь линушный gateway. Ультимативная цель - собрать VPN с шифрованием, чтобы софт на VPN-сервере имел возможность опрашивать по TCP оборудование, находящееся в сетях за роутерами. Роутеры выходят в инет через 3G-модемы со всеми вытекающими прелестями. Ну и, желательно, чтобы клиенты все друг друга видели (можно было попасть из одной сети в другую).

Итого, как я понимаю, тоннели так или иначе мне нужны. Возможно, не L2TP, но тогда что?

Немного запутано описали. Опишу как понял я. Есть сеть в которой есть сервер VPN (без разницы какой). Задача. Подключаться к этой сети из других мест используя в качестве клиентов Микротик или linux. В этих «других» местах есть свои сети. Нужно обьединение сетей. Если все верно то:
1. ipsec без всяких лишних l2tp вполне подходит
2. Но у вас нюанс «Роутеры выходят в инет через 3G-модемы со всеми вытекающими прелестями» я бы тут больше склонился к варианту ovpn.
2.1 Но опять-таки зависит от общей загрузки. Хотя выше вы упоминали pptp это имхо будет худший вариант (про безопасность не говорим), не смотря на ядручесть.
3. «чтобы клиенты все друг друга видели (можно было попасть из одной сети в другую)» - Звезда? Все ко всем? меш сеть? Каждый вариант надо рассматривать отдельно.

Накидал небольшую схемку для наглядности. https://imgur.com/1QnFBOj

Есть несколько роутеров, со своими сетями (192.168.х.0/24), которые выходят в инет через 3G. В каждой такой сети есть сервер приложения, который необходимо опрашивать с центрального сервера 9.9.9.9. За 9.9.9.9 нет никакой сети, это просто арендуемая VDSка. Первая проблема - опросить напрямую не выйдет, так как NAT и динамические IP для роутеров.

Соответственно, роутеры сами должны стучаться на сервер 9.9.9.9 и устанавливать какой-нибудь VPN тоннель, чтобы 9.9.9.9 имел возможность опрашивать сервера в сетях 192.168.х.0/24. Плюс, раз уж есть VPN, можно подключать ПК айтишников, так как им иногда необходимо влезть в 192.168.х.0/24 удаленно.

Насчет моего 3 пункта «клиенты друг друга видели» - я имел в виду возможность безгеморройной маршрутизации на стороне 9.9.9.9, чтобы сидя в 192.168.1.0/24 можно было ходить в другие 192.168.х.0/24 через VPN-сервак (звездой).

Трафика через VPN будет ходить не слишком чтобы много (мобильные сети особо и не позволят разогнаться). 5-10 кб/сек на опрос + периодически одна VNC 800х600.

Сейчас данная сеть живет на PPTP, но безопасники сказали прикрыть эту дырявую лавочку и заменить ее на что-нибудь с нормальным шифрованием, предложили IPSec.

ipsec без всяких лишних l2tp вполне подходит

IPSec, насколько я понял, работает «по запросу» - если есть исходящее соединение, которое удовлетворяет условиям в конфиге, то шифруем его, иначе ничего не делаем. Если бы у роутеров была белая статика, то проблем с IPSec не было бы. А так получается роутер сам должен инициировать подключение, по которому потом 9.9.9.9 будет обращаться к роутеру (ну или к сети за ним). IPSec так, по-моему, не умеет (может я чего-то не знаю).

Насчет OpenVPN. Увы, реализация ovpn в микротике весьма кастрирована - поддерживается только TCP и нет сжатия. В добавок, в 2010м микротик официально объявили о прекращении работы над реализацией ovpn в угоду SSTP. Так что я в сомнениях. Можно посмотреть в сторону SSTP, но я о нем мало что слышал.

IPSec, насколько я понял, работает «по запросу»...

Наискосок как вижу, поставить aggressive и периодическую пинговалку запускать с «сервера приложения» (ну или микротика если позволит правильно).
Вообще какой бы тунель не был, один фиг за ним следить надо что бы перезапускался.