У меня есть устройство на базе Linux (скажем, Raspberry Pi), на котором размещен HTTP-сервер. Это устройство регулярно меняет точку доступа Wi-Fi и часто не является общедоступным из-за NAT и / или брандмауэра.
Я хочу настроить обратный туннель ssh, используя общедоступный сервер (rpi.example.com ниже) такие, что rpi behind NAT установить туннель для rpi.example.com при загрузке. rpi.example.com затем перенаправит любой HTTP-запрос на rpi behind NAT.
Схема последовательности:
HTTP client rpi.example.com rpi behind NAT
+ + +
| | ssh -R |
| | <-----------------+
| GET /temp | |
+-----------------> | |
| +-----------------> |
| | [SSH tunnel] |
| | <-----------------|
| HTTP/1.1 200 OK | |
| <-----------------+ |
| | |
Как настроить такой обратный SSH-туннель? Есть ли лучшая альтернатива?
Я думаю, что VPN (например, openVPN или решение IPSEC, например strongswan) может работать лучше.
Вы можете абсолютно использовать SSH с -R переключатель:
-R удаленный_сокет: локальный_сокет
Указывает, что соединения с заданным TCP-портом или сокетом Unix на удаленном (серверном) хосте должны быть перенаправлены на данный хост и порт или сокет Unix на локальной стороне. Это работает путем выделения сокета для прослушивания TCP-порта или сокета Unix на удаленной стороне. Всякий раз, когда выполняется соединение с этим портом или сокетом Unix, соединение пересылается по защищенному каналу, и с локальной машины устанавливается соединение либо с портом хоста, либо с local_socket.
Вам просто понадобится что-то на вашем Pi, чтобы инициировать соединение и перезапустить его, если оно не удастся. NAT здесь не имеет значения, потому что туннель будет напрямую между вашим общедоступным хостом и Pi - на вашем хосте у вас фактически будет прослушиватель (например, 127.0.0.1:9999), и вы настроите свой веб-сервер для использования этого прослушивателя в качестве вверх по течению.
Скорее всего, вам захочется иметь специального пользователя для создания этой пересылки (поскольку ваш Pi должен иметь возможность аутентифицироваться на вашем сервере, что почти наверняка означает, что вам понадобится закрытый ключ без пароля). Вам также потребуется создать одно перенаправленное соединение для каждого порта, если вам когда-либо понадобится более одного.
Я подозреваю, что VPN было бы проще обеспечить надежную работу и, по сути, потребовалось бы меньше скриптов. Однако оба подхода будут работать.