Настройте прямое SSH-подключение от A к C без публичных IP-адресов, используя один публичный SSH-сервер

Настройте прямое SSH-подключение от A к C без публичных IP-адресов, используя один публичный SSH-сервер

У меня есть в наличии следующие SSH-серверы/клиенты:

A - без публичного IP

B - публичный IP

C - без публичного IP

Я знаю, что могу установить SSH-соединение из A в C следующим образом:

1) Присоединяем C к B. Выполняем из C:

ssh -R 10100:localhost:22 B_IP

2) Установите переадресацию портов с A на C с помощью хука B, чтобы иметь возможность использовать ssh-agent на машине A:

ssh -L 5000:localhost:10100 B_IP

3) Теперь я могу использовать свои ключи SSH для «прямого» доступа к C из A:

ssh -p 5000 localhost

... моя точка зрения такова:

Могу ли я как-то установить новое «чистое» соединение от А до С?чтобы после выхода машины B из строя я мог продолжить свою работу?

Я думаю, это возможно, если эти два компьютера поймут, что они уже имеют общее соединение, или я ошибаюсь?

Спасибо за ваше время и идеи :)

решение1

  • TheобычныйМетод заключается в настройке «переадресации портов NAT» на маршрутизаторе A или C. (Как это сделать, зависит от маршрутизатора, но инструкции есть везде.) После этого вы сможете подключиться к публичному адресу маршрутизатора C + «переадресованному» порту, и соединение будет проходить через C.

    (Примечание: переадресация портов NAT и переадресация портов SSH аналогичныно отчетливый(вещи, вроде молотка и отвертки. Не путайте их.)

  • Если у вас нет административного доступа ни к одному из маршрутизаторов, вы можете попробовать использовать UPnP или NAT-PMP для настройки правила переадресации портов, как это делают многие игры и программы P2P. Для этого используйте команды upnpcили .natpmpc

  • Если ни один из вышеперечисленных методов не сработал, вам понадобится какая-то формаNAT-дырокол. (См. такжеТКПиИКМП(Дыроколы.)

    К сожалению, хотя он широко используется в различныхспецифическийпрограмм, похоже, не так уж многообщийинструменты для TCP, хотячовнатможет сработать.

решение2

Это, вероятно, невозможно, если только вы не сможете выполнить переадресацию портов на маршрутизаторах, но в этом случае вам вообще не понадобится компьютер C.

Дело в том, что в вашем примере вы не идете напрямую из A -> C, все пакеты все еще проходят через B.

Если у вас есть другой компьютер с публичными адресами, вы, вероятно, можете настроить VPN в топологии звезды и использовать маршрутизацию между VPN для создания виртуальной сети, где любой из публичных хостов может упасть, и все может продолжать работать. Я делал это с OpenVPN — есть несколько подводных камней — один из важных — отключение Reverse Path Filtering.

решение3

Одним из способов сделать это было бы использование одноранговой VPN — VPN, которая не требует, чтобы один из хостов имел статический IP-адрес или статическое доменное имя, указывающее на него. Другие идеи, упомянутые ниже, на самом деле не являются VPN, а представляют собой программное обеспечение, которое устанавливает одноранговое соединение через какой-то протокол. Вот несколько вариантов:

На основеtox.чатсеть:

Я лично попробовал оба решения, но они были заблокированы моей рабочей сетью (в стиле крупной корпорации).

  • toxvpn- на сегодняшний день, похоже, не очень хорошо обслуживается, но должен работать.
  • тунтокс- Похожая идея, хотя это не настоящий VPN, но может устанавливать соединение и пересылать порты ssh между двумя машинами в сети tox. Примеры для ssh доступны в README.
На основе общедоступных платных чат-сервисов

Я лично ничего из этого не пробовал и сомневаюсь, что они сработают, но попробовать, возможно, стоит.

  • LAN-вечеринка VPN- На основе Discord. Похоже, на сегодняшний день он не очень хорошо поддерживается, а в README не так много примеров, но, возможно, стоит проверить.
  • роботито- не выглядит очень ухоженным. Также установка кажется сложной - используетГугл голос(ранее GTalk).
VPN на базе публичного сервера (обслуживаемого другими)

Личный опыт: попробовал n2n, но моя рабочая сеть (большая корпоративная) заблокировала.

  • н2н- использует "суперузел", который поддерживаетсяntopкоманда - она ​​работает согласно n2nREADME по адресу supernode.ntop.org:7777(суперузел также является свободным программным обеспечением, но для его запуска снова требуется общедоступный сервер).
  • Нубела- Похожая концепция, как n2n, но вместосуперузелэто называетсямаяк. Они не предлагают общедоступный маяк для использования всеми, но вам на самом деле придется запустить его dnclientна вашем общедоступном VPS, как описано вих документы. Следовательно, это не отвечает вашим требованиям, но я подумал, что об этом все равно стоит упомянуть.
Другие VPN-решения, требующие платной подписки.

В отличие от большинства коммерческих VPN-сервисов, только некоторые из них, ориентированные на опытных пользователей, позволят двум пользователям общаться друг с другом через подсети VPN, которые вы получаете. Вероятно, есть и другие провайдеры, которые могут предоставить эту функцию. Вот один из них:

На основе сетей, поддерживаемых сообществом

Даже за мощным NAT, если ваш брандмауэр не слишком строг (в моем случае это не так), вы можете сделать одно из следующего (не VPN):

  • тор- Пытатьсяэто руководствоПо сути, вы создаете .onionдомен (сервис Tor), к которому смогут получить доступ пользователи Tor со всего мира.
  • i2pd- Пытатьсяэто руководствов которых также есть инструкции для i2dpклиента, которого i2pя бы рекомендовал.
Крайнее решение

Даже при наличии самых раздражающих брандмауэров, NAT и других сетевых ограничений, с которыми вы можете столкнуться, вы сможете использовать замечательныйhttps://tmate.io/бесплатное (как в бесплатном пиве и как в свободной речи) программное обеспечение и услуги. Однако у него есть некоторые недостатки:

  • Никаких интерактивных команд (см.выпуск №179).
  • Без scpподдержки.
  • tmuxверсия, на которой основан форк, актуальна на сегодняшний день 2.6.0, в то время как текущая последняя версия tmux 3.3a— это означает, что для ее ~/.tmux.confработы ~/.tmate.confвам придется внести нетривиальные коррективы (см.например из моих личных dotfiles).

Хотя разработчики tmate не упоминают об этом явно, я думаю, что первые два недостатка являются преднамеренными ограничениями, поскольку люди могут злоупотреблять этими возможностями для передачи большого объема данных через tmate.ioсервер . Таким образом, это tmateдействительно создает своего рода «удаленный рабочий стол» для вашей оболочки. Вам придется найти другие методы для передачи файлов между двумя машинами (рассмотритесинхронизация).

В целом - простота использования tmate и его замечательная производительность делают его лучшим решением, на мой взгляд. В сочетании ссинхронизациядля передачи файлов я считаю это лучшим решением и самым надежным.

Связанный контент