openvpn No route to host (code=113) после 6ти вечера%)

[shtok]

Всех с окончанием рабочей недели) Ребята помогите разобраться, поднял на сервере openvpn  2.1.3-2  конфиги ниже,все работает хорошо, но вот в конце рабочего дня ближе к пол 6го начинает отваливаться интернет, кто сидит напрямую без впн все работает, привожу логи с ошибками, может кто уже сталкивался с подобным.

Код: [Выделить]

Fri Feb  3 17:22:44 2012 us=237550 valeevirchat.imsp/192.168.2.170:1194 write UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Fri Feb  3 17:22:44 2012 us=358365 oleneva.imsp/192.168.2.221:1194 write UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Fri Feb  3 17:22:44 2012 us=361128 valeevirchat.imsp/192.168.2.170:1194 write UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Fri Feb  3 17:22:44 2012 us=489094 oleneva.imsp/192.168.2.221:1194 write UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Fri Feb  3 17:22:44 2012 us=491858 oleneva.imsp/192.168.2.221:1194 write UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Fri Feb  3 17:22:44 2012 us=494398 valeevirchat.imsp/192.168.2.170:1194 write UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Fri Feb  3 17:22:45 2012 us=151199 cicanbaev.imsp/192.168.2.109:1194 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Feb  3 17:22:45 2012 us=151273 cicanbaev.imsp/192.168.2.109:1194 TLS Error: TLS handshake failed
Fri Feb  3 17:22:45 2012 us=231150 user15.imsp/192.168.2.235:1194 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Feb  3 17:22:45 2012 us=231214 user15.imsp/192.168.2.235:1194 TLS Error: TLS handshake failed
Fri Feb  3 17:22:45 2012 us=377130 trifonov.imsp/192.168.2.196:1194 write UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Fri Feb  3 17:22:47 2012 us=3746 ytashev.imsp/192.168.2.113:1194 write UDPv4 [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH]: No route to host (code=113)
Fri Feb  3 17:22:47 2012 us=4340 gafarova.imsp/192.168.2.114:1194 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Feb  3 17:22:47 2012 us=4375 gafarova.imsp/192.168.2.114:1194 TLS Error: TLS handshake failed
Fri Feb  3 17:22:47 2012 us=79485 teregylov.imsp/192.168.2.124:1194 write UDPv4 [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH]: No route to host (code=113)
Fri Feb  3 17:22:47 2012 us=80365 hazgaliev.imsp/192.168.2.179:1194 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Feb  3 17:22:47 2012 us=80402 hazgaliev.imsp/192.168.2.179:1194 TLS Error: TLS handshake failed
Fri Feb  3 17:22:47 2012 us=81371 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Fri Feb  3 17:22:47 2012 us=241666 ganeeva.imsp/192.168.2.180:1194 write UDPv4 [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNR]: No route to host (code=113)
Fri Feb  3 17:22:47 2012 us=245290 zinovev.imsp/192.168.2.116:1194 write UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Fri Feb  3 17:22:50 2012 us=7527 ganeeva.imsp/192.168.2.180:1194 write UDPv4 [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH]: No route to host (code=113)
Fri Feb  3 17:22:50 2012 us=244203 galeev.imsp/192.168.2.106:1194 write UDPv4 [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNR]: No route to host (code=113)
Fri Feb  3 17:22:50 2012 us=248899 admin.imsp/192.168.2.66:1194 write UDPv4 [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNR]: No route to host (code=113)
Fri Feb  3 17:22:50 2012 us=253370 trifonov.imsp/192.168.2.196:1194 write UDPv4 [ECONNREFUSED]: Connection refused (code=111)
less /etc/openvpn/openvpn.conf

Код: [Выделить]

