1

Я создал обратный SSH-туннель, который создает сокет UNIX на удаленном сервере (назовем его proxy_srv), чтобы я мог подключить владельца туннеля (с именем target_srv в оставшейся части этого вопроса) в 2 этапа: создать ссылку из Сокет Unix к порту TCP с помощью socat и подключение к этому порту с помощью клиента SSH (клиент SSH, по-видимому, не принимает подключение к сокету Unix, поэтому я использовал эту уловку socat в качестве обходного пути).

Используемые команды (достаточно воспроизвести, немного больше на практике, с файлами идентификации и со) в следующем порядке:

Из target_srv:

me@target_srv:% ssh -CNR /tmp/$(hostname):127.0.0.1:22 me@proxy_srv -o ExitOnForwardFailure=yes

Из proxy_srv:

me@proxy_srv:% socat TCP-LISTEN:2222 UNIX-CONNECT:/tmp/target_srv

С любого другого компьютера, который может получить доступ к proxy_srv:

ssh someone@proxy_srv

Цель всего этого - автоматически построить туннель из компьютеров, использующих сети GPRS, в точку доступа, чтобы я мог получить к ним доступ в случае проблем, учитывая тот факт, что у меня нет физического доступа к ним (слишком далеко),

У меня есть 2 основные проблемы:

  • когда кто-то удаляет файл сокета Unix на proxy_srv, туннель не заканчивается, поэтому я не могу воссоздать его (легко обойти, просто используйте выделенного пользователя, но все же немного касательно меня),

  • самое главное, если по какой-то причине что-то в target_srv было перезапущено, либо в результате физической перезагрузки, либо в результате сбоя системы, после чего все происходило автоматически, файл в proxy_srv не удалялся, и туннель не мог быть восстановлен. Конечно, я мог бы просто удалить его и надеяться, что проблема не в конфликте с другим компьютером, но я думаю, что должен быть лучший способ по крайней мере обойти это, например, обнаружение файлов сокетов, которые больше не имеют прослушивателей, и автоматическое удаление их регулярно (внутри выделенной папки, конечно).

Любая идея?

1 ответ1

1

Я понимаю, что есть много машин target_srv, и по этой причине вы не используете -R 2222:127.0.0.1:22 но подключаете порт 2222 proxy_srv к машине по вашему выбору ad hoc.

Я думаю, что правильный инструмент - это VPN. Если proxy_srv был VPN-сервером, а машины target_srv были клиентами, вы бы туннелировали SSH к IP-адресу (VPN) нужного клиента. Если вы также сделали свой локальный компьютер клиентом, вы можете даже напрямую подключиться к другим клиентам (без SSH-туннелирования). Программное обеспечение VPN будет отвечать за установление, поддержание и возобновление любого присутствия target_srv в виртуальной сети.

Предположим, вы не можете использовать VPN, и эта ваша хитрость на основе сокетов просто необходима. Я не знаю, как обнаружить потерянные доменные сокеты Unix, однако есть другой способ справиться с ситуацией.

Создайте вспомогательный скрипт на proxy_srv, скажем, /home/me/bin/ssh-tunnel-helper.sh:

#!/bin/sh

soc1="$1".tmp
soc2="$1"

mv "$soc1" "$soc2" || { rm "$soc1"; exit 2; }
while sleep 40; do
   [ -e "$soc2" ] || exit 1
done

(Не забудьте сделать его исполняемым).

Затем вызовите target_srv:

socket="/tmp/$(hostname)-tunnel"
while sleep 5; do
   ssh -CR "$socket".tmp:127.0.0.1:22 -o ExitOnForwardFailure=yes me@proxy_srv \
      /home/me/bin/ssh-tunnel-helper.sh "$socket"
done

Сейчас

  • когда кто-то удаляет файл сокета unix на proxy_srv

Сценарий ssh-tunnel-helper.sh обнаруживает его и завершает работу. Петли , while на target_srv обновляет туннель.

  • если по какой-то причине что-то на target_srv было перезапущено, […] файл на proxy_srv не удаляется

*-tunnel действительно не удален, но sshd изначально создает *-tunnel.tmp который позже переименовывается. Хитрость в том, что в Unix вы можете открыть файл и переместить его (или даже удалить). Переименование сокета не нарушает существующий туннель, но позволяет создавать новый сокет в будущем.

Если вспомогательный скрипт прерван, он может оставить устаревший сокет *-tunnel.tmp , который помешает созданию будущих туннелей. Я ожидаю, что такие случаи будут редкими. Запустите rm /tmp/*-tunnel.tmp на proxy_srv для восстановления. Даже если вам удастся удалить другой сокет, который должен был быть переименован в этот самый момент, его вспомогательный скрипт завершится, и через некоторое время туннель будет обновлен.

Замечания:

  • Вы можете использовать autossh вместо ssh на target_srv машинах для обнаружения сломанных соединений и т.д. Даже с autossh вы все еще нуждаетесь в while цикла , так как autossh выйдет , если вспомогательный скрипт завершает работу (например , когда кто - то удаляет сокет на proxy_srv).

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .