VPN Server (pptpd) (Проблема..)

[neru_dead]

Стоит работает, но иногда бывает, что к нему нельзя подключиться, а через минуту,другую пускает. ( В винде пишет "ошибка 800" )
С чем это может быть связанно ? ( не каких закономерностей не вывел, когда заходит тогда и перестает работать... )

[TuLiss]

Стоит работает, но иногда бывает, что к нему нельзя подключиться, а через минуту,другую пускает. ( В винде пишет "ошибка 800" )
С чем это может быть связанно ? ( не каких закономерностей не вывел, когда заходит тогда и перестает работать... )

Ну ту т надо логи посмотреть. Как вариант может происходить залепание сесии.

[neru_dead]

Там в логах нечего не разобрать, одни GRE пакеты

Код: Выделить всё

Nov  8 06:45:37 billing pptpd[3947]: GRE: accepting packet #593740
Nov  8 06:45:37 billing pptpd[17256]: GRE: accepting packet #279

[sash-kan]

насколько помнится из опыта работы в техподдержке провайдера, «ошибкой 800» дос-овцы называют отсутствие связи с сервером. это когда на посланные syn-пакеты ни ответа, ни привета.
если и на icmp-запросы в этот момент сервер не отвечает, то, понятное дело, в первую очередь надо ковырять физическое соединение.
если icmp-replay-и приходят, стоит проверить в этот момент доступность сервера на других портах (ну, какие у Вас там демоны крутятся — 22, 25, 80, 110?).
если окажется, что не только 1723-й, но и другие порты «ни здрасте, ни до свидания», наличествует какая-то глобальная проблема.

[neru_dead]

насколько помнится из опыта работы в техподдержке провайдера, «ошибкой 800» дос-овцы называют отсутствие связи с сервером. это когда на посланные syn-пакеты ни ответа, ни привета.
если и на icmp-запросы в этот момент сервер не отвечает, то, понятное дело, в первую очередь надо ковырять физическое соединение.
если icmp-replay-и приходят, стоит проверить в этот момент доступность сервера на других портах (ну, какие у Вас там демоны крутятся — 22, 25, 80, 110?).
если окажется, что не только 1723-й, но и другие порты «ни здрасте, ни до свидания», наличествует какая-то глобальная проблема.

Сам сервак в тот момент отвечает ( 80, 443, 22 ... порт ).
Я не могу поймать тот момент когда он не отвечает, мне уже потом пользователи говорят, что мы не могли подключиться... ( хотя в этот момент я на нем работал это если сравнивать дату сообщения отправленного мне "о невозможности подключиться" и моей работы там )

[sash-kan]

запустите что-нибудь вроде
$ sudo tcpdump -pni <нужный интерфейс> host <ip-адрес проблемного клиента> and port 1723 > log.file
и попросите клиента точно фиксировать время, в которое он получил «ошибку 800».

[TuLiss]

насколько помнится из опыта работы в техподдержке провайдера, «ошибкой 800» дос-овцы называют отсутствие \
Я не могу поймать тот момент когда он не отвечает, мне уже потом пользователи говорят, что мы не могли подключиться... ( хотя в этот момент я на нем работал это если сравнивать дату сообщения отправленного мне "о невозможности подключиться" и моей работы там )

Сделайте простой тест.
При работе , отключите кабель =) (не отключая соединения) Потом подключите снова, и попробуйте соединится.

[neru_dead]

Вот что еще обнаружил в логах:

Код: Выделить всё

Nov  9 21:46:53 billing kernel: possible SYN flooding on port 1723. Sending cookies.
Nov  9 22:08:21 billing kernel: possible SYN flooding on port 1723. Sending cookies.
Nov  9 22:38:09 billing kernel: possible SYN flooding on port 1723. Sending cookies.
Nov  9 22:39:12 billing kernel: possible SYN flooding on port 1723. Sending cookies.
Nov  9 22:40:35 billing kernel: possible SYN flooding on port 1723. Sending cookies.

Может из-за этого ?

Код: Выделить всё

cat /etc/sysctl.conf

net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.rp_filter=1
net.ipv4.tcp_syncookies=1
net.ipv4.conf.all.forwarding=1
net.ipv4.conf.all.accept_source_route=0

[sash-kan]

Может из-за этого ?

очень даже может. на упомянутом предыдущем месте работы именно syn-flood-ы были причиной периодической «ошибки 800».
отфильтровать syn-пакеты для выявления сбоящего оборудования (в моем случае именно железяки сбоили) можно примерно так:
$ sudo tshark -pni <интерфейс> -R "tcp.flags == 0x02"

[neru_dead]

Может из-за этого ?

очень даже может. на упомянутом предыдущем месте работы именно syn-flood-ы были причиной периодической «ошибки 800».
отфильтровать syn-пакеты для выявления сбоящего оборудования (в моем случае именно железяки сбоили) можно примерно так:
$ sudo tshark -pni <интерфейс> -R "tcp.flags == 0x02"

А как понять что идет сбой ?

Код:

15.320307 192.168.250.58 -> 87.250.251.11 TCP 2509 > 80 [SYN] Seq=0 Len=0 MSS=1360 15.590816 192.168.250.18 -> 194.67.23.109 TCP 1644 > 80 [SYN] Seq=0 Len=0 MSS=1360 15.818894 192.168.250.67 -> 84.53.134.48 TCP 2635 > 80 [SYN] Seq=0 Len=0 MSS=1360 16.091000 192.168.26.46 -> 192.168.0.6 TCP 2050 > 1723 [SYN] Seq=0 Len=0 MSS=1460 TSV=22907555 TSER=0 WS=3 16.740142 192.168.250.248 -> 65.54.81.27 TCP 21574 > 80 [SYN] Seq=0 Len=0 MSS=1360

[sash-kan]

А как понять что идет сбой?

когда десятки/сотни/тысячи syn-пакетов ломятся с одного ip-адреса на ip-адрес сервера. допустим, на один и тот же порт. а может быть и с нескольких ip-адресов. и такое в практике бывало. две железяки начинали глючить. причем, обычно именно в субботу с утра (:
спасением было только drop-анье всех пакетов с этих адресов.
кстати, в Вашем случае пофильтровать-то не помешает посильнее:
$ sudo tshark -pni <интерфейс> -R "tcp.flags == 0x02 && ip.dst == <ip-адрес сервера на этом интерфейсе>"

[neru_dead]

Спасибо
Буду наблюдать...

[neru_dead]

все у меня в логах:

Код: Выделить всё

possible SYN flooding on port 1723. Sending cookies.
possible SYN flooding on port 1723. Sending cookies.
possible SYN flooding on port 1723. Sending cookies.
possible SYN flooding on port 1723. Sending cookies.
possible SYN flooding on port 1723. Sending cookies.

И не могу достать этот момент, что б узнать точно кто флудит...

Это получается работает функция "net.ipv4.tcp_syncookies=1" ?
И при флуде она блокирует полностью порт ? а не адреса с которого идет флуд ?

[sash-kan]

все у меня в логах

а как же файлик с выводом tshark-а?
чтобы в нем проще было ориентироваться, можно метки времени вставлять:
while true;do time >> <файл>;sleep 60;done

http://en.wikipedia.org/wiki/SYN_cookies
страничка Бернштейна оказалась недоступной. вот ссылка из кэша google:
http://64.233.183.104/search?q=cache:KRsDU...t=clnk&cd=1

[neru_dead]

Будем искать...