Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Не могу пробить NAT, UDP создает канал (5 стр)

Не могу пробить NAT, UDP создает канал (5 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
ZabПостоялецwww13 дек. 201713:45#60
Dampire
Смешно было бы, если б я помогать сунулся, не сталкиваясь ранее с этим и не имея возможности посмотреть сейчас.

Значит, не везде по умолчанию full cone? Это экзотика или нечто массовое?
SOHO это ведь оборудование для сверхмалых сетей? Там то чем помогут строгости? Все равно у юзера бардак полный.
Единственное что приходит в голову - так боролись со сканированием портов во времена до выхода XP SP3, когда дыры в XP залатали. Так это когда было... Да и full cone нат вполне противостоял вирусам, проблемные порты то обычно не пробиты.

CoderInTankПостоялецwww13 дек. 201713:45#61
Отличная шутка, но NAT не зарезервирует за клиентом все 65 тысяч портов, скорее всего он этого клиента заблочит после первых 500 пакетов.

Не заблочит, не отрубается же интернет после полного сканирования кого нить по UDP. Может в худшем случае хранить не все 64к записей, а 500 последних) Но насколько мне известно, это вполне реальный способ пробития NAT, когда 2 клиента сканируют друг друга до случайного установления связи. Кстати, до факта пробития можно пускать трафик через сервер, чтобы для юзера не было задержек.

Есть еще варианты?

Все варианты давно уже известны(не мне), что то новое придумать вряд ли получится.

Вторая проблема, 2 ПК стоят за одним роутером и одним NAT-ом. Сервер получает из внешние адреса (они всегда одинаковые, они отличаются только портами), оба ПК узнают их...
Вопрос, как NAT провайдера справится с этим, ведь для него конечная точка одна - роутер, с его двух портов идут пакеты на внешний адрес...
Короче, это абсурд получается.
Ну вот например, моя локальная сеть устроена таким образом, что у роутера IP 192.168.0.1, а клиентам он выдает адреса 192.168.0.Х. Клиенты могут отправлять друг другу пакеты напрямую, по нужному адресу, но слать их на IP роутера бессмысленно.
Железо провайдера определит, что от него требуется в таком случае? 

Вообще не вижу проблемы. Внешний адрес NAT'а доступен всем интернету. Зачем делать его недоступным или каким то особенным для внутренних клиентов? Если только специально ограничивать, однако для этого нужны какие то причины.

DampireПостоялецwww13 дек. 201714:10#62
Ramm
> родным инетом виртуалки
Каким родным инетом виртуалки? Который NAT в VirtualBox или bridge? Ты знаешь какой там тип ната? Я вот не знаю например.
> "Удаленный хост принудительно разорвал существующее подключение"
Што? Мы точно про UDP говорим? Какое нах подключение в UDP? Какой разрыв?
> и с другого ПК за роутером, результат все равно один
Это "я так думаю" или проверено? У VirtualBox по умолчанию стоит тип сети - NAT и какого он типа я понятия не имею.
DampireПостоялецwww13 дек. 201714:14#63
Zab
> Значит, не везде по умолчанию full cone?
У меня дома port-restricted cone. На работе стоит симметричный вообще.
SOHO это малый офис или домашнее.
25cmПользовательwww13 дек. 201714:27#64
Ramm
на виртуалке открой chrome, вбей адрес "about:blank", открой консоль разработчика (F12), вкладка console. туда вставь код и нажми enter. Если у тебя symmetric NAT ты получишь сообщение в консоли 'symmetric nat' или 'normal nat' в противном случае.

код:

// parseCandidate from https://github.com/fippo/sdp
function parseCandidate(line) {
  var parts;
  // Parse both variants.
  if (line.indexOf('a=candidate:') === 0) {
    parts = line.substring(12).split(' ');
  } else {
    parts = line.substring(10).split(' ');
  }

  var candidate = {
    foundation: parts[0],
    component: parts[1],
    protocol: parts[2].toLowerCase(),
    priority: parseInt(parts[3], 10),
    ip: parts[4],
    port: parseInt(parts[5], 10),
    // skip parts[6] == 'typ'
    type: parts[7]
  };

  for (var i = 8; i < parts.length; i += 2) {
    switch (parts[i]) {
      case 'raddr':
        candidate.relatedAddress = parts[i + 1];
        break;
      case 'rport':
        candidate.relatedPort = parseInt(parts[i + 1], 10);
        break;
      case 'tcptype':
        candidate.tcpType = parts[i + 1];
        break;
      default: // Unknown extensions are silently ignored.
        break;
    }
  }
  return candidate;
};

var candidates = {};
var pc = new RTCPeerConnection({iceServers: [
    {urls: 'stun:stun1.l.google.com:19302'},
    {urls: 'stun:stun2.l.google.com:19302'}
]});
pc.createDataChannel("foo");
pc.onicecandidate = function(e) {
  if (e.candidate && e.candidate.candidate.indexOf('srflx') !== -1) {
    var cand = parseCandidate(e.candidate.candidate);
    if (!candidates[cand.relatedPort]) candidates[cand.relatedPort] = [];
    candidates[cand.relatedPort].push(cand.port);
  } else if (!e.candidate) {
    if (Object.keys(candidates).length === 1) {
      var ports = candidates[Object.keys(candidates)[0]];
      console.log(ports.length === 1 ? 'normal nat' : 'symmetric nat');
    }
  }
};
pc.createOffer()
.then(offer => pc.setLocalDescription(offer))