#local 192.168.2.254
port 1194
proto udp
#dev tun
dev tap
;dev-node tap0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/mailserver.imsp.crt
key /etc/openvpn/mailserver.imsp.key # This file should be kept secret
dh /etc/openvpn/dh1024.pem
server 10.10.10.0 255.255.255.0 # vpn subnet
ifconfig-pool-persist /etc/openvpn/ipp.txt
push "route-gateway 192.168.2.254 255.255.255.0" # work subnet
#push "route 0.0.0.0 255.255.255.0" # work subnet
#push "dhcp-option DNS 192.168.2.254"
#push "redirect-gateway def1" # старый маршрут останеться
push "redirect-gateway" # старый маршрут удалиться
;duplicate-cn
#keepalive 10 120
#;cipher BF-CBC # Blowfish (default)
#;cipher AES-128-CBC # AES
#;cipher DES-EDE3-CBC # Triple-DES
comp-lzo no
max-clients 220
user nobody
group nogroup
persist-key
persist-tun
log /var/log/openvpn.log #log-append log файл будет дополняться
status /var/log/openvpn-status.log #обновляеться каждую минуту о подкл пользователей
verb 4
mute 20
client-to-client
client-config-dir /etc/openvpn/ccd
Смотрел cron нет расписаний на это время, пользовался поисковиком находил полезные стати но они были иного характера и не помогли, да и пото конфиг то рабочий до 6ти ошибок нет

[user_anonymous]

Сервер находится в той же сети, что и клиентские машины? Не может ли после 18:00 нарушаться связанность?
Не может ли кто-либо уходя с работы выключать какую-либо важную железку (например коммутатор, через который все сидят, может быть подключен в пилот с чьим-то компьютером)?
Выбор /dev/tap был осознанным или просто так захотелось?

Утилита nc способна посылать udp пакеты куда скажут. При помощи tcpdump,  запущенного на сервере, множно узать, доходят ли до него пакеты в то время, как udp-пакеты от опенвпн не доходят.

[shtok]

Спасибо за ответ. Да сервер находится в той же подсети, локальная сеть работает хорошо, и если юзеров пускать напярмую через правила iptables то нет никаких проблем. И дело в том что это проходит глобально все работающие через впн испытывают переодические сбои с нетом ближе к 6ти. /dev/tap использовал намеренно, по фукционалу tun конечно лучше но у меня в сети гдето 100компов и при подключении через tun переодически возникали ошибки, пришлось сделать сетевой мост с маленьким 64 бродкастом
Прослушивание через tcpdump думаю нет смысла тестить. ведь локалка то работает.

Вот логи дневные ошибок нет

Код: [Выделить]

Tue Feb  7 09:31:48 2012 us=783175 nazarova.imsp/192.168.2.243:1194 MULTI: Learn: 00:ff:f0:1b:3e:fa -> nazarova.imsp/192.168.2.243:1194
Tue Feb  7 09:33:45 2012 us=979658 nagimov.imsp/192.168.2.187:1194 VERIFY OK: depth=1, /C=RU/ST=RU/L=Ufa/O=imsp/CN=mailserver.imsp/emailAddress=sagvir@imsp.ru
Tue Feb  7 09:33:45 2012 us=980075 nagimov.imsp/192.168.2.187:1194 VERIFY OK: depth=0, /C=RU/ST=RU/L=Ufa/O=imsp/CN=nagimov.imsp/emailAddress=sagvir@imsp.ru
Tue Feb  7 09:33:45 2012 us=988076 nagimov.imsp/192.168.2.187:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Feb  7 09:33:45 2012 us=988133 nagimov.imsp/192.168.2.187:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Feb  7 09:33:45 2012 us=988287 nagimov.imsp/192.168.2.187:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Feb  7 09:33:45 2012 us=988318 nagimov.imsp/192.168.2.187:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Feb  7 09:33:45 2012 us=989506 nagimov.imsp/192.168.2.187:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Feb  7 09:34:24 2012 us=36297 gynekov.imsp/192.168.2.125:1194 TLS: soft reset sec=0 bytes=3685763/0 pkts=14832/0
Tue Feb  7 09:34:24 2012 us=217423 gynekov.imsp/192.168.2.125:1194 VERIFY OK: depth=1, /C=RU/ST=RU/L=Ufa/O=imsp/CN=mailserver.imsp/emailAddress=sagvir@imsp.ru
Tue Feb  7 09:34:24 2012 us=217805 gynekov.imsp/192.168.2.125:1194 VERIFY OK: depth=0, /C=RU/ST=RU/L=Ufa/O=imsp/CN=gynekov.imsp/emailAddress=sagvir@imsp.ru
Tue Feb  7 09:34:24 2012 us=229771 gynekov.imsp/192.168.2.125:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Feb  7 09:34:24 2012 us=229838 gynekov.imsp/192.168.2.125:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Feb  7 09:34:24 2012 us=229991 gynekov.imsp/192.168.2.125:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Feb  7 09:34:24 2012 us=230022 gynekov.imsp/192.168.2.125:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Feb  7 09:34:24 2012 us=233677 gynekov.imsp/192.168.2.125:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Feb  7 09:34:34 2012 us=303374 ivaevval.imsp/192.168.2.171:1194 VERIFY OK: depth=1, /C=RU/ST=RU/L=Ufa/O=imsp/CN=mailserver.imsp/emailAddress=sagvir@imsp.ru
Tue Feb  7 09:34:34 2012 us=303514 ivaevval.imsp/192.168.2.171:1194 VERIFY OK: depth=0, /C=RU/ST=RU/L=Ufa/O=imsp/CN=ivaevval.imsp/emailAddress=sagvir@imsp.ru
Tue Feb  7 09:34:34 2012 us=311788 ivaevval.imsp/192.168.2.171:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Feb  7 09:34:34 2012 us=311810 ivaevval.imsp/192.168.2.171:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Feb  7 09:34:34 2012 us=311851 ivaevval.imsp/192.168.2.171:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Feb  7 09:34:34 2012 us=311873 ivaevval.imsp/192.168.2.171:1194 NOTE: --mute triggered...

