klink0v | Про StrongSWAN и Openconnect (Reply)

... Известные РосКозлы и Негодяи обычно обновляют прошивки на своих ТЬФУ в пятницу вечером по Москве. Так что в субботу у меня отъехал беспамятный страж проволоки. Вообще, удивительно что только сейчас, потому что с того хостинга (OVH) даже обычные HTTP и HTTPS перестали работать очень-очень давно.

Но как ни странно, имеет значение направление установления соединения если протокол несимметричный. Так что "туда" может и "не алё", а вот в обратную сторону иногда очень даже копенгаген. Есть одна штука, которая по сути своей есть HTTPS, и имя ей Openconnect. Так что решил попробовать.

Общие впечатления: штука корявая и глюкавая. По качеству кода, дизайну и полноте документации до того же OpenVPN-а ей как до Луны пешком. Но от чего меня реально бомбануло — он не работает поверх IPv6. Нет, чисто номинально такой функционал имеется. И между соседними виртуалками на одной хост-машине всё замечательно бегает. Но вот в реальной сети — до первого packet reorder. Дальше идет какой-то совершенно неинформативный отлуп вида "main-worker-cmd.c:351: worker process invalid MTU -18" и клиент отлетает. Причем, это не связано с проблемами на сети. Я упоролся и таки сравнил дампы трафика с двух сторон: потерь пакетов нет. Это именно какой-то косяк в логике то ли клиента, то ли сервера. По-хорошему бы зарепортить авторам, не знаю дойдут ли руки.

На практике это выглядит так, что подключенный клиент работает некий случайный промежуток времени от полминуты до пары часов, потом получает "давайдосвиданья" от сервера и завершается с ошибкой. Если перезапустить, то подключается и работает ещё некоторое время. И так далее. В конце концов я плюнул, перевесил линк на IPv4 и проблема ушла.

Другой неприятный косяк Openconnect-а: он как-то не отрабатывает Path MTU Discovery на своих виртуальных TUN-интерфейсах. Ни со стражем проволоки, ни с OpenVPN-ом у меня таких неприятностей ни разу не было. А этот вроде бы и шлёт "Frag needed and DF set", но почему-то на TCP MSS это никак не влияет. Может я конечно что-то неверно понимаю или что-то не так делаю. Но пришлось лапами в nftables эти TCPMSS подкручивать, а то толстый payload начинал дико тупить.

Ещё одна попа-боль — это создание отдельного PtP-интерфейса под каждого клиента. Ну зачем? Зачем, Карл? Неужели нельзя всё через один интерфейс разрулить, как это делают те же самые OpenVPN и StrongSWAN? Ну возьмите же ж вы оттуда прям готовый код, они все открытые!

В общем, вердикт: как-то работает, и ладно. Я сперва думал контору на него переводить. Но теперь чё-то засомневался, а стоит ли. Радиус кривизны у него прям несравнимо круче, чем и у того же OpenVPN-а, и у StrongSWAN-а. Чувствую, если меня сильно выбесить, схожу на курсы по "плюсам" и запилю свою собственную реализацию ISAKMP поверх HTTPS для OpenVPN, бггг. Переизобрету велосипед наподобие Ultra Horizon. Те редиски свою балалайку чё-то забросили.

... Нашел свою старую ошибку в конфиге StrongSWAN-а. Долго не понимал, почему у меня периодически переставал ходить трафик с мобильного клиента до тех пор пока не переподключусь. Грешил на NAT-ы ОПСОСов. Но всё оказалось проще: в multi-client конфиге ни в коем случае нельзя прописывать "remote_ts". Иначе следующий подключившийся заберет на себя xfrm policy, а все предыдущие хоть и не отвалятся, но останутся ни с чем. И "local_addrs" лучше тоже не указывать, особенно если хочется Dual-Stack (IPv4+IPv6) на одном инстансе. Так можно, да.

Таким образом, правильный рабочий конфиг для multi-client StrongSWAN выглядит вот так. Пользуйтесь кому надо.

guestras {
    version = 2
    proposals = aes256gcm16-prfsha384-ecp256
    if_id_in = 101
    if_id_out = 101
    rekey_time=8h
    pools = pool_v4, pool_v6
    send_cert = always

    local {
        certs = "серверный_сертификат.crt"
        id = @foo.staser.ru
        auth=pubkey
     }

    remote {
        auth=pubkey
     }

     children {
        guestras-phase2 {
            esp_proposals = aes256gcm16
            rekey_time = 1h
            mode = tunnel
            start_action = none
            local_ts  = 0.0.0.0/0,::0/0
         }
     }
}

В качестве "серверный_сертификат.crt" можно использовать тот же Lets Encrypt, только в DNS Alternative Name должен быть правильный домен указан, который соответствует действительности и совпадает с содержимым директивы "id =" в конфиге. А вот клиентам сертификатики придется сгенерировать самостоятельно при помощи какого-нибудь easy-rsa и раздать всем желающим. Я сам именно так цепляюсь к своему антресольному серверу дома, мне нравится.

... И немного новостей из перевернутого мира.

Я каким-то непостижимым образом то ли умудрился высосать за месяц два терабайта трафика, то ли это OpenWRT брешет, то ли меня кто-то дудосит. Не знаю.

Налоговая зачебурнетилась. Из России её DNS-зона ресолвится, из остального мира — только из Испании почему-то. Гугол (четыре восьмерки) адрес "lkfl2.nalog.ru" тоже не может отдать. В субботу похожим образом падали DNS-ы у МИФИ, но к понедельнику починились. Совпадение?