LINUX.ORG.RU
Форум — Admin  

Туннель между двумя системами за серыми IP

 ,


0

4

Имеются две станции, в каждую из которых воткнута Yota.

Первая станция получает IP 10.178.253.168 внешний IP: 188.162.229.137 (определил на internet.yandex.ru )

Первая станция получает IP 10.179.213.16 внешний IP: 188.162.229.135

Как между ними прокинуть прямой туннель? Станции друг друга не пингуют.

С помощью дополнительного внешнего сервера с белым IP задача решается с помощью ssh, что-то вроде 

ssh -R *:27777:localhost:25565 root@62.109.15.241 -NCv
В этом примере на первой станции работает сервис на порту 25565, мы делаем его доступным по адресу 62.109.15.241:27777 и теперь мы можем пробраться на этот сервис со второй станции.

У этого варианта 2 недостатка: 1) необходимость иметь в интернете внешний сервер с белым IP, на который мы можем подключиться по SSH и 2) большие задержки связанные с удалённостью этого сервера. В моём случае первая и вторая станции находятся в Хабаровске, а сервер в германии. Пинг до сервера 250 мс. При обращении с первой станции на вторую через ssh-туннель суммарно получается 500 мс. При прямом соединении я ожидаю сокращения задержки в десятки раз.

Мои познания сетей подсказывают, что сделать такое не получится, но остаётся надежда, что решение может быть схоже с принципом работы tor, skype, torrent, webrtc и т. п.

← открыть закрыть доступ по SSH через маилсервер
Bind9 notify port →

Ответ на: комментарий от te111011010

Плюсую. Через miredo проще всего (вроде там трафик напрямую идет без проксирования).

Еще можно pwnat. Правда не всегда работает.

Black_Roland ★★★★
()
Последнее исправление: Black_Roland (всего исправлений: 1)
Ответ на: комментарий от MyTrooName

Я недавно тоже похожее решение искал: Перепроброс (перемаршрутизация) SSH туннеля без сервера посредника

Pwnat не все NAT'ы пробивает. По крайней мере тот который мне надо было — не пробило. Просто нет соединения.

Еще пробовал пробивать свой домашний NAT — соединение устанавливается, но дальше появляются ошибки и данные не передаются. Возможно криво собралось.

Black_Roland ★★★★
()
Последнее исправление: Black_Roland (всего исправлений: 1)
Ответ на: комментарий от MyTrooName

http://samy.pl/pwnat/

В двух словах: NAT на обоих концах не должен менять source port при трансляции. Некоторые NAT'ы могут рандомизировать порт, на некоторых этот порт уже может быть занят какой-то трансляцией, поэтому стоит поиграться с номерами.

anonymous
()
Ответ на: комментарий от CHIPOK

можно сделать, чтобы он менялся реже, указав точный порт. можно использовать no-ip или другой подобный сервис. можно не выключать компьютер.

Black_Roland ★★★★
()
Последнее исправление: Black_Roland (всего исправлений: 1)
Ответ на: комментарий от te111011010

Попробовал поставить на обоих хостах (debian) miredo. IP выдались, гугл пингуют, сами себя тоже, но друг-друга не пингуют. Буду копать дальше, больше спасибо за наводку!

vovanmozg
() автор топика
Ответ на: комментарий от vovanmozg

Вроде miredo (teredo) некорректно работает через симметричный nat. Если у тебя такой, то может способ попробовать сменить. Например, через http://www.gogo6.com/freenet6

te111011010 ★
()

Я не знаю, подойдет ли вам это решение, но это явно удобней того же pwnat. На одном компьютере нужно поднять OpenVPN-сервер на UDP с фиксированным портом, скажем, 7777, и отправлять, скажем, один UDP-пакет с source port 7777, destination port 7777 на ваш второй внешний IP раз в 30 секунд. На клиенте необходимо настроить подключение к OpenVPN-серверу на внешнем IP и порту 7777, установить source port 7777 тоже. Все, теперь вы можете подключиться с клиента к OpenVPN-серверу.

