Всем добрый день! Пытаюсь поднять игровой сервер BF2 в контейнере виртуальной машины. Но увы - из локальной сети его не видит. tcpdump -vv| grep UDP ничего не выводит - подозреваю пакеты не проходят на виртуалку, притом пакеты на хост-машину приходят. Подскажите что может быть не так? Все настройки по дефолту.. /etc/sysctl.conf net.ipv4.conf.default.forwarding=1 kernel.sysrq = 0 net.ipv4.conf.default.rp_filter=1 net.ipv4.tcp_syncookies=1 Заранее спасибо!
а icmp (ping) из локальной сети в контейнер проходит?
net.ipv4.ip_forward ? iptables -F
1. пинги и TCP трафик в контейнер проходит без проблем. 2. сеть подключена по типу bridge в контейнер не проходит непосредственно UDP трафик, т.е. tcpdump -vv | grep udp - ничего не выдает, хотя на хост-машине видно много данного трафика...
joub wrote on Sun, 17 April 2011 08:45 1. пинги и TCP трафик в контейнер проходит без проблем. 2. сеть подключена по типу bridge в контейнер не проходит непосредственно UDP трафик, Это очень необычно Сбросьте, для теста, правила iptables в контейнере и на ноде Так же запустите nmap, и протестируйте доступность UDP-порта: ключ -sU
sHaggY_caT wrote on Sun, 17 April 2011 11:21 Это очень необычно Сбросьте, для теста, правила iptables в контейнере и на ноде Так же запустите nmap, и протестируйте доступность UDP-порта: ключ -sU нет правил - полный ACCEPT. порты UDP - недоступны.
netstat -atunp внутри контейнера... Ваша программа вообще слушает этот порт? Проверьте так же nmap-ом изнутри контейнера
sHaggY_caT wrote on Mon, 18 April 2011 10:41 netstat -atunp внутри контейнера... Ваша программа вообще слушает этот порт? Проверьте так же nmap-ом изнутри контейнера изнутри контейнера все видится отлично. может чем поможет: Хост-система - debian squeeze., ядро: Linux version 2.6.32-5-openvz-686 (Debian 2.6.32-31) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Mar 8 23:30:33 UTC 2011 местами читал что проблем не должно быть в 18-м ядре, а в тех что поновее - есть, так же что она фиксится... вроде как но пака безрезультатно...
А привидите-ка все-таки вывод: netstat -atunp iptables -Ln на ноде и в контейнере, и вывод nmap -sU -p <порт UDP программы> <IP-адрес контейнера, НЕ(!) локальная петля> Изнутри контейнера и с ноды. Мы своим, не замыленным уже как у Вас взглядом посмотрим... Вдруг Вы что-то просто не замечаете? Что касается вероятности бага, имхо, 2.6.32 уже достаточно стабильно, что бы в нем были ТАКИЕ баги. Вы запостите, если мы никаких ошибок не увидим, можно будет забить баг с чистой совестью
к сожалению я решил прекратить попытки использовать данную средуи посмотрел в сторону XEN. Причины: непонятки UDP, проблемы с NFS, и прочие неприятности.
Повторюсь, у нас все работает. Мы используем астериск в контейнере, он работает (rtp-трафик) как раз через UDP. Нареканий нет совсем, даже мельчайших (тьфу-тьфу!) и сервис работает на OpenVZ-сервере стабильнее и быстрее, чем раньше работал на устаревшем ПК в роли сервера. Что касается NFS, раньше ядерный NFS внутри контейнера не работал, теперь это не так, и он работает. Но мы пока еще используем UNFSd внутри контейнера. Зря Вы все-таки не дали себе помочь, уверена, что это мелкая ошибка в конфигурировании, у Вас просто вызгляд замыленный, и Вы ее не замечали.
а могли бы вы привести пример вашей конфигурации одной из виртуалок ? а так же: версия ядра и версия самой OpenVZ. а я в сваю очередь попробую еще рез "поднять" сию виртуалку и ответить на ваши предыдущие вопросы... За ранее большое спасибо!
Последнее, стабильное RHEL5 ядро на CentOS 5 на ноде: Linux ovz07.ha-systems.ru 2.6.18-238.5.1.el5.028stab085.3PAE #1 SMP Mon Mar 21 21:09:23 MSK 2011 i686 i686 i386 GNU/Linux Конфиг контейнера: # #Параметры генерации: # ./rc.ubc.sh mem 756 - 756 Мегабайт гарантированной user-mode памяти # ./rc.ubc.sh cpu 800 1500 2800 280075 - 800Mhz гарантированных CPU, 1500 Mhz лимит (2800 280075 параметры эталонной ноды) # ./rc.ubc.sh kernel 15 - 15% ядерной памяти гарантированно ### section of other settings ####### NUMSIGINFO="1024:1024" PHYSPAGES="0:2147483647" NUMFLOCK="120:130" LOCKEDPAGES="120:130" #остальные параметры NUMPTY="80:80" NUMIPTENT="200:200" DISKSPACE="20048576:20048576" DISKINODES="600000:600000" QUOTATIME="0" ### other settings ####### # Disk quota parameters (in form of softlimit:hardlimit) ### section of kernel memory settings ####### NUMPROC="960:960" NUMFILE="30720:30720" DCACHESIZE="15728640:17301500" AVNUMPROC="320:320" KMEMSIZE="30408700:33449570" NUMOTHERSOCK="960:960" NUMTCPSOCK="1920:1920" TCPSNDBUF="9830400:14745600" TCPRCVBUF="9830400:14745600" OTHERSOCKBUF="4915200:24576000" DGRAMRCVBUF="4915200:24576000" ### end kernel memory settings ####### ### section of usermode memory settings ####### PRIVVMPAGES="3096576:4644855" VMGUARPAGES="3096576:2147483647" OOMGUARPAGES="3096576:2147483647" SHMPAGES="1548288:1548288" ### end usermode memory settings ####### ####### sections of CPU settings ########## #лимиты, установленные в мегагерцах CPUUNITS="80000" CPULIMIT="53" CPUS="1" ####### end of CPU settings ########## IP_ADDRESS="46.4.XX.XX" HOSTNAME="asterisk04.int.ha-systems.ru" VE_ROOT="/vz/root/$VEID" VE_PRIVATE="/vz/private/$VEID" OSTEMPLATE="centos-5-x86" ORIGIN_SAMPLE="vps756M" NAMESERVER="10.0.XX.XX" ONBOOT="yes" #Для работы OpenVPN DEVICES="c:10:200:rw " CAPABILITY="NET_ADMIN:on "
А может быть проблема в самом дистрибутиве ? Linux version 2.6.32-5-openvz-686 (Debian 2.6.32-31) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) Debian Squeeze
32-е ядро официально еще не является, для OpenVZ, стабильным. Но я не очень верю в то, что может быть _такой_ баг с UDP трафиком, это слишком невероятно... Имхо, Вы где-то накосячили в настройках или пакетного фильтра, или сети, или чего-то еще.
а какие параметры у вас в : /etc/sysctl.conf
[root@ovz07 ~]# sysctl -p net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.default.proxy_arp = 0 net.ipv4.ip_forward = 1 net.ipv4.conf.all.rp_filter = 1 kernel.sysrq = 1 net.ipv4.conf.default.send_redirects = 1 net.ipv4.conf.all.send_redirects = 0 fs.vsyscall = 1
sHaggY_caT wrote on Mon, 18 April 2011 17:46 А привидите-ка все-таки вывод: netstat -atunp Внутри контейнера: bf2:~# netstat -atunp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:4711 0.0.0.0:* LISTEN 3860/bf2 tcp 0 0 127.0.0.1:587 0.0.0.0:* LISTEN 1054/sendmail: MTA: tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3826/apache2 tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 363/sshd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1054/sendmail: MTA: tcp 0 0 192.168.2.41:22 192.168.2.123:1303 ESTABLISHED 1052/0 tcp 0 0 192.168.2.41:22 192.168.2.123:1372 ESTABLISHED 3868/1 tcp6 0 0 :::22 :::* LISTEN 363/sshd udp 0 0 0.0.0.0:16567 0.0.0.0:* 3860/bf2 udp 0 0 0.0.0.0:29900 0.0.0.0:* 3860/bf2 udp 0 0 0.0.0.0:55124 0.0.0.0:* 3860/bf2 udp 0 0 0.0.0.0:55125 0.0.0.0:* 3860/bf2 udp6 0 0 :::517 :::* 579/xinetd udp6 0 0 :::518 :::* 579/xinetd Quote: iptables -Ln на ноде и в контейнере, на ноде: root@srv08:/etc/init.d# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination В контейнере: bf2:~# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Quote: и вывод nmap -sU -p <порт UDP программы> <IP-адрес контейнера, НЕ(!) локальная петля> Изнутри контейнера и с ноды. нода: root@srv08:~# nmap -sU -p 16567 192.168.2.41 Starting Nmap 5.00 ( http://nmap.org ) at 2011-04-26 10:15 EEST Note: Host seems down. If it is really up, but blocking our ping probes, try -PN Nmap done: 1 IP address (0 hosts up) scanned in 0.29 seconds контейнер: bf2:~# nmap -sU -p 16567 192.168.2.41 Starting Nmap 4.62 ( http://nmap.org ) at 2011-04-26 11:16 MSD Interesting ports on bf2 (192.168.2.41): PORT STATE SERVICE 16567/udp open|filtered unknown Nmap done: 1 IP address (1 host up) scanned in 2.049 seconds с постороннего компа: srv07:~# nmap -sU -p 16567 192.168.2.41 Starting Nmap 4.62 ( http://nmap.org ) at 2011-04-26 10:19 EEST Interesting ports on 192.168.2.41: PORT STATE SERVICE 16567/udp open|filtered unknown MAC Address: 00:25:22:56:B5:EB (Unknown) Nmap done: 1 IP address (1 host up) scanned in 0.648 seconds
Quote: нода: root@srv08:~# nmap -sU -p 16567 192.168.2.41 Starting Nmap 5.00 ( http://nmap.org ) at 2011-04-26 10:15 EEST Note: Host seems down. If it is really up, but blocking our ping probes, try -PN Nmap done: 1 IP address (0 hosts up) scanned in 0.29 seconds Что-то у Вас с ноды ICMP-трафик до контейнера не ходит, странно это: Note: Host seems down. If it is really up, but blocking our ping probes, try -PN Попробуйте, как он предлагает, -PN Quote: контейнер: bf2:~# nmap -sU -p 16567 192.168.2.41 Starting Nmap 4.62 ( http://nmap.org ) at 2011-04-26 11:16 MSD Interesting ports on bf2 (192.168.2.41): PORT STATE SERVICE 16567/udp open|filtered unknown Nmap done: 1 IP address (1 host up) scanned in 2.049 seconds Quote: с постороннего компа: srv07:~# nmap -sU -p 16567 192.168.2.41 Starting Nmap 4.62 ( http://nmap.org ) at 2011-04-26 10:19 EEST Interesting ports on 192.168.2.41: PORT STATE SERVICE 16567/udp open|filtered unknown MAC Address: 00:25:22:56:B5:EB (Unknown) Nmap done: 1 IP address (1 host up) scanned in 0.648 seconds Так картина же идентична тому, что изнутри контейнера! Имхо, проблема локализована в настройках Вашей программы, а UDP трафик как раз ходит!
sHaggY_caT wrote on Tue, 26 April 2011 07:12 Что-то у Вас с ноды ICMP-трафик до контейнера не ходит ICMP - ходит! root@srv08:~# ping 192.168.2.41 PING 192.168.2.41 (192.168.2.41) 56(84) bytes of data. 64 bytes from 192.168.2.41: icmp_req=1 ttl=64 time=0.031 ms 64 bytes from 192.168.2.41: icmp_req=2 ttl=64 time=0.007 ms Quote: Попробуйте, как он предлагает, -PN а такова флага не существует (man nmap) Quote: Так картина же идентична тому, что изнутри контейнера! Имхо, проблема локализована в настройках Вашей программы, а UDP трафик как раз ходит! имхо ответ сервера(рабочего) точно такой же! да и если бы ходили UDP - они бы 100% были бы видны при помощь tcpdump - однако он молчит.
Quote: Попробуйте, как он предлагает, -PN а такова флага не существует (man nmap) Существует:) nmap -PN yandex.ru Nmap scan report for yandex.ru (87.250.251.11) Host is up (0.0046s latency). Hostname yandex.ru resolves to 6 IPs. Only scanned 87.250.251.11 Not shown: 998 filtered ports PORT STATE SERVICE 80/tcp open http 443/tcp open https Nmap done: 1 IP address (1 host up) scanned in 5.11 seconds [shaggycat@desktop2 SOURCES]$ man nmap | egrep -e '-PN' -PN: Расценивать все хосты как работающие -- пропустить обнаружение хостов Quote: имхо ответ сервера(рабочего) точно такой же! да и если бы ходили UDP - они бы 100% были бы видны при помощь tcpdump - однако он молчит. Смотрите, если бы пакеты не ходили, то там open/filtred бы не стояло! А что касается tcpdump, мне почему-то кажется, что Вы забыли ключ -i venet0
sHaggY_caT wrote on Tue, 26 April 2011 12:02 Существует:) nmap -PN yandex.ru Nmap scan report for yandex.ru (87.250.251.11) Host is up (0.0046s latency). Hostname yandex.ru resolves to 6 IPs. Only scanned 87.250.251.11 Not shown: 998 filtered ports PORT STATE SERVICE 80/tcp open http 443/tcp open https Nmap done: 1 IP address (1 host up) scanned in 5.11 seconds Смотрите, если бы пакеты не ходили, то там open/filtred бы не стояло! А что касается tcpdump, мне почему-то кажется, что Вы забыли ключ -i venet0 каюсь, с флагом -PN затупил. однако я использовал комбинацию: nmap -sU -p xx ... а вот вам пример tcpdump - больше ничего на выходе нет... bf2:/usr/local/bf2# tcpdump -i venet0 -vv | grep UDP tcpdump: WARNING: arptype 65535 not supported by libpcap - falling back to cooked socket tcpdump: listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes а так же ради эксперимента поставил в контейнере DNS-сервер, вот скан: srv05:~# nmap -sUT -p 53 192.168.2.41 Starting Nmap 4.62 ( http://nmap.org ) at 2011-04-26 19:05 EEST Interesting ports on 192.168.2.41: PORT STATE SERVICE 53/tcp open domain 53/udp open|filtered domain что может еще быть не так ?
Что там в netstat? timewait или что еще есть? Кстати, а правда named в этом контейнере работает?
sHaggY_caT wrote on Tue, 26 April 2011 15:32 Что там в netstat? timewait или что еще есть? Кстати, а правда named в этом контейнере работает? на счет работать - не знаю, но порты - открыты.
так Вы его откройте, пропишите несколько DNS-зон, и сделайте запрос: host <зона> <IP-контейнера> По-моему, вариант только один: неправильно настроенный этот Ваш игровой сервер. OpenVZ, Xen, или что-то еще тут совсем не причем.
sHaggY_caT wrote on Tue, 26 April 2011 18:23 так Вы его откройте, пропишите несколько DNS-зон, и сделайте запрос: host <зона> <IP-контейнера> По-моему, вариант только один: неправильно настроенный этот Ваш игровой сервер. OpenVZ, Xen, или что-то еще тут совсем не причем. Честно я уже устал всем доказывать. 1. Я сравнивал приходящие пакеты на реальный и виртуальный сервер о чем было выше и уже не раз. 2. Если все работает - почему я не вижу внутри контейнера широковещательных запросов? (на реальном - все есть) 3. Серверная часть игру не имеет настроек касательно сетевого интерфейса или IP адресов! Все что касается сети - это UDP порт(16567). Может быть проблема в сырости VZ для моего ядра !? Все у кого удачно все работает: отпишитесь! - какая версия ядра и что за хост-система?
Вы тут упомянули широковещательные запросы, для venet они не работают, т.к. это соединение точка-точка. Для сервисов, для которых нужны броадкасты, нужно использовать veth-интерфейсы, вставленные на ноде в бридж с реальным интерфейсом ноды. Например, veth нужен для dhcp и tftp. У интерфейса venet нет мак-адреса, который есть у veth, но, зато, venet работает без некоторых накладных расходов, которые есть у veth. А что касается доказывания, результаты nmap как раз и говорят, что UDP-пакеты прекрасно ходят... Имхо, дело в настройках Вашей программы.
sHaggY_caT wrote on Wed, 27 April 2011 04:58 Вы тут упомянули широковещательные запросы, для venet они не работают, т.к. это соединение точка-точка. Для сервисов, для которых нужны броадкасты, нужно использовать veth-интерфейсы, вставленные на ноде в бридж с реальным интерфейсом ноды. Например, veth нужен для dhcp и tftp. У интерфейса venet нет мак-адреса, который есть у veth, но, зато, venet работает без некоторых накладных расходов, которые есть у veth. А что касается доказывания, результаты nmap как раз и говорят, что UDP-пакеты прекрасно ходят... Имхо, дело в настройках Вашей программы. Вот эти запросы мне и нужны видимо... Где можно глянуть про veth - только в Гугл не посылайте, он со мной не дружит. А на счет программы еще раз повторюсь - ОНА НЕ ИМЕЕТ НИКАКИХ НАСТРОЕК КАСАТЕЛЬНО СЕТИ КРОМЕ ТОЛЬКО ПОРТА!!! так что в не в ней дело.
joub wrote on Wed, 27 April 2011 03:54 Вот эти запросы мне и нужны видимо... Где можно глянуть про veth - только в Гугл не посылайте, он со мной не дружит. И не думала. Гугл вообще дурной тон, читать нужно всегда и везде официальную документацию, вот, собственно, она по veth: http://wiki.openvz.org/Veth Если с английским плохо, можете попробовать использовать Google translate joub wrote on Wed, 27 April 2011 03:54 А на счет программы еще раз повторюсь - ОНА НЕ ИМЕЕТ НИКАКИХ НАСТРОЕК КАСАТЕЛЬНО СЕТИ КРОМЕ ТОЛЬКО ПОРТА!!! так что в не в ней дело. Если ей нужны броадкасты и мак-адреса, то она не может работать через интернет, только в локалке, в одной L2.
sHaggY_caT wrote on Wed, 27 April 2011 06:27 http://wiki.openvz.org/Veth почитал, настроил , клиенты увидели сервак - но! ужасный пинг... C:\Users\us>ping 192.168.2.42 -t Обмен пакетами с 192.168.2.42 по с 32 байтами данных: Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса. Ответ от 192.168.2.42: число байт=32 время=4мс TTL=64 Ответ от 192.168.2.42: число байт=32 время=1мс TTL=64 Ответ от 192.168.2.42: число байт=32 время<1мс TTL=64 Ответ от 192.168.2.42: число байт=32 время=1мс TTL=64 Ответ от 192.168.2.42: число байт=32 время<1мс TTL=64 Ответ от 192.168.2.42: число байт=32 время<1мс TTL=64 Ответ от 192.168.2.42: число байт=32 время=1мс TTL=64 Ответ от 192.168.2.42: число байт=32 время=1мс TTL=64 Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса. Ответ от 192.168.2.42: число байт=32 время=3мс TTL=64 Ответ от 192.168.2.42: число байт=32 время=1мс TTL=64 Ответ от 192.168.2.42: число байт=32 время<1мс TTL=64 Ответ от 192.168.2.42: число байт=32 время=1мс TTL=64 Ответ от 192.168.2.42: число байт=32 время=1мс TTL=64 Ответ от 192.168.2.42: число байт=32 время=1мс TTL=64 и далее в таком же духе.... из-за этого у клиентов вылетает тайм-аут и соответственно не дает запускать дальше... Quote: Если ей нужны броадкасты и мак-адреса, то она не может работать через интернет, только в локалке, в одной L2. что это значит ? по сути мне нужен локальный сервак и все.
Знаете, Вы определенно делаете что-то не так так как мы с Вами убили уже кучу времени, мне жалко так просто бросать Вашу проблему, Вы не побоитесь дать поковыряться на Вашей машине? Можно в одной сессии screen.