Fencing 12 June 2025

Jul. 12th, 2025 10:33 pm
izard: (Default)
[personal profile] izard
Just returned from the Upper Bavaria Open Fencing Tournament - Jacob’s first competition under German rules and his return to competitive fencing after a long break. The format followed European youth fencing regulations, which meant a significant equipment change for Jacob: a shorter and stiffer foil compared to one he was using in U.S. tournaments.

ExpandRead more... )

И еще о ssh vpn

Jul. 12th, 2025 07:32 pm
vitus_wagner: My photo 2005 (Default)
[personal profile] vitus_wagner

Разобрался тут, как использовать опцию -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.

vitus_wagner: My photo 2005 (Default)
[personal profile] vitus_wagner

У ssh есть, как известно, ключик -w который позволяет аллоцировать на обоих концах виртуальный сетевой интерфейс и гонять через свое ssh-соединение любой траффик.

К сожалению никакого удобного сервиса, аналогичного тому что есть почти у всех прочих фич ssh вокруг этой опции не сложилось.

Получается следующее

  1. На обоих концах пользователь должен быть рутом, а то будет ошибка device setup failed.
  2. Команды для конфигурирования интерфейа и маршрутов нужно запускать самому, никакого сервиса не предусмотрено.
  3. Предусмотрена возможность передачи имени аллоцированного интерфейса в команды, указанные как LocalCommand и RemoteCommand, но у меня что-то нифига не получилось.

Соответсвенно встает задача как организовать работу по схеме "звезда". Т.е. когда есть 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-адрес. Это несколько менее удобно чем хранить всю конфигурацию на сервере, но что делать.

vitus_wagner: My photo 2005 (Default)
[personal profile] vitus_wagner

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

izard: (Default)
[personal profile] izard
Here is how buggy messenger delivery status can lead to miscommunication.

Message status: [Sent, Delivered, Read]

My view, after mobile internet went down on my phone at some point:
1. Me: Going home now. [SDR]
2. Julia: We'll be at a grocery store soon, should I pick you up at station A?
3. Me: No, thanks, I'll exit at station B and walk home. [SD]
4. Me: I'll be there in 30 minutes. [S]
5. Me: I'll text you if something happens with the train. []

Julia's view:
1. Alex: Going home now.
2. Me: We'll be at a grocery store soon, should I pick you up at station A? [SDR]
3. Alex: I'll be there in 30 minutes.
4. Me: I am waiting, where are you? [S]
5. Me: FindMy shows you at station B, why? [S]
6, 7, 8, 9

I was considering sending an SMS, but as my 3. was shown as delivered, I did not expect Julia to receive my message 4. only, but not 3. I should probably switch to WhatsApp.

When it rains

Jul. 8th, 2025 05:31 pm
izard: (Default)
[personal profile] izard
When I was a kid, I was spending every summer holiday in my grandmother’s village in Russia. The region sits on a cultural and religious border between Christian and Islam parts, with surviving traces of pre-Christian paganism. Some villages still had practicing shamans who preserved old rituals that were rarely talked about openly, but widely respected.

When I was 14 a drought had started in summer. Crops were at risk, and everyone was worried. A weather forecast finally offered some hope: light, scattered showers the following day. In response, several shamans from neighboring villages decided to “ask the gods” for rain.

I didn’t witness the ritual itself. But later that evening, I saw what they had left behind: stains of chicken blood at the base of a centuries-old oak tree, and bright cloths tied into its branches, swaying in the still, hot evening air.

The next day, it rained. Not much, maybe 20 minutes, but it was something. That’s when things got strange. I took my bicycle out and rode around the area.
ExpandRead more... )

April 2016

S M T W T F S
     12
3456789
1011121314 1516
17181920212223
24252627282930

Most Popular Tags

Style Credit

Expand Cut Tags

Expand All Cut TagsCollapse All Cut Tags
Page generated Jul. 16th, 2025 04:24 am
Powered by Dreamwidth Studios