Настройка нового VDS, день первый

Вчера после долгих колебаний всё же решился взять второй VDS, о чём впервые задумывался ещё с февраля. Арендовал его на VDSCOM, так как это один из немногих хостеров, где есть дешёвые серверы с безлимитным каналом в 1 Гбит/с. На сервер я планировал перенести своих Telegram-ботов, поднять VPN, а также узлы i2p и yggdrasil. Собственно, такая высокая скорость канала мне ради SiteKnockerBot и требовалась.
И вот наконец-то сервер готов! Зашёл, осмотрелся, и обнаружил, что нет адресов IPv6, хотя я специально подключал IPv6-сеть как дополнительную опцию. И, главное, в панели управления про них тоже ни слова! Пришлось писать в техподдержку. Там сообщили мне эти адреса и дали ссылку, как прописать их в настройках. А потом решили прописать сами и перезагрузили сервер. Я очень удивлялся, когда он внезапно исчез со связи! А ещё у них бардак творится с размером подсети, которую мне дали: на сайте написано, что дают всего /125, в ответе техподдержки было написано /80, а в настройках прописали стандартные /64.
Дальше настроил VPN. Взять и воспользоваться готовым скриптом — это не есть путь Настоящего Компьютерщика, поэтому нашёл инструкцию и стал делать по ней вручную. Но просто взять и настроить — неинтересно, поэтому без приключений не обошлось. Сначала я хотел повесить VPN на tcp-порт 443, чтобы подключение на первый взгляд выглядело как обычный https-запрос. Поставил, протестировал. Вроде заработало, но тут обнаружилось, что хотя адреса IPv6 дали, но обратиться куда-либо вовне не получается: шлюз возвращает «no route to host». Видимо, админы хостинга забыли прописать разрешающее правило на самом шлюзе. Написал в техподдержку ещё раз, но, судя по всему, она отвечает только в рабочее время. (Хе-хе, это у меня вечер и ночь пятницы — пик активности). Так что решение вопроса с IPv6 отложилось до понедельника.
Решил поэкспериментировать, насколько различается VPN с TCP и UDP. Как выяснилось, разница очень существенная, почти в два раза. Решил, что пока всё-таки перейду на UDP. Но держать сервер на UDP-порту 443 как-то глупо, поэтому решил выбрать другой порт. Поменял порт, а также заодно ещё несколько настроек: жёстко задать алгоритмы шифрования и аутентификации, чтобы всё быстрее согласовывашлось на этапе подключения, и уменьшить размер MTU до 1400, чтобы не было фрагментации пакетов при подключении через мобильные сети. И вдруг подключение перестало работать! Стал поштучно отменять каждую из настроек, кроме порта (так как думал, что уж тут-то накосячить негде), но без толку. И только потом вспомнил, что на сервере включён ufw, и нужно прописать правило для подключения к новому порту!
Затем решил перенести ботов. Поскольку прежде делал это уже два раза, опыт был, и перенос удалось выполнить совершенно без проблем и с минимальным простоем: меньше 15 минут. Точнее, эти 15 минут исчезли из логов, но на старом сервере ещё работала мониторинговая часть, которая отправила бы уведомления, если бы возникла такая необходимость. Потом отключил в Яндекс.Облаке виртуальный сервер, где боты были раньше и подумал «ну всё, теперь можно удалить, наверное». Но не стал этого делать. Как оказалось, правильно! Буквально через 10 минут вспомнил, что забыл забрать один файл — настройки sysctl для SiteKnockerBot. Пришлось включать обратно… Причём в облаке при включении/выключении виртуальной машины IP-адрес меняется, но я этого не учёл, и долго пытался сконнектиться на старый по сохранившимся настройкам. И только скопировав тот файл, смог сказать «Прощай, Яндекс.Облако!» Кстати, впечатления от Яндекс.Облака остались противоречивые: с одной стороны, просто отличная скорость каналов (даже на новом VDS чуть ли не на порядок меньше), с другой — отсутствие внешних IPv6-адресов и совершенно грабительские цены — в месяц получалjсь около 800 рублей за сервер с 20% ядра, медленным HDD и 1 Гб оперативки, причём часть из них — за «белый IP» и совершенно ненужную мне услугу «Cloud DNS».
Разобравшись с этим, я решил было попробовать подключиться с Android. Залез в настройки, там множество опций, и совершенно непонятно, что выставлять для подключения именно к OpenVPN. После недолгого поиска выяснилось, что готовой поддержки для OpenVPN в Android нет, и всё-таки придётся ставить приложение. И тут я подумал, что раз приложение придётся ставить по-любому, то почему бы не попробовать WireGuard. (Изначально я от него отказался именно из-за необходимости ставить стороннее приложение.) Сказано — сделано. Но пришлось разбираться ещё и с его настройкой. И тут ждала первая неприятность. Под Linux он попытался собрать модуль ядра, но не смог — не хватило каких-то symbols. Ядро у меня старое и самосборное. Искать, что там нужно включить обратно, и пересобирать ядро не хотелось от слова совсем, ставить второе из дистрибутива и перезагружаться — тем более. Поэтому решил ограничиться тестом на Android. Поставил для него клиентское приложение, далеко не сразу разобрался с настройками, но в итоге запустил. Потестировав, выяснил, что WireGuard реально даёт неплохой выигрыш на WiFi. Скорость загрузки была порядка 50 Мбит/с против 35—40 у OpenVPN. Но когда переключился на 4G-соединение, результат был обратный — OpenVPN стал уверенно выигрывать. В итоге окончательно решил остаться на нём.
Остаток ночи провёл, экспериментируя с различными размерами MTU в попытках выжать из VPN больше скорости. Но особой разницы увидеть не удалось. Ещё попытался было включить TLS-аутентификацию, но безрезультатно. Уж не знаю, что делал не так, но она так и не заработала. Зато поставил yggdrasil. Вот он завёлся сразу! Правда, потратил кучу времени на то, чтобы собрать список хостов и привести к нужному формату. Почему никто не сообразил выложить их в таком виде, чтобы можно было бы просто скопировать в файл настроек?