LINUX.ORG.RU
ФорумAdmin

сервер VPN pptp ошибки в логах


0

1

настроил сервер VPN но почему то при определенных обстоятельствах в логах вываливаются ошибки вида: pptpd[11557]: GRE: read(fd=8,buffer=60ece0,len=8260) from network failed: status = -1 error = Protocol not available

pptpd[11557]: CTRL: GRE read or PTY write failed (gre,pty)=(8,6)

pptpd[11557]: CTRL: Reaping child PPP[11558]

и происходит отключение пользователей. конфиги:

/etc# cat pptpd.conf ############################################################################### # $Id$ # # Sample Poptop configuration file /etc/pptpd.conf # # Changes are effective when pptpd is restarted. ###############################################################################

#ppp /usr/sbin/pppd

option /etc/ppp/pptpd-options

# TAG: debug # Turns on (more) debugging to syslog # #debug

noipparam

#logwtmp

localip 192.168.254.1

remoteip 192.168.254.205-246

cat pptpd-options

#chapms-strip-domain

refuse-pap

refuse-chap

require-mschap # Require the peer to authenticate itself using MS-CHAPv2 [Microsoft # Challenge Handshake Authentication Protocol, Version 2] authentication.

require-mschap-v2

# Require MPPE 128-bit encryption # (note that MPPE requires the use of MSCHAP-V2 during authentication)

require-mppe-128

mppe-stateful

# }}}

ipcp-accept-local

ipcp-accept-remote

lcp-echo-failure 30

lcp-echo-interval 5

# Network and Routing

#ms-dns 10.0.0.1

#ms-dns 10.0.0.2

#ms-wins 10.0.0.3

#ms-wins 10.0.0.4

# Add an entry to this system's ARP [Address Resolution Protocol] # table with the IP address of the peer and the Ethernet address of this # system. This will have the effect of making the peer appear to other # systems to be on the local ethernet. # (you do not need this if your PPTP server is responsible for routing # packets to the clients — James Cameron)

#proxyarp

# Debian: do not replace the default route

nodefaultroute

# Logging

# Enable connection debugging facilities. # (see your syslog configuration for where pppd sends to)

#debug

lock

mtu 1000

mru 1200

# Disable BSD-Compress compression

nobsdcomp

в файрволе прописаны правила:

:INPUT DROP [0:0]

:OUTPUT ACCEPT [0:0]

-A INPUT -p 47 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 1723 -j ACCEPT

все выходные лазил по форумам уменьшал mtu загружал все модули ядра, но проблему так и не победил. у кого еще какие мысли есть?



Последнее исправление: Evgen25 (всего исправлений: 1)

Ответ на: комментарий от Evgen25

какого протокола не хватает для полного счастья ему? на каком то форуме вычитал, что надо открыть протоколы:

-A INPUT -p icmp -m icmp -f --icmp-type 3 -j ACCEPT

-A INPUT -p icmp -m icmp -f --icmp-type 4 -j ACCEPT

-A INPUT -p icmp -m icmp -f --icmp-type 8 -j ACCEPT

-A INPUT -p icmp -m icmp -f --icmp-type 11 -j ACCEPT

по пробовал. но пока не знаю помогло или нет

Evgen25
() автор топика
Ответ на: комментарий от Evgen25

еще вот такая ошибка вываливается :