Это костыльно и неудобно, но у вас будет прямая связность с минимальным пингом. Miredo вам такого не даст, хотя он проще.

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

Black_Roland

ValdikSS ★★★★★
()
Последнее исправление: ValdikSS (всего исправлений: 2)
Ответ на: комментарий от ValdikSS

На одном компьютере нужно поднять OpenVPN-сервер на UDP с фиксированным портом, скажем, 7777, и отправлять, скажем, один UDP-пакет с source port 7777, destination port 7777 на ваш второй внешний IP раз в 30 секунд. На клиенте необходимо настроить подключение к OpenVPN-серверу на внешнем IP и порту 7777, установить source port 7777 тоже.

Так и pwnat, как я понял из описания, пробивает дырку в нате таким же образом.

Вообще, меня берут сомнения, можно ли сделать такое с Linux-based NAT'ом без координации действий с обеих сторон. Когда пакет дойдет до NAT'а клиента, то там в таблице conntrack будет создана запись такого вида (IP клиента - 192.0.2.2, IP сервера - 192.0.2.130): 

src=192.0.2.130 dst=192.0.2.2 sport=7777 dport=7777 [UNREPLIED] src=192.0.2.2 dst=192.0.2.130 sport=7777 dport=7777
Дефолтный (в 3.2, по крайней мере) таймаут у UDP соединения - 30 секунд. И в течение этих 30 секунд ни один пакет от сервера не уйдет клиенту, даже если клиент будет слать что-то обратно.

Если добиться того, что первые пакеты клиента и сервера одновременно пройдут через свои NAT'ы, то все должно получиться.

Deleted
()
Ответ на: комментарий от Deleted

Дефолтный (в 3.2, по крайней мере) таймаут у UDP соединения - 30 секунд

Имел в виду в состоянии UNREPLIED, в ASSURED таймаут будет больше.

Deleted
()
Ответ на: комментарий от Deleted

Нет, pwnat, можно сказать, чуточку умнее. Он работает через ICMP, и ему не нужно знать IP клиента на стороне сервера. Но все должно получится.

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

Я имел в виду именно алгоритм пробивания ната. То, что он сначала через ICMP узнает адрес клиента, я знаю :)

Deleted
()
Ответ на: комментарий от Black_Roland

Попробовал pwnat, но опять-таки не получилось с наскоку. Пришлось в исходниках сменить IP с 3.3.3.3 на 2.2.2.2. Из описания я понял, что пакеты на 3.3.3.3 не должны доходить, но 3.3.3.3 в интернете есть и пингуется.

vovanmozg
() автор топика
Ответ на: комментарий от vovanmozg

Странный у тебя интернет 

$ ping -c 5 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 56(84) bytes of data.

--- 3.3.3.3 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms

Black_Roland ★★★★
()
Ответ на: комментарий от Black_Roland 
C:\Users\vovan>ping 3.3.3.3

Обмен пакетами с 3.3.3.3 по с 32 байтами данных:
Ответ от 3.3.3.3: число байт=32 время=39мс TTL=247
Ответ от 3.3.3.3: число байт=32 время=37мс TTL=247
Ответ от 3.3.3.3: число байт=32 время=46мс TTL=247
Ответ от 3.3.3.3: число байт=32 время=37мс TTL=247

Статистика Ping для 3.3.3.3:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 37мсек, Максимальное = 46 мсек, Среднее = 39 мсек
vovanmozg
() автор топика
Ответ на: комментарий от te111011010

Более того, если речь идёт о LTE, и если бы у Yota он был честный, т.е. удовлетворяющий стандартам, то там было бы IPv6 в комплекте. По крайней мере, на русской Wikipedia в статье про IPv6 написано, что

В спецификации стандарта мобильных сетей LTE указана обязательная поддержка протокола IPv6.

Воткнул сейчас свой модем — не видно что там есть на интерфейсе IPv6 адрес. Жаль, конечно.

Infra_HDC ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← открыть закрыть доступ по SSH через маилсервер
Admin
Bind9 notify port →