RammПостоялецwww13 дек. 201714:37#65
Dampire
> Што? Мы точно про UDP говорим? Какое нах подключение в UDP? Какой разрыв?
Я хз, вот щас попробовал словить - получилось.
Я его еще ловлю, когда, например, на второй ПК в локалке пакеты шлю на случайный порт, который не слушают.
И вылетает оно, когда я смотрю что пришло, вот тут (C#):
bytes = udp.ReceiveFrom(data, ref remoteIp);
Аналогичная проблема у человека из 2013 года:
http://www.cyberforum.ru/csharp-net/thread1554160.html
Вот такая вот хрень.
25cmПользовательwww13 дек. 201714:41#66
В инете где то прочитал что если раздать WIFI с айфона - то будет symmetric NAT.
Еще прочитал что сеть скайпа старается клиентов соединять через p2p, но если это не работает, используются UDP и TCP relay серверы.
Так что пробитие + relay_сервера = 100% охват. Но это уже сложнее в реализации. Поправьте если я не прав.

А вообще если делать игруху, то я б забил на symmetric. Насколько я понял их практически нет на домашних роутерах или встречаются крайне редко.
А еще лучше вообще юзать не p2p а клиент-сервер. 

25cmПользовательwww13 дек. 201714:46#67
Ramm
после socket.Bind добавь
try
      {
        const uint IOC_IN = 0x80000000;
        const uint IOC_VENDOR = 0x18000000;
        uint SIO_UDP_CONNRESET = IOC_IN | IOC_VENDOR | 12;
        socket.IOControl((int)SIO_UDP_CONNRESET, new byte[] { Convert.ToByte(false) }, null);
      }
      catch
      {
        // ignore; SIO_UDP_CONNRESET not supported on this platform
      }
должно помочь
RammПостоялецwww13 дек. 201715:00#68
25cm
Да, супер, этот код помогает.
Я, блин, какой-то особенный, наверное...
Я тут почитал...
https://stackoverflow.com/questions/38191968/c-sharp-udp-an-exist… e-remote-host
и на русском:
http://forum.sources.ru/index.php?showtopic=276334
Уведомление ICMP типа source quench иногда называют также "подавление источника". Его можно рассматривать как примитивный инструмент сдерживания потоков, генерируемых отправителем, но нельзя причислить к эффективным методам контроля за перегрузками. В ранних UNIX-реализациях протоколов TCP/IP ICMP-пакеты этого типа игнорировались. В TCP-реализациях, поддерживающих алгоритм медленного старта, в ответ на это сообщение уменьшается размер "окна перегруженности

Это типа мне на сокет приходит сообщение, чтобы я заткнулся... Поэтому и генерируется оно именно при просмотре того, что пришло на сокет... И вылететь оно может после ПЕРВОГО пакета, не сотни в секунду, не при перегрузке сети, а сразу.
И вопрос, кто мне это уведомление присылает? Клиент, провайдер, маршрутизатор?


Вот так,  а Dampire даже не в курсе,  что такое может быть.

DampireПостоялецwww13 дек. 201715:01#69
Даже в UDP, который должен просто работать протащили проверку портов.
http://microsoft.public.win32.programmer.networks.narkive.com/Rlx… reset-problem
Решение выше уже кинули.
25cm
Симметричный тоже пробивается, но только если против него стоит restricted (кинуть пакет на любой порт симметричного, что откроет порт для подключения с той стороны) или full cone (тут очевидно как делать). А так да, релейки дадут 100% покрытие.
> А еще лучше вообще юзать не p2p а клиент-сервер.
Дедики снаружи для инди дорого, а селфхостинг требует решения ровно тех же проблем с натом.

Правка: 13 дек. 2017 15:06

DampireПостоялецwww13 дек. 201715:03#70
Ramm
> Вот так, а Dampire даже не в курсе, что такое может быть.
Это какая-то надстройка. Я работаю в крестах с сокетами и все работает ровно так, как и должно.
RammПостоялецwww13 дек. 201715:12#71
25cm
'normal nat'
25cmПользовательwww13 дек. 201715:14#72
Dampire
> Дедики снаружи для инди дорого, а селфхостинг требует решения ровно тех же
> проблем с натом.
Тут конечно все зависит от инди, но ИМХО нынешние цены на VPS вполне доступны. Под линух особенно.
А открывать 100 серверов конечно дорого, надо начинать с одного и добавлять по мере роста =)
RammПостоялецwww14 дек. 201711:51#73
Ребят, последний вопрос, то делать, если клиенты находятся за одним и тем же натом, сервер определяет их адреса одинаковыми, отличаются только порты. Клиентам пытаться стучать на полученные адреса-порты?
ZabПостоялецwww14 дек. 201713:19#74
Ramm
> Клиентам пытаться стучать на полученные адреса-порты?
Если через общий механизм, то так. Должно работать.
Но физически возможна связь и чисто внутри локальной сети. Будешь предусматривать отдельный способ соединения на этот случай? Это нужно?
Во многих играх оно реализовано. Обычно поиск производится броадкастами или же явно вбивается ip-адрес. Сервер-посредник для поиска участников игры не используется.
Страницы: 1 2 3 4 5 6 7 Следующая »

/ Форум / Программирование игр / Сеть

2001—2018 © GameDev.ru — Разработка игр