Разобрался тут, как использовать опцию -w у ssh. Надо будет в рассказку дописать.

Токен %T в LocalCommand вполне работает. А на серверной стороне у команды которая передана в командной строке ssh есть переменная среды SSH_TUNNEL.

Получилось следующее:

1. На сервере требуется опция PermitTunnel yes и PermitRootLogin yes в глобальном sshd_config и у рута в .ssh/authorized_keys ключи клиентов. Надо их ограничить, чтобы ничего лишнего не делал, прописав там command и прочее
2. На клиенте в глобальном ssh_config PermitLocalCommand yes
3. На сервере в /usr/local/bin скриптик sshnetsetup
4. На клиенте в /usr/local/bin sshnetclient и sshvpn
5. На клиенте в /etc/ssh файлиk vpn.conf, содержащий следующией настройки

```

 # !/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.

Что-то мобильные операторы совсем невзлюбили мой сервер (с проводного Ростелекома из московской квартиры 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 есть. Но зато сигнала во всей округе нет.