Решая задачу о связывании двух сетей через интернет (both Win32), возникло несколько вопросов по разным путям реализации:

1. Есть ли способ перехватывать ARP пакеты (request/reply) через SOCK_RAW или другим non-driver способом? Если мне и придется залезть в драйвера, смогу ли я оттуда малой кровью установить TCP соединение на другом интерфейсе или придется данные из user-mode выковыривать, чтобы воспользоваться функциональностью WinSock?

2. Если я использую socket(AF_INET, SOCK_RAW, IPPROTO_IP) и выставляю IPPROTO_INCLHDR, как используются поля src_ip, dst_ip переданного в буфере IP header'а? Т.е. заменяется ли src_ip на IP прибинденного интерфейса (а если bind'а не было?) и заменяется ли dst_ip на адрес, указанный в "sendto"? Можно ли при этом использовать просто "send", чтобы инфа о цели бралась из IP header'а?

3. Существуют ли виртуальные TCP-based сетевые адаптеры? Т.е., используя уже установленные сетевые интерфейсы, машина A коннектится на машину B (B имеет внешний IP адрес), после чего установленный TCP канал используется как виртуальный "провод" между созданными виртуальными "сетевыми адаптерами". Это позволило бы использовать эти адаптеры как gateways между сетями. VPN соединение как gateway работать не хочет (видимо из-за PPP-шной маски подсети 255.255.255.255), да и с ARP оно не дружит (according to MSDN).

4. Учитывая семантику IP протокола, п.3 можно заменить на UDP, но это потребует хотя бы одной машины со внешним IP адресом в _каждой_ сетке. От TCP в моей задаче не требуется flow/sequence control, но требуется возможность получать данные обратно на "серый" IP после установки соединения. ВОПРОС: Что именно позволяет сделать это в TCP/IP? Прочитав оба RFC, посвященные TCP и IP протоколам, я не нашел связки, которая позволяет направлять данные обратно от yandex.ru на серый бред вроде 192.168.0.1, с которого пришел запрос на коннект. Может быть это сделано на уровне gateways (kinda NAT substitution) или используются IP header options (запоминание gateways по дороге)? Реально ли создать UDP-alike протокол, но с обратной связью как у TCP? Если это в итоге окажется свой протокол со своим номером (TCP,UDP,MY_STUFF), пропустит ли MY_STUFF бОльшая часть WAN gateways?

Заранее спасибо за ответы!

Цитата(Harkonnen @ 14.7.2005, 16:10)

но требуется возможность получать данные обратно на "серый" IP после установки соединения. ВОПРОС: Что именно позволяет сделать это в TCP/IP? Прочитав оба RFC, посвященные TCP и IP протоколам, я не нашел связки, которая позволяет направлять данные обратно от yandex.ru на серый бред вроде 192.168.0.1, с которого пришел запрос на коннект.

Ничего удивительного, что ответ не придет. Удивительно будет, если он до яндекса доберется - значит масса провайдеров на маршрутизаторах "забыли" порезать серые сети. Представь, что тебе пришло письмо, а вместо обратного почтового адреса просто надпись "работник Иванов". Куда ответ отправлять?

Цитата(Harkonnen @ 14.7.2005, 16:10)

Может быть это сделано на уровне gateways (kinda NAT substitution) или используются IP header options (запоминание gateways по дороге)? Реально ли создать UDP-alike протокол, но с обратной связью как у TCP? Если это в итоге окажется свой протокол со своим номером (TCP,UDP,MY_STUFF), пропустит ли MY_STUFF бОльшая часть WAN gateways?

Нет, нет, и на третий вопрос тоже нет . ПРотоколы здесь вообще не причем. Это все основы маршрутизации семейства TCP/IP. Если ты сидишь за NAT'ом, то да, ты будешь поддерживать связь с другим публичным хостом. Если нужно связаться с другой серой сеткой, то необходимо обеспечить такую возможность на соотвествующем хосте, который ее в инет выводит (например пробросить порты в NAT или создать DMZ).

Вообще в чем суть вопроса? какая цель преследуется?

DENNN
Цель следующая: связать две сети. Будет ли это в итоге одна сеть (i.e. 10.0.0.x, либо две с routing'ом друг на друга через gateways в обеих - не важно). Суть в том, что сегменты разделены интернетом (via GPRS), а не хабом. По идее, эту проблему как раз решеат VPN. Но то ли в XP Pro он жутко кастрированный, то ли VPN её все-таки не решает. Я пока не могу понять, как VPN может её решить, если он из-за PPP в своей основе не поддерживает ни ARP, ни подсети 255.255.255.0. ARP в случае разных сетей (192.168.0.x и 10.0.0.x) не нужен, но в случае одной сети 10.0.0.x он потребуется, а PPP коннект форвардить эти запросы не станет (как и не станет форвардить пакеты с src_ip/dst_ip, отличными от его собственного IP, т.е. он не может быть gate'ом).

Почитаю про NAT/DMZ c целью использовать их свйства в двустороннем обмене данными через UDP (если это возможно). Я уже готов к тому, чтобы с помощью DDK создать виртуальный сетевой адаптер, являющийся gateway'ем между кусками сети, используя TCP для форварда Ethernet пакетов, и пошли все эти заморочки с протоколами лесом (выдержал бы GPRS кросс-сегментный трафик, придется по MAC адресам отличать кросс-траффик от внутреннего обмена, как в умном свитче).

TCP в данном случае слегда оверхэден. Он позволяет:
1) Сидя за NAT'ом иметь двустороннюю связть с public host.
2) sequence control (byte order).
3) flow control (write-ahead length limit).

Т.к. всё сведется к форварду IP/ICMP/ARP пакетов (или даже Ethernet пакетов, чтобы не морочаться), то от TCP мне в итоге портебуется только (1), т.к. один из связываемых сегментов сидит за серым IP (через GPRS). Sequence control(2) и flow control(3) мне не нужны, т.к. они не нужен для IP/ARP/ICMP/(Ethernet?).

Цитата(Harkonnen @ 15.7.2005, 10:26)

либо две с routing'ом друг на друга через gateways в обеих - не важно

Елсли не важно, то почему бы так и не сделать?

Цитата(Harkonnen @ 15.7.2005, 10:26)

а PPP коннект форвардить эти запросы не станет (как и не станет форвардить пакеты с src_ip/dst_ip, отличными от его собственного IP, т.е. он не может быть gate'ом).

почему нет? Ты не путай, он выполняет задачи транспорта а не маршрутизатора. У меня одна из сетей замечательно в инет ходит именно через PPTP.

Цитата(Harkonnen @ 15.7.2005, 10:26)

Почитаю про NAT/DMZ c целью использовать их свйства в двустороннем обмене данными через UDP (если это возможно).

Просто пробрось нужные тебе порты через NAT на внутреннюю машину. Это самое простое решение.

Цитата(Harkonnen @ 15.7.2005, 10:26)

Т.к. всё сведется к форварду IP/ICMP/ARP пакетов (или даже Ethernet пакетов, чтобы не морочаться)

ARP (Ethernet) не ворвардится и не маршрутизируется. Это и не нужно.
Добавлено @ 14:12
Вообще, если ставить задачу соединения одного сегмента через PPP, то необходимо на обоих концах поднимать BRIDGE. На счет встроенных средств винды не скажу (но использовать хрюшу для серверных здач, ИМХО, убийство собственных нервов), а тот же MPD из портов BSD имеет настройки Arp-proxy для соединения