[user_anonymous]

Прослушивание через tcpdump думаю нет смысла тестить. ведь локалка то работает.

Вот тут я с вами не соглашусь. Исследование сети - это как раз то, чем имеет смысл заняться, когда вываливаются такие косяки. "Локалка работает" - это такое очень растяжимое понятие, уж поверьте. Если ничего необычного не найдется - ну и слава богу. Значит с этой стороны засады можно будет исключить.

[shtok]

А не могли бы вы привести пример в таком случаем, тоесть на клиенте я запускаю netcat скажем nc 10.10.10.1 1194 а на сервере через tcpdump по маку машины клиента весь трафик прослушиваю?

[shtok]

Понимаю что возможности nc велеки, но я не работал еще с ней особой. На сервере запустил nc -l -p 1194, чтобы udp прослушать ставил место -l -u но 

Код: [Выделить]

   nc -u -p 1194
no destination
на клиенте nc 10.10.10.1 1194 он логи кудато записывает? потомучто ничего на экране не происходит

[user_anonymous]

Не писал, потому что совсем нет времени  Если еще актуально, то пример для nc:

В первой консоли запускаем
$ nc -u -l 25000
Это значит использовать UDP и слушать порт 25000 (взят от балды)

Во второй консоли запускаем
$ date | nc -u 127.0.0.1 25000

На первой консоли должна вылезти дата:
$ nc -u -l 25000
Втр Фев 21 17:14:01 YEKT 2012

[shtok]

Диагностика никогда не бывает лишней) так что спасибо за совет. На сервере запустил nc -u -l -p 1194
на клиенте date | nc -u 10.10.10.1 1194 , на сервере вышло сообщение

Код: [Выделить]

Can't grab 0.0.0.0:1194 with bind


[shtok]

Слушай у меня тут в syslog неразбериха пошла, вес вывод содержит лишь одно сообщение в разных вариациях

Код: [Выделить]

