19

Я хочу использовать Raspberry Pi в своем коттедже на выходных. Raspberry Pi предназначен для регистрации температур и отправки их на удаленный сервер с фиксированным IP-адресом, который сохраняет данные и отображает их на простом веб-сайте.

Однако может возникнуть ситуация, когда я хочу что-то изменить на Raspberry Pi. Например, обновления системы или изменения в программе, которая отправляет данные на сервер или что-то еще.

С предложенной настройкой я не смог бы подключиться к Raspberry Pi за пределами его локальной сети.

ПРИМЕЧАНИЕ. Я не хочу менять сеть, и на существующем маршрутизаторе нет возможности переадресации портов, dynDNS или VPN.

Я недавно перечитал UDP дырокол. Основная идея заключается в том, что клиент отправляет пакет UDP на известный адрес сервера (т. Е. С включенным общедоступным IP-адресом или dynDNS). Клиент B, который хочет подключиться к клиенту A, запрашивает у сервера общедоступный IP-адрес и номер порта клиента A.

Затем он может подключиться к клиенту A напрямую по общедоступному IP-адресу и порту, который является динамическим. Поскольку клиент A сначала подключается к серверу через используемый порт, NAT будет пересылать пакеты клиенту A.

Надеюсь, я правильно изложил идею, более или менее…

Все это звучит хорошо, но проблема в том, что это не гарантируется для работы с TCP-соединением, так как маршрутизатор может «понимать» рукопожатие TCP-соединения и, если оно не создано правильно, оно не будет пересылать пакеты.

Итак, как я могу открыть сессию SSH от клиента B к клиенту A без клиента A, сидящего за маршрутизатором с dynDNS, с фиксированным общедоступным IP-адресом или возможностью переадресации портов? Использование центрального сервера с общедоступным, фиксированным IP-адресом или доменным именем было бы жестким.

|источник

3 ответа3

7

pwnat

«... нетривиально инициировать соединение с пэром за NAT ».

«... почти все реализации NAT отказываются перенаправлять входящий трафик , который не соответствует недавнему совпадающему исходящему запросу ».

»..Инструмент pwnat - это автономная реализация GNU/Linux для автономного обхода NAT. После установления связи с сервером за NAT он устанавливает канал с семантикой TCP, используя пакеты UDP. Он поддерживает как клиента, так и сервер за NAT (если один из NAT позволяет передавать поддельные [пользовательские] ICMP- сообщения). Эта реализация предназначена для конечных пользователей. " 

  
usage: ./pwnat <-s | -c> <args>

  -c    client mode
    <args>: [local ip] <local port> <proxy host> [proxy port (def:2222)] <remote host> <remote port>

  -s    server mode
    <args>: [local ip] [proxy port (def:2222)] [[allowed host]:[allowed port] ...]

  -6    use IPv6  
  -v    show debug output (up to 2)  
  -h    show help and exit  

Examples:  

    Server side allowing anyone to proxy:
      ./pwnat -s

    Client wanting to connect to google.com:80:
      ./pwnat -c 8000 <pwnat.server.com> google.com 80
    Then, browse to http://localhost:8000 to visit the google!

pwnat; схема потока сигналов сети

«Основная идея, позволяющая серверу узнать IP-адрес клиента, состоит в том, чтобы сервер периодически отправлял сообщение на фиксированный, известный IP-адрес. В простейшем подходе используются сообщения ICMP ECHO REQUEST на нераспределенный IP-адрес, например 1.2.3.4. Поскольку 1.2.3.4 не выделен, запрос ICMP не будет маршрутизироваться маршрутизаторами без маршрута по умолчанию. "

«В результате сообщений, отправленных на 1.2.3.4, NAT включит маршрутизацию ответов в ответ на этот запрос. Затем подключающийся клиент подделает такой ответ. В частности, клиент передаст сообщение ICMP, указывающее TTL_EXPIRED . Такое сообщение может быть законно передано любым интернет-маршрутизатором, и адрес отправителя не должен соответствовать целевому IP-адресу сервера. "

« Сервер прослушивает (поддельные) ответы ICMP и при получении инициирует соединение с IP-адресом отправителя, указанным в ответе ICMP. Если клиент использует глобально маршрутизируемый IP-адрес, это совершенно не проблема, и TCP или UDP могут использоваться для установления двунаправленного соединения, если клиент прослушивает предварительно согласованный порт. "

«(В тех случаях, когда нет заранее согласованного порта, номер порта в большинстве случаев может передаваться как часть полезной нагрузки ICMP ECHO RESPONSE)».

Источник: http://samy.pl/pwnat.pdf
https://github.com/samyk/pwnat

|источник
1

Вот пара решений:

Вы можете настроить Raspberry Pi для подключения к серверу OpenVPN, и вы будете иметь к нему доступ постоянно.

Вы можете взглянуть на PageKite. Проверьте https://pagekite.net/wiki/Howto/SshOverPageKite/

|источник
0

Это несколько грязное, но простое решение, но как насчет использования netcat? На Raspberry Pi вы можете создать скрипт, который повторяет команду: 

nc <public_ip> <port1> | sh | nc <public_ip> <port2>

На вашем локальном хосте выполните: 

nc -l <port1>

А также:

nc -l <port2>

Вы сможете набрать команду в первом случае и увидеть ответ во втором.

|источник

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