Как пропинговать комп, подключенный через GPRS, с другого компа, так же подключенного через GPRS (возможно даже, что, другого мобильного оператора)?

Question

[1010101001000100110100111]

Другими словами, как установить «р2р-соединение» по протоколу ICMP между двумя мобильными терминалами?

Comments

[1010101001000100110100111]

Если Вы убеждены в том, что это невозможно-в-принципе, и даже можете объяснить, почему — то, лучше ничего не пишите в ответ.

[strib]

вывод ipconfig/ifconfig и трассу вовне можно посмотреть?
есть несколько способов организации APN

[Виталий Перетятько]

я так понял — конечная цель гонять данные между мобилками и не платить за трафик?

[1010101001000100110100111]

Конечная цель немного иная: эти два терминала (их может быть и больше двух) резервируют друг-друга. Важно чтобы у каждого из них был «свой» постоянный Интернет. Как только ICMP-связность этих двух терминалов пропадает регистрируется «сработка» и оба терминала переходят в «аварийный» режим, в котором они за некоторое время должны восстановить связность (вплоть до установки прямой связи по GSM-голосовому каналу 9600 бит/с). Если им это не удается за какое-то время, то каждый из терминалов генерирует сигнал «тревога» (и, например, запускает программу самоликвидации).

Answer 1

[isden]

Я вижу 2 варианта:
1. Простой — DynDNS на клиентских компах. Т.е. при любой смене ip мы все равно можем обращаться к хосту по имени.
2 Сложнее — некий третий узел-посредник с известным фиксированным адресом и VPN-сервером на борту.

Comments

[1010101001000100110100111]

К сожалению, DynDNS в случае с мобильными терминалами не пройдет — так как терминалы находятся за NAT'ом, и один IP-адрес делится между несколькими узлами. А, пропинговать нужно вполне-себе конкретный узел.

Answer 2

[Evengard]

Вижу только вариант с Hamachi или подобным (VPN). Дело всё в том, что мобильный инет ОПСОСы обычно старательно NAT-ят. А значит вам придётся прорваться через 2 NAT-а (минимум — 1 на вашей стороне, 1 — на другой) а то и больше.
Прорваться через такое количество NAT-ов и без GPRS-а не всегда выходит…
Так что только VPN.

Comments

[1010101001000100110100111]

Я так понял, VPN-сервер в этом случае нужно будет на каком-то третьем узле поднимать (причем с белым адресом)?

Answer 3

[Maxim Kuzovlev]

Вроде тут было что-то подобное описано.

Answer 4

[Максим]

Установить тимвьювер на обе машинки, и сможете видеть друг друга, в случае чего, и опять же для проверки.

Comments

[1010101001000100110100111]

К сожалению, это решение создает слишком уж большой объем «левого» трафика.
В идеале хотелось бы чтобы после успешного «пробивания» двух NAT'ов оба терминала могли общаться обмениваясь только лишь ICMP-пакетами.

Answer 5

[Disasm]

Сначала через какой-нибудь сервер определить внешний IP друг друга, а потом кидаться в эти айпишники ICMP пакетами с терминалов.

Comments

[1010101001000100110100111]

Свои собственные «Внешние» IP определить (и передать друг-другу) как раз-таки не проблема, а, вот, что дальше-то с ними (ай-пишниками) делать?

[Disasm]

Пинговать друг друга. Пакеты будут проходить через NAT так как роутер будет считать что пакет извне — ответ на ушедший изнутри пакет.

[1010101001000100110100111]

No pasaran! (они не пройдут)
Он (роутер) так не будет считать, ведь он же видел, что изнутри никакие пакеты никуда не уходили. И, к тому же, кроме моего узла есть еще куча других сидящих под этим же NAT'ом, и неизвестно, кому из них пакет слать.

[Disasm]

Так надо чтоб ходили. Узел А отправляет пакет в сторону узла Б (он может быть не дойдёт), в это же время узел Б отправляет пакет в сторону узла А. Роутер узла А думает что это ответ на первый пакет и он (пакет) проходит внутрь и доходит до узла А.

Answer 6

[Виталий Перетятько]

ru.wikipedia.org/wiki/STUN
сетевой протокол (....) используется для установления соединения UDP между двумя хостами в случае, если они оба находятся за маршрутизатором NAT.
Возможно и для ICMP удастся применить, ну хотя бы свои внешние IP хосты узнают. RFC в котором описано прохождение ICMP NAT www.faqs.org/rfcs/rfc5508.html
Для сопоставления отправитель-получатель NAT использует поле ICMP Query Id пакета так же, как порт в UDP. Тоесть отправив с одного хоста H1 пакет на внешний IP второго хоста H2 с каким то заданным ID, наш нат его пропустит и будет ждать назад ответа от H2 с тем же ID, и он его пропустит к H1. Проблема только в том, что этот ответ сформирует маршрутизатор, за которым сидит H2, и скорее всего наш NAT сразу же после этого удалит сопоставление IP->ID из своих таблиц и таким образом мы не сможем получить пакет от H2…
Задача сложная но интересная…

Answer 7

[ValdikSS]

samy.pl/pwnat/
Вот. Что-то вроде того, что disasm написал. Это точно работает.

Answer 8

[w66fer]

У самого похожая задача, буду пробовать следущее:

Куплю рутер с поддержкой dd-wrt.
Подниму на нём VPN сервер.
Привяжу его к DynDNS.
Подключу мобилки.

В теории всё просто и должно работать, на практике… хм… вот и узнаю.

Comments

[w66fer]

Кстати, если работать не должно, разбейте мои иллюзии, расскажите почему, съэкономите мне денежку. Спасибо.