Feb 26 10:05:18 mailserver kernel: [2139831.056869] DROP INPUTIN=eth1 OUT= MAC=00:1b:21:80:81:9b:00:01:02:77:e6:ce:08:00 SRC=xxx.xxx.xxx.1 DST=xxx.xxx.xxx.88 LEN=163 TOS=0x00 PREC=0x00 TTL=63 ID=10069 PROTO=UDP SPT=53 DPT=46365 LEN=143
Feb 26 10:05:18 mailserver kernel: [2139831.097556] DROP INPUTIN=tap0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:ff:4b:a1:c0:51:08:00 SRC=10.10.10.50 DST=10.10.10.255 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=254 PROTO=UDP SPT=59055 DPT=1947 LEN=48
Feb 26 10:05:18 mailserver kernel: [2139831.279922] DROP INPUTIN=eth1 OUT= MAC=00:1b:21:80:81:9b:00:01:02:77:e6:ce:08:00 SRC=xxx.xxx.xxx.3 DST=xxx.xxx.xxx.88 LEN=84 TOS=0x00 PREC=0x60 TTL=55 ID=13677 PROTO=ICMP TYPE=0 CODE=0 ID=29527 SEQ=3132
Feb 26 10:05:19 mailserver kernel: [2139831.549018] DROP INPUTIN=eth1 OUT= MAC=00:1b:21:80:81:9b:00:01:02:77:e6:ce:08:00 SRC=xxx.xxx.xxx.1 DST=xxx.xxx.xxx.88 LEN=126 TOS=0x00 PREC=0x00 TTL=63 ID=10070 PROTO=UDP SPT=53 DPT=48097 LEN=106
(END)
  где eth1 - интерфейс смотрящий на ружу,  xxx.xxx.xxx.1 - провайдерский dns-nameservers, xxx.xxx.xxx.88 - eth1:0 ip где крутиться веб сервер
помоги разобраться, а то логи этим только и заняты,а другую системную инфу и не предоставляют

[MrStraker]

Слушай у меня тут в syslog неразбериха пошла, вес вывод содержит лишь одно сообщение в разных вариациях

Код: [Выделить]

Feb 26 10:05:18 mailserver kernel: [2139831.056869] DROP INPUTIN=eth1 OUT= MAC=00:1b:21:80:81:9b:00:01:02:77:e6:ce:08:00 SRC=xxx.xxx.xxx.1 DST=xxx.xxx.xxx.88 LEN=163 TOS=0x00 PREC=0x00 TTL=63 ID=10069 PROTO=UDP SPT=53 DPT=46365 LEN=143
Feb 26 10:05:18 mailserver kernel: [2139831.097556] DROP INPUTIN=tap0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:ff:4b:a1:c0:51:08:00 SRC=10.10.10.50 DST=10.10.10.255 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=254 PROTO=UDP SPT=59055 DPT=1947 LEN=48
Feb 26 10:05:18 mailserver kernel: [2139831.279922] DROP INPUTIN=eth1 OUT= MAC=00:1b:21:80:81:9b:00:01:02:77:e6:ce:08:00 SRC=xxx.xxx.xxx.3 DST=xxx.xxx.xxx.88 LEN=84 TOS=0x00 PREC=0x60 TTL=55 ID=13677 PROTO=ICMP TYPE=0 CODE=0 ID=29527 SEQ=3132
Feb 26 10:05:19 mailserver kernel: [2139831.549018] DROP INPUTIN=eth1 OUT= MAC=00:1b:21:80:81:9b:00:01:02:77:e6:ce:08:00 SRC=xxx.xxx.xxx.1 DST=xxx.xxx.xxx.88 LEN=126 TOS=0x00 PREC=0x00 TTL=63 ID=10070 PROTO=UDP SPT=53 DPT=48097 LEN=106
(END)
  где eth1 - интерфейс смотрящий на ружу,  xxx.xxx.xxx.1 - провайдерский dns-nameservers, xxx.xxx.xxx.88 - eth1:0 ip где крутиться веб сервер
помоги разобраться, а то логи этим только и заняты,а другую системную инфу и не предоставляют

У вас работает iptables как я понял.
Так первое это попытка ДНС сервера провайдера обратиться к твоему серверу по адресу х.х.х.88 на порты 53 - это днс порт. Такое может быть если где-то есть упоминание что твой сервер является днс сервером для какого-то домена. Либо есть анонсирование на днс сервер провайдера информации от клиентов сети. Попытка динамического обновления. Этим грешит виндовс (там галочка по умолчанию стоит).
Второе это походу кто-то CS запустил в режиме мультиплеера.
третье это проверка на живучесть твоего сервера по пингу (ICMP).
Для правильной настройки межсетевого экрана (iptables, firewall, брандмауэр) почитайте книгу "Брандмауэры в Linux". Найдете много интересного.
И еще замечу что 0 и 3 тип ICMP пакета лучше не блокировать. Меньше проблем.

[shtok]

