Я хочу розгорнути Raspberry Pi у своєму котеджі на вихідних. Raspberry Pi є для того, щоб реєструвати температури та відправляти їх на віддалений сервер, який має фіксований ip, зберігає дані та відображає їх на простому веб-сайті.

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

Завдяки запропонованій настройці я не зможу підключитися до Raspberry Pi з-за меж своєї локальної мережі.

ПРИМІТКА. Я не хочу змінювати мережу, і існуючий маршрутизатор не має можливості переадресації портів, dynDNS або VPN.

Нещодавно я прочитав пробивання отворів UDP. Основна ідея полягає в тому, що клієнт надсилає UDP-пакет на відому адресу сервера (тобто з увімкненим загальнодоступним IP-адресою або dynDNS). Клієнт B, який хотів би підключитися до клієнта A, запитує сервер для загальнодоступного IP-номера та номера порту клієнта А.

Потім він може підключитися до клієнта A безпосередньо на його публічному IP та порту, який є динамічним. Оскільки клієнт A вперше підключений до сервера на використовуваному порту, NAT пересилатиме пакунки клієнту А.

Я сподіваюся, що я підсумував ідею правильно, більш-менш ...

Це все звучить приємно, але проблема полягає в тому, що це не має гарантії для роботи з TCP-з'єднанням, оскільки маршрутизатор здатний «зрозуміти» рукостискання TCP-з'єднання, і якщо він не побудований правильно, він не перейде вперед пакети.

Отже, як я можу відкрити сесію SSH від клієнта B до клієнта A без клієнта A, який сидить за маршрутизатором з dynDNS, виправленим загальнодоступним IP-адресою або можливістю переадресації портів? Використання центрального сервера з загальнодоступним, виправити IP або доменне ім'я може бути важким.

pwnat

"..не тривіально ініціювати з'єднання з одноранговим агентом позаду NAT. "

".. майже всі реалізації NAT відмовляються пересилати вхідний трафік , який не відповідає нещодавньому відповідному вихідному запиту. "

".. pwnatІнструмент - це лише GNU / Linux, автономна реалізація автономного обходу NAT. Після контакту з сервером позаду NAT він встановлює канал із семантикою TCP, використовуючи пакети UDP. Він підтримує і клієнт, і сервер позаду NAT. (якщо один з NAT дозволяє передавати підроблені [користувацькі] ICMP- повідомлення). Ця реалізація націлена на кінцевих користувачів. "

  
використання: ./pwnat <-s | -c> <args>

  -c клієнтський режим
    <args>: [local ip] <local port> <proxy host> [proxy port (def: 2222)] <remote host> <remote port>

  -s серверний режим
    <args>: [local ip] [порт проксі (def: 2222)] [[дозволений хост]: [дозволений порт] ...]

  -6 використовувати IPv6  
  -v показати вихід налагодження (до 2)  
  -h показати допомогу та вийти  

Приклади:  

    Сторона сервера, що дозволяє кожному проксі:
      ./pwnat -s

    Клієнт, який хоче підключитися до google.com:80:
      ./pwnat -c 8000 <pwnat.server.com> google.com 80
    Потім перейдіть до http: // localhost: 8000, щоб відвідати google!  

«Ключова ідея для включення сервера , щоб дізнатися IP - адреса клієнта є для сервера , щоб періодично відправляти повідомлення для фіксованого, відомого IP - адреси. Найпростіший підхід використовує ICMP ехо - запити на незайнятий 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

Ось пара рішень:

Ви можете налаштувати Raspberry Pi для того, щоб повернутися назад до сервера OpenVPN, і ви будете мати доступ до нього постійно.

Ви можете подивитися на PageKite. Перевірте https://pagekite.net/wiki/Howto/SshOverPageKite/

Це дещо брудне, але просте рішення, а як щодо використання netcat? На Raspberry Pi ви можете створити сценарій, який циклічно виконує команду:

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

Зробіть місцевий хост:

nc -l <port1>

І:

nc -l <port2>  

Ви зможете ввести команду в першій інстанції і побачити відповідь у другій.