NAT и fsinn

[grfmaniak]

Появился у меня клиент, играет в онлайн-симуляторе самолетном под названием fsinn. Все у него ок, толко вот голос, говорит, в программе не работает (они там между собой переговариваются голосом по ходу игры). Пока выходил по диалапу, где ему давался реальный ip - все работало. Как только подключился по adsl и стал сидеть за моим NATом на cisco - с голосом проблемы. Все входящие порты для всех открыты. Подключение идет по vpn-pptp. mtu=1492

В чем может быть проблема? Может кто сталкивался.

Edited August 21, 2006 by grfmaniak

[Microsoft]

"Все входящие порты для всех открыты"

Это еще ничего не значит. Что вы думаете должен сделать NAT, когда на его собственный адрес приходит пакет, для которого нет записи в таблице NAT? Какому клиенту из подключенных его слать?

[grfmaniak]

пакет, для которого нет записи в таблице NAT? Какому клиенту из подключенных его слать?

сферические кони в вакууме - это инетересно, но хотелось бы конкретики

[GateKeeper]

grfmaniak, вся конкретика по данному вопросу находится в пределах одного запроса на гугле по дополнительному ключевому слову RFC. Или таки ссылочки подкинуть?

[grfmaniak]

grfmaniak, вся конкретика по данному вопросу находится в пределах одного запроса на гугле по дополнительному ключевому слову RFC. Или таки ссылочки подкинуть?

Я так думаю, авторы IOS читали RFC, когда разрабатывали свою реализацию NAT. Авторы игрушки наверное тоже, раз в ней предусмотрена работа через него. Так же меня терзают сомнения, что провайдеры в массовом порядке раздают всем клиентам реальные IP. Потому и инетерсно, какие конкретно могут быть подводные камни в конкретно этом случае.

А ссылкой на RFC - зачем тогда вообще форум организовывать? Надо вывесить здесь RFC и на все вопросы тыкать в него. А вместо темы "Работа с бумагами" - вывесить закон о связи. И будет всеобщее счастье, надо полагать.

 

 

Нат настроен так:

 

Внутренний инетрефейс:

interface FastEthernet0/0.11

description PPTP VPN

encapsulation dot1Q 11

ip address 192.168.11.1 255.255.255.0

no ip redirects

ip nat inside

ip virtual-reassembly

no snmp trap link-status

no cdp enable

 

interface Virtual-Template1

ip unnumbered FastEthernet0/0.11

ip access-group 101 in

ip mtu 1492

ip nat inside

ip virtual-reassembly

autodetect encapsulation ppp

peer default ip address pool vpn

no keepalive

ppp authentication ms-chap-v2

!

 

Внешний:

 

interface Serial0/0:0

ip address 222.222.222.222 255.255.255.252

ip access-group main-in in

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip virtual-reassembly

encapsulation ppp

ip route-cache policy

ip route-cache flow

ip policy route-map priv-acc

no cdp enable

!

ip nat pool adsl 123.123.123.123 123.123.123.123 netmask 255.255.255.252

ip nat inside source list 2 pool adsl overload

 

ip access-list extended main-in

permit ip any host 123.123.123.123

deny ip 192.168.0.0 0.0.255.255 any log

deny ip 0.0.0.0 0.255.255.255 any log

deny ip host 255.255.255.255 any log

deny ip 127.0.0.0 0.255.255.255 any log

deny ip 224.0.0.0 15.255.255.255 any log

deny ip 240.0.0.0 7.255.255.255 any log

deny ip 10.0.0.0 0.255.255.255 any log

deny ip 172.16.0.0 0.15.255.255 any log

deny ip 192.0.2.0 0.0.0.255 any log

deny ip 169.254.0.0 0.0.255.255 any log

deny ip any any log

 

 

access-list 2 permit 192.168.11.0 0.0.0.255

access-list 101 permit ip 192.168.11.0 0.0.0.255 any

Edited August 22, 2006 by grfmaniak

[GateKeeper]

Я так думаю, авторы IOS читали RFC, когда разрабатывали свою реализацию NAT.

Да, читали, раз NAT работает на цисках, и ни у кого жалоб не было

 

Авторы игрушки наверное тоже, раз в ней предусмотрена работа через него.

С FTP через NAT когда-нибудь работали? Помните, как там повсеместно кричат: "For your ftp-client to work through NAT use passive ftp mode", что на практике означает лишь следующее: "мы гарантируем Вам работоспособность фтп-клиента только в том случае, если все соединения будет инициировать Ваш клиент (читай: создавать запись в state-таблице NAT'а, через который Вы ходите), ибо иначе этого невозможно сделать без конкретной настройки самого NAT".

 

Либо создавайте перманентный порт-мап на внешнем интерфейсе вида:

 

"any -> outer_interface:port_A" <=> client_A:port_B

при этом port_A и port_B могут совпадать

[grfmaniak]

мне просто кажется, может тут дело не в самом NAT, а в выставлении MSS или размере MTU. Я с этим еще как-то дела не имел (mss).

[ShumBor]

Скорее всего голос идет там по upd и порты на прием передачу различны.

Пример:

Программа использует для обмена 2 порта - передача 16345, приема 16346.

получается 2 разный потока(со стороны машины А):

1 исходящий: порт источника(А машина) 16345 -> порт получателя(Б машина) 16346

2 входящий: порт источника(Б машина) 16345 -> порт получателя(А машина) 16346

Соответственно в нате будет только запись о первом потоке

2 он откинет так как не знает адрес куда слать пакет.

Соответстенно ему надо об этом сказать, о чем говорилось выше.

Я в свои времена с батлнетом натрахался по этому поводу.

Там порт отправителя - рандомно, а порт получателся всегда 6112.

[desperado]

млин... тут же всё как ясный день.

игрушка юзает 2 вида трафика:

1. TCP от клиента к серверу, который отлично натится без всяких прибамбасов.

2. некий трафик между клиентами (дабы не грузить сервер), который ессесно не натится, мало того между двумя клиентами за разными натами вообще никакой трафик ходить не будет. Всякие пробросы портов это дурь и не надо этим заниматься. Дайте ему прямой адрес, пусть радуется.

 

 

PS

GateKeeper

FTP в активном режиме научились натить еще в каменном веке.

[boykov]

trafshow на него напустить не пробовали во время игры?

или его батьку -- tcpdump (на обоих интерфейсах рутера)