У вас работает iptables как я понял.
Так первое это попытка ДНС сервера провайдера обратиться к твоему серверу по адресу х.х.х.88 на порты 53 - это днс порт. Такое может быть если где-то есть упоминание что твой сервер является днс сервером для какого-то домена. Либо есть анонсирование на днс сервер провайдера информации от клиентов сети. Попытка динамического обновления. Этим грешит виндовс (там галочка по умолчанию стоит).
Второе это походу кто-то CS запустил в режиме мультиплеера.
третье это проверка на живучесть твоего сервера по пингу (ICMP).
Для правильной настройки межсетевого экрана (iptables, firewall, брандмауэр) почитайте книгу "Брандмауэры в Linux". Найдете много интересного.
И еще замечу что 0 и 3 тип ICMP пакета лучше не блокировать. Меньше проблем.

Спасибо MrStraker за отличные пояснения. У меня был открыт #$IPT -A INPUT -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
#$IPT -A INPUT -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT . временно закрыл icmp пакеты логи не изменились

Код: [Выделить]

Mar  5 09:36:31 mailserver kernel: [2829303.792570] DROP INPUTIN=eth1 OUT= MAC=00:1b:21:80:81:9b:00:01:02:77:e6:ce:08:00 SRC=ххх.xxx.xxx..94 DST=ххх.xxx.xxx.82 LEN=84 TOS=0x00 PREC=0x00 TTL=255 ID=63474 PROTO=ICMP TYPE=0 CODE=0 ID=21798 SEQ=1290
Mar  5 09:36:31 mailserver kernel: [2829303.805607] DROP INPUTIN=eth1 OUT= MAC=00:1b:21:80:81:9b:00:01:02:77:e6:ce:08:00 SRC=77.120.128.138 DST=ххх.xxx.xxx..82 LEN=48 TOS=0x10 PREC=0x00 TTL=110 ID=11574 DF PROTO=TCP SPT=32241 DPT=59803 WINDOW=65535 RES=0x00 SYN URGP=0
Mar  5 09:36:31 mailserver kernel: [2829303.898804] DROP INPUTIN=tap0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:ff:a9:5d:57:d6:08:00 SRC=10.10.10.236 DST=10.10.10.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=12158 PROTO=UDP SPT=137 DPT=137 LEN=58
Mar  5 09:36:31 mailserver kernel: [2829303.905470] DROP INPUTIN=tap0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:ff:ef:2a:9e:d0:08:00 SRC=10.10.10.46 DST=10.10.10.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=31562 PROTO=UDP SPT=137 DPT=137 LEN=58
Mar  5 09:36:31 mailserver kernel: [2829304.008220] DROP INPUTIN=eth1 OUT= MAC=00:1b:21:80:81:9b:00:01:02:77:e6:ce:08:00 SRC=89.133.129.229 DST=212.193.134.82 LEN=131 TOS=0x00 PREC=0x00 TTL=116 ID=13395 PROTO=UDP SPT=41338 DPT=17726 LEN=111
Mar  5 09:36:31 mailserver kernel: [2829304.052209] DROP INPUTIN=eth1 OUT= MAC=00:1b:21:80:81:9b:00:01:02:77:e6:ce:08:00 SRC=87.250.250.203 DST=212.193.134.88 LEN=84 TOS=0x00 PREC=0x00 TTL=58 ID=21302 PROTO=ICMP TYPE=0 CODE=0 ID=21782 SEQ=1409
У меня лишь кеширующий ДНС сервер - рекурсивный  и он же являеться мастер -ДНС сервером для своей локальной сети. Так же крутится web-server с ip ххх.ххх.ххх.88 на нем сайт. но файлы зоны для этого домена и сам днс не на моем сервере
Кстати как в логе видно. не только ххх.xxx.xxх.88 айпи теребит где сайт висит но и ххх.xxx.xxx.82 внешний айпи для интернета. Просто раньше этого не было. лишь пару недель назад стало, после того как я icmp покеты открыл, но сейчас ведь закрыл все равно так. может правила iptables касячные. не могли бы взглянуть.
---"CS запустил в режиме мультиплеера." вы имеете в виду контру? Да есть сотрудники которые в контру играют, если это причина, то как это устранить? ведь логи всегда такие хоть и в контру не играют) Заранее спасибо.