Здравствуйте, x-code, Вы писали:

XC>В обоих случаях ip внутренние.
XC>нужен БЕСПЛАТНЫЙ сервис, позволяющий моему приложению пробить между ними tcp или udp канал.

Фигня в том, что в общем случае задача в принципе нерешаема. Почитай RFC3489 про так называемый symmetric NAT.
Ты на этот сервер идёшь, тебе выдали внешний адрес на NAT, например, 1.2.3.4:5678. Хорошо, можно с ним общаться.
Но чтобы выйти не на сервер, а на пиира, тебе дадут адрес 1.2.3.4:9012. И вот его ты предсказать не сможешь.

NAT в домашних раутерах чаще конусовый, чем симметричный, с ним будет работать, тогда просто бесплатный STUN сервер поможет. Но чем крупнее сеть (предприятие или второй уровень NAT провайдера), тем вероятнее "симметричная" реализация.

В случае TCP есть ещё одно осложнение: входящие на незарегистрированные ассоциации обычный NAT не пропускает. Тебе нужен особый режим старта TCP — не сервер c listen() и клиент с connect(), а два встречных connect() друг к другу, зная точные назначенные адреса. TCP как протокол такое умеет, но не любой стек такое позволяет. (В SCTP так вообще его запретили.) На FreeBSD старых (примерно до 5.0) ещё такое работало. На Linux и новых FreeBSD я уже не могу добиться, чтобы это сработало, при попытке встречного коннекта идёт RST и всё.
Остаётся UDP.

Здравствуйте, x-code, Вы писали:

XC>В обоих случаях ip внутренние.
XC>нужен БЕСПЛАТНЫЙ сервис, позволяющий моему приложению пробить между ними tcp или udp канал.

Фигня в том, что в общем случае задача в принципе нерешаема. Почитай RFC3489 про так называемый symmetric NAT.
Ты на этот сервер идёшь, тебе выдали внешний адрес на NAT, например, 1.2.3.4:5678. Хорошо, можно с ним общаться.
Но чтобы выйти не на сервер, а на пиира, тебе дадут адрес 1.2.3.4:9012. И вот его ты предсказать не сможешь.

NAT в домашних раутерах чаще конусовый, чем симметричный, с ним будет работать, тогда просто бесплатный STUN сервер поможет. Но чем крупнее сеть (предприятие или второй уровень NAT провайдера), тем вероятнее "симметричная" реализация.

В случае TCP есть ещё одно осложнение: входящие на незарегистрированные ассоциации обычный NAT не пропускает. Тебе нужен особый режим старта TCP — не сервер c listen() и клиент с connect(), а два встречных connect() друг к другу, зная точные назначенные адреса. TCP как протокол такое умеет, но не любой стек такое позволяет. (В SCTP так вообще его запретили.) На FreeBSD старых (примерно до 5.0) ещё такое работало. На Linux и новых FreeBSD я уже не могу добиться, чтобы это сработало, при попытке встречного коннекта идёт RST и всё.
Остаётся UDP.

UPD: Рядом намекнули на настройку раутера с пробросом входящих.
Это не полностью соответствует задаче, но может помочь.

Я ещё забыл написать, что именно из-за этой проблемы рекламируют, что "в IPv6 не нужен NAT". Но там тоже сложно.
Если входящие открыты и security by obscurity на незнании внутренних адресов, то достаточно заставить зайти на подконтрольный сайт, чтобы узнать адрес.
Если входящие закрыты, то просто так TCP не пробросишь, см. выше.
Если входящие открыты для SLAAC-адресов, то опять SbO, но на короткий срок.
Решать по-человечески пока никто не захотел.