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

Другими словами, как установить «р2р-соединение» по протоколу ICMP между двумя мобильными терминалами?
3 февраля в 11:07
2
Если Вы убеждены в том, что это невозможно-в-принципе, и даже можете объяснить, почему — то, лучше ничего не пишите в ответ. 1010101001000100110100111,
вывод ipconfig/ifconfig и трассу вовне можно посмотреть?
есть несколько способов организации APN
strib,
я так понял — конечная цель гонять данные между мобилками и не платить за трафик? viperet,
Конечная цель немного иная: эти два терминала (их может быть и больше двух) резервируют друг-друга. Важно чтобы у каждого из них был «свой» постоянный Интернет. Как только ICMP-связность этих двух терминалов пропадает регистрируется «сработка» и оба терминала переходят в «аварийный» режим, в котором они за некоторое время должны восстановить связность (вплоть до установки прямой связи по GSM-голосовому каналу 9600 бит/с). Если им это не удается за какое-то время, то каждый из терминалов генерирует сигнал «тревога» (и, например, запускает программу самоликвидации). 1010101001000100110100111,

отсортировано по дате по оценке
ответы (8)

+1
isden #
Я вижу 2 варианта:
1. Простой — DynDNS на клиентских компах. Т.е. при любой смене ip мы все равно можем обращаться к хосту по имени.
2 Сложнее — некий третий узел-посредник с известным фиксированным адресом и VPN-сервером на борту.
К сожалению, DynDNS в случае с мобильными терминалами не пройдет — так как терминалы находятся за NAT'ом, и один IP-адрес делится между несколькими узлами. А, пропинговать нужно вполне-себе конкретный узел. 1010101001000100110100111, 3 февраля в 11:43
+1
Evengard #
Вижу только вариант с Hamachi или подобным (VPN). Дело всё в том, что мобильный инет ОПСОСы обычно старательно NAT-ят. А значит вам придётся прорваться через 2 NAT-а (минимум — 1 на вашей стороне, 1 — на другой) а то и больше.
Прорваться через такое количество NAT-ов и без GPRS-а не всегда выходит…
Так что только VPN.
Я так понял, VPN-сервер в этом случае нужно будет на каком-то третьем узле поднимать (причем с белым адресом)? 1010101001000100110100111, 3 февраля в 13:48
+1
KY3EH #
Вроде тут было что-то подобное описано.
0
Maxim_ka #
Установить тимвьювер на обе машинки, и сможете видеть друг друга, в случае чего, и опять же для проверки.
К сожалению, это решение создает слишком уж большой объем «левого» трафика.
В идеале хотелось бы чтобы после успешного «пробивания» двух NAT'ов оба терминала могли общаться обмениваясь только лишь ICMP-пакетами.
1010101001000100110100111, 3 февраля в 13:16
+1
Disasm #
Сначала через какой-нибудь сервер определить внешний IP друг друга, а потом кидаться в эти айпишники ICMP пакетами с терминалов.
Свои собственные «Внешние» IP определить (и передать друг-другу) как раз-таки не проблема, а, вот, что дальше-то с ними (ай-пишниками) делать? 1010101001000100110100111, 3 февраля в 14:25
Пинговать друг друга. Пакеты будут проходить через NAT так как роутер будет считать что пакет извне — ответ на ушедший изнутри пакет. Disasm, 3 февраля в 14:41
No pasaran! (они не пройдут)
Он (роутер) так не будет считать, ведь он же видел, что изнутри никакие пакеты никуда не уходили. И, к тому же, кроме моего узла есть еще куча других сидящих под этим же NAT'ом, и неизвестно, кому из них пакет слать.
1010101001000100110100111, 3 февраля в 15:19
Так надо чтоб ходили. Узел А отправляет пакет в сторону узла Б (он может быть не дойдёт), в это же время узел Б отправляет пакет в сторону узла А. Роутер узла А думает что это ответ на первый пакет и он (пакет) проходит внутрь и доходит до узла А. Disasm, 3 февраля в 15:30
+1
viperet #
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…
Задача сложная но интересная…
+1
ValdikSS #
samy.pl/pwnat/
Вот. Что-то вроде того, что disasm написал. Это точно работает.
0
w66fer #
У самого похожая задача, буду пробовать следущее:

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

В теории всё просто и должно работать, на практике… хм… вот и узнаю.
Кстати, если работать не должно, разбейте мои иллюзии, расскажите почему, съэкономите мне денежку. Спасибо. w66fer, 7 февраля в 04:18

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.