Fencing 12 June 2025
Jul. 12th, 2025 10:33 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Разобрался тут, как использовать опцию -w у ssh. Надо будет в рассказку дописать.
Токен %T в LocalCommand вполне работает. А на серверной стороне у команды которая передана в командной строке ssh есть переменная среды SSH_TUNNEL.
Получилось следующее:
```
# !/bin/sh
# Config file for ssh vpn
# DNS name of server to connect to (required)
SERVER=example.com
# IP of this computer in VPN (required)
MY_IP=192.168.217.194
# IP of server in VPN (required)
SERVER_IP=192.168.217.193
# network to route via server (optional)
NET=192.168.217.128/25
# Port for dynamic port forwarding (optional)
SOCKS_PORT=1080
```
SERVER - это имя сервера куда ходить по ssh в открытом интернете. А MY_IP и SERVER_IP - "серые" адреса внутри vpn. SOCKS_PORT - это чтобы не держать отдельной ssh-сессии для ssh -D, NET - это если нам сеть нужна не для обхода блокировок. а как виртуальная частная сеть, объединяющая наши компьютеры, вошедшие в интернет через разных провайдеров. На каждом клиенте для рута генерируется ключевая пара ssh и открытый ключ помещается руту на сервер.
На этом настройка заканчивася. Дальше запускаем sshvpn, оно устанавливает соединение и voila.
Скрипт sshvpn имеет следующий вид:
#!/bin/sh
if [ "$(id -u)" -ne 0 ]; then
sudo "$0"
exit "$?"
fi
if ! [ -f /etc/ssh/vpn.conf ]; then
echo "No /etc/ssh/vpn.conf found"
exit 1
fi
. /etc/ssh/vpn.conf
ssh -w "any:any" -o LocalCommand="sshnetclient %T" ${SOCKS_PORT:+-D "localhost:$SOCKS_PORT" }"$SERVER" sshnetsetup "$MY_IP"
Собственно интересны тут две последние строчки - прочитать конфиг и запустить ssh c кучей параметров из этого конфига. На клиенте в резулаьте выполнится следующий скрипт
#!/bin/sh
. /etc/ssh/vpn.conf
DEVICE="$1"
ip addr add dev "$DEVICE" local "$MY_IP" peer "$SERVER_IP"
ip link set "$DEVICE" up
[ -n "$NET" ] && ip route add "$NET" via "$SERVER_IP"
Он прочитает тот же конфиг и сконфигурирует интерфейс, имя которого ему передано в командной строке через токен %T (см раздел TOKENS в man ssh_config)
На сервере выполняется вот такой скрипт:
#!/bin/sh
client=$1
if [ -z "$client" ]; then
client="${SSH_ORIGINAL_COMMAND##* }"
fi
ip addr add 192.168.217.193 peer $client dev $SSH_TUNNEL
ip link set $SSH_TUNNEL up
# now wait until other side would break connection
cat
Он конфигурирует интерфпейс указанный в переменной среды SSH_TUNNEL в переданный ему в командной строке из клиентского sshvpn IP-адрес, а потом запускает команду cat, т.е. ждет ввода на stdin до упора. Пока SIGINT не прилетит. Если в authorized_keys мы пропишем command=/usr/local/bin/sshnetsetup, то параметр $MY_IP sshd в скрипт не передаст. Зато засунет оригинальную команду в SSH_ORIGINAL_COMMAND, откуда этот адрес мы и выкусываем. Особые параноики могут там использовать какой-нибудь sed, чтобы убедиться что ORIGINAL_COMMAND это действительно sshnetsetup ip-address.
При таком сетапе, когда IP-адреса клиентам назначаются явным образом и прописываются на клиентах же в конфиг, нет необходимости что-то делать с динамическим DNS можно всех клиентов статически прописать.
Теперь бы еще разобраться как совместить это дело с SessionType=none (aka -N) и RemoteCommand.
У ssh есть, как известно, ключик -w который позволяет аллоцировать на обоих концах виртуальный сетевой интерфейс и гонять через свое ssh-соединение любой траффик.
К сожалению никакого удобного сервиса, аналогичного тому что есть почти у всех прочих фич ssh вокруг этой опции не сложилось.
Получается следующее
Соответсвенно встает задача как организовать работу по схеме "звезда". Т.е. когда есть n девайсов, которые могут ходить по ssh на некий центральный сервер, и данный сервер должен им устроить полноценную виртуальную сеть, вне зависимости от того, сколько из них и в каком порядке пришли. Полноценную, это значит что они видят не только сервер и выполняющиеся на нем серверные процессы (dovecot, postfix, http-proxy), но и друг друга. Поичем друг друга полноценным способом.
Ну собственно, очевидный вариант - прописать каждому девайсу при его настройке номер tun-интерфейса, который оно должно запрашивать на сервере, а дальше в зависимости от этого номера плясатьj, назначая IP.
Интерфейс у них там по умолчанию point-to-point но можно включить режим ethernet. Правда не совсем понятно есть ли в этом хоть какой-то смысл.
Этот вариант мне не нравится, но сойдет для сельской местности.
Далее, у команды которая выполняется в ssh-сессии может быть переменная вреды SSH_USER_AUTH, указывающая на файлик, где лежит инфрмация о пользовательском ключе. (Чтобы ее включить, в sshd_config напишите ExposeAuthInfo yes) можно взять этот файлик, прочитать его, потом поискать сооответствующий ключ в authorized_keys и найти там последним полем комментарий, который как правило, содержит имя машины, на которой сгенерена ключевая пара. Дальше уже танцевать от имени машины. Это удобно, если все клиенты - линуксовые машины и админ серевра все равно знает их по имени (что, впрочем, необхдимо и для того, чтобы пользователи могли с одной машины к другой обращаться по имени).
Все примерны, которые мне удалось нагуглить в интернете, используют ifconfig. Он у нас вроде как deprecated, хотя в пакет net-tools в trixie поставляется.
Но аналогичных результатов можно добиться и с использованием iproute2.
ip addr set $address peer $serveraddress dev $device
ip link set $device up
на клиенте
ip addr set $serveraddress peer $adddess dev $device
ip link set $device up
на сервере.
Вообще, видимо, самое логичное - запускать ssh с ключиком -w из скрипта передавая на сервер в параметрах и номер интерфейса и ip-адрес. Это несколько менее удобно чем хранить всю конфигурацию на сервере, но что делать.
Что-то мобильные операторы совсем невзлюбили мой сервер (с проводного Ростелекома из московской квартиры imap и smtp вполне работают).
Теперь уже и на 443 порту все плохо - Фотку кисоньки по вебдав не выложишь - большие POST и PUT запросы по https таймаутятся. Что, кстати, мешает отправлять письма через webmail.Если письмо больше нескольких килобайт, например как нынче любят - с топквотигном, отправка не проходит. Фактически единственное что (пока) работает это ssh. И то только на 22 порту. На 443 уже как-то не очень.
Отдельный квест в этих условиях - почитать почту с нерутованного смартфона. Я этот квест решил, но ход решения, пожалуй, здесь описывать не буду.
Видимо, надо хостинг-провайдера менять. Возможно, на российского. Поскольку есть подозрение что там хостинговый датацентр запретами специально обложен. А для фото кисонек и текущей почты российский провайдер не сильно хуже нероссийского. И с оплатой проще. Или найти какого-нибудь провайдера в стране против которой РКН ничего не имеет - в Бразилии, например или Вьетнаме?
Жалко, конечно что ipv6 так толком и не взлетел. Я тут в мегафоне подключил эту услугу - а шиш. Из трех роутеров только один сумел получить ipv6 адрес - Huawei-вский travel router. Причем он это как-то сам, после чего я полез смотрерть, нельзя ли на других симках это включить. Но ни openwrt на TN MR6400, ни Olax c родной прошивкой не видят ipv6. Насколько я понимаю, там до OpenWRT дело не доходит. Получить какой-то префикс должен QMI-модем с проприетарной прошивкой.
Был бы везде IPv6 можно было бы почту опять держать под кроватью как я на протяжении полутора десятилетий делал. Правда с моим нынешним образом жизни, когда моя квартира по полгода стоит с отключенным электричеством тут тоже есть проблемы.
UPD. У МТС теперь в Тверской области IPv6 есть. Но зато сигнала во всей округе нет.