GRE: read(fd=6,buffer=606c80,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs

pptpd[3372]: CTRL: PTY read or GRE write failed (pty,gre)=(6,8)

pptpd[3372]: CTRL: Reaping child PPP[3373]

Evgen25
() автор топика
Ответ на: комментарий от Evgen25

а в логе ядра вот такие записи иногда бывают:

kernel: [128710.512045] ppp0: ppp: compressor dropped pkt

kernel: [129309.869937] mppe_compress[0]: osize too small! (have: 1004 need: 1008)

Evgen25
() автор топика
Ответ на: комментарий от Evgen25

подгружаю вот такие модули

modprobe nf_nat_pptp

modprobe ip_gre

modprobe gre

modprobe nf_nat_pptp

modprobe nf_nat_proto_gre

modprobe nf_conntrack_pptp

modprobe nf_conntrack_proto_gre

modprobe ip_nat_pptp

уже весь яндекс перерыл. ответа на вопрос найти не могу

Evgen25
() автор топика
Ответ на: комментарий от Marchael

правила для VPN идут в первых рядах файрвола. сервер еще является шлюзом для двух сеток. так просто правила не очистить

Evgen25
() автор топика
Ответ на: комментарий от Marchael

у меня сжатие не включено. и как бы не хочется включать. лишняя нагрузка на процессор

Evgen25
() автор топика

послушай трафик tcpdump-ом, узнаешь много нового. В частности, такая ошибка(Protocol not available) может возникать из-за кривого файрволла на клиентах, который шлем ICMP Protocol unreachable серверу

Pinkbyte ★★★★★
()
Ответ на: комментарий от Evgen25

смущает такой вывод:

GREv1, call 2254, seq 12, length 24: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 12

GREv1, call 44160, seq 11, ack 12, length 28: unknown ctrl-proto (0x80fd), Conf-Nack (0x03), id 1, length 12

GREv1, call 2254, seq 13, ack 11, length 28: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 2, length 12

GREv1, call 44160, seq 12, ack 13, length 28: unknown ctrl-proto (0x80fd), Conf-Ack (0x02), id 2, length 12

GREv1, call 2254, seq 14, ack 12, length 34: IPCP, Conf-Request (0x01), id 1, length 18

GREv1, call 44032, seq 95, length 74: compressed PPP data

я даже не представляю чего я должен увидеть и чего быть не должно

Evgen25
() автор топика

Попробуй выключить шифрование — у меня в своё время тоже какая-то фигня из-за него творилась.

post-factum ★★★★★
()
Ответ на: комментарий от post-factum

в том то и дело что нужен шифрованный канал. иначе бы вообще VPN не поднимал бы. а ошибки именно на одном адресе. остальные клиенты нормально работают вроде как

Evgen25
() автор топика
Ответ на: комментарий от post-factum

учту на будущее. замучал просто этот сервак. с пятницы мучаюсь и все выходные груз гранит науки.

Evgen25
() автор топика
Ответ на: комментарий от Evgen25
15:30:45.003482 IP client > 78.109.114.83: GREv1, call 43776, seq 430, length 74: compressed PPP data
15:30:45.033102 IP client > server: GREv1, call 43776, seq 431, ack 439, length 73: compressed PPP data
15:30:45.033582 IP client > server: GREv1, call 43776, seq 432, ack 438, length 61: compressed PPP data
15:30:45.083714 IP server > client: GREv1, call 1441, ack 432, no-payload, length 12
15:30:45.164946 IP server > client: GREv1, call 1441, seq 440, length 57: compressed PPP data
15:30:45.297050 IP client.2670 > server.1723: Flags [S], seq 1221601302, win 65535, options [mss 1460,nop,nop,sackOK], length 0
15:30:45.297081 IP server.1723 > client.2670: Flags [S.], seq 3094661764, ack 1221601303, win 12600, options [mss 1260,nop,nop,sackOK], length 0
15:30:45.338335 IP client > server: GREv1, call 43776, ack 440, no-payload, length 12
15:30:45.377475 IP client.2670 > server.1723: Flags [P.], seq 1:157, ack 1, win 65535, length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(2600) HOSTNAME() VENDOR(Microsoft Windows NT)
15:30:45.377508 IP server.1723 > client.2670: Flags [.], ack 157, win 13400, length 0
15:30:45.378199 IP server.1723 > client.2670: Flags [P.], seq 1:157, ack 157, win 13400, length 156: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP() BEARER_CAP() MAX_CHAN(1) FIRM_REV(1) HOSTNAME(local) VENDOR(linux)
15:30:45.455491 IP client.2670 > server.1723: Flags [P.], seq 157:325, ack 157, win 65379, length 168: pptp CTRL_MSGTYPE=OCRQ CALL_ID(2670) CALL_SER_NUM(22613) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
15:30:45.455882 IP server.1723 > client.2670: Flags [P.], seq 157:189, ack 325, win 14472, length 32: pptp CTRL_MSGTYPE=OCRP CALL_ID(43904) PEER_CALL_ID(2670) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(64) PROC_DELAY(0) PHY_CHAN_ID(0)
15:30:45.457832 IP server > client: GREv1, call 2670, seq 0, length 45: LCP, Conf-Request (0x01), id 1, length 31
15:30:45.533096 IP client > server: ICMP client protocol 47 unreachable, length 73
15:30:45.533222 IP server.1723 > client.1441: Flags [F.], seq 1649050870, ack 4210299906, win 14472, length 0
15:30:45.533235 IP server.1723 > client.2670: Flags [F.], seq 189, ack 325, win 14472, length 0
15:30:45.538136 IP client.2670 > server.1723: Flags [P.], seq 325:349, ack 189, win 65347, length 24: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(43904) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
15:30:45.538160 IP server.1723 > client.2670: Flags [R], seq 3094661953, win 0, length 0
15:30:45.541052 IP client > server: GREv1, call 43904, seq 0, length 64: LCP, Conf-Request (0x01), id 0, length 50
15:30:45.556175 IP client > server: GREv1, call 43776, seq 433, length 69: compressed PPP data
15:30:45.612363 IP client > server: GREv1, call 43776, seq 434, length 69: compressed PPP data
15:30:45.612484 IP client.1441 > server.1723: Flags [F.], seq 1, ack 1, win 65347, length 0
15:30:45.612503 IP server.1723 > client.1441: Flags [.], ack 2, win 14472, length 0
15:30:45.612517 IP client.2670 > server.1723: Flags [F.], seq 349, ack 190, win 65347, length 0
15:30:45.612535 IP server.1723 > client.2670: Flags [R], seq 3094661954, win 0, length 0

кто подскажет где ошибка? может я что то где то не до глядел? может модуль какой упустил

Evgen25
() автор топика
Ответ на: комментарий от Evgen25

Если ошибки на одном адресе, его и изучайте, запускайте в фоне/в screen'е tcpdump на запись в файл:

tcpdump -i ИНТЕРФЕЙС -n -nn -s 0 -w /tmp/tcpdump.res host ПРОБЛЕММНЫЙ-IP-АДРЕС

Потом, когда произойдёт разрыв связи, или несколько разрывов, убиваете этот tcpdump и смотрите что там было:

tcpdump -n -nn -r /tmp/tcpdump.res | less -S

прокручиваете до времени ошибки и смотрите, были ли ICMP пакеты от клиента и т.д.

Относительно сервер VPN pptp ошибки в логах (комментарий) смотрите логи на предмет сообщений от pppd[3373], может там что интерестное.

Зачем вам модули NAT'а для pptp и gre? Вы не только терминируете pptp, но ещё и NAT для него делаете?

mky ★★★★★
()
Ответ на: комментарий от mky

нат нужен. vpn сервер еще является и шлюзом. смущает строчка: 15:30:45.533096 IP client > server: ICMP client protocol 47 unreachable, length 73

Evgen25
() автор топика
Ответ на: комментарий от Evgen25

Да, это то, про что писал Pinkbyte, погуглите про «ICMP protocol 47 unreachable», в одном месте советовали просто рубить подобные пакеты, говорят, помогает, не знаю, не проверял:

iptables -I INPUT -s <remoteip> -p icmp --icmp-type 3 -j DROP

Мне больше не понятно, почему там с server.1723 два соединения (client.1441 и client.2670). Выглядит это так, как будто клиент, имея одно соединение пытается установить второе.

mky ★★★★★
()
Ответ на: комментарий от Evgen25

смотрел я. говорят что достаточно сделать: modprobe ip_nat_pptp modprobe ip_conntrack_pptp. сделал. но не помогло. может в ядре 3.2.0 как то по другому модуль называется?

Evgen25
() автор топика
Ответ на: комментарий от Evgen25

есть модули ip_nat_pptp и ip_conntrack_pptp а есть nf_nat_pptp и nf_conntrack_pptp в чем разница, может они взаимоисключающие?

Evgen25
() автор топика
Ответ на: комментарий от Evgen25

Вы пробовали делать то правило, что я написал "--icmp-type 3 -j DROP"? С какими сообщениями в этом случае рвётся соединение?

ip_nat_pptp нужен на сервере, если он делает NAT pptp соединений, как тот маршрутник, за которым 4 компьютера.

ip_conntrack_pptp нужен на сервере, чтобы в iptables трафик проходил по state RELATED,ESTABLISHED. Если явно открыт tcp 1723 порт и ip протокол 47 (gre), то ip_conntrack_pptp не нужен.

mky ★★★★★
()
Ответ на: комментарий от Evgen25

вообщем. пока разрывов соединений не было. сижу жду чего нибудь. оно было и через пол часа рвалось

Evgen25
() автор топика
Ответ на: комментарий от Evgen25

До 2.6.22 (ЕМПИП) модули назывались ip_, потом стали называться nf_. В некоторых дистрибутивах название ip_ сделали алиасом для nf_.

mky ★★★★★
()
Ответ на: комментарий от mky

мне помогло зарубить подобные пакеты. По крайней мере жалоб со стороны пользователей на разрывы стало гораздо меньше

Pinkbyte ★★★★★
()
Ответ на: комментарий от Evgen25

С чем именно связанно возникновение этих ICMP пакетов врятли вам кто-нибудь объяснит. Может на клинетах кривой софт, может на маршрутнике. Но, когда ваш pptp-сервер получает подобный пакет, то у него возникает ошибка чтения/записи и он разрывает соединение.

В целом, для работы pptp эти пакеты не нужны, с одной стороны ppp отслеживает состояние соединения, с другой стороны, для управления gre-тунелем используется tcp-соединение (1723). Поэтому, в игнорировании этих пакетов (через запись в iptables) ничего особо страшного нет.

mky ★★★★★
()
Ответ на: комментарий от mky

спасибо, стало намного лучше но, ошибки всё же есть. что еще можно сделать для их уменьшения?

Evgen25
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.