Pppd-440
👉🏻👉🏻👉🏻 ALL INFORMATION CLICK HERE 👈🏻👈🏻👈🏻
настроил сервер 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. ###############################################################################
# TAG: debug # Turns on (more) debugging to syslog # #debug
require-mschap # Require the peer to authenticate itself using MS-CHAPv2 [Microsoft # Challenge Handshake Authentication Protocol, Version 2] authentication.
# Require MPPE 128-bit encryption # (note that MPPE requires the use of MSCHAP-V2 during authentication)
# 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)
# Debian: do not replace the default route
# Enable connection debugging facilities. # (see your syslog configuration for where pppd sends to)
-A INPUT -p tcp -m tcp --dport 1723 -j ACCEPT
все выходные лазил по форумам уменьшал mtu загружал все модули ядра, но проблему так и не победил. у кого еще какие мысли есть?
версия ядра uname -a Linux 3.2.0-2-amd64 Debian GNU/Linux
Ответ на: комментарий от Evgen25 02.07.12 09:15:52
какого протокола не хватает для полного счастья ему? на каком то форуме вычитал, что надо открыть протоколы:
-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 02.07.12 09:31:54
еще вот такая ошибка вываливается :
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 02.07.12 09:44:53
а в логе ядра вот такие записи иногда бывают:
kernel: [128710.512045] ppp0: ppp: compressor dropped pkt
kernel: [129309.869937] mppe_compress[0]: osize too small! (have: 1004 need: 1008)
Ответ на: комментарий от Evgen25 02.07.12 09:47:27
уже весь яндекс перерыл. ответа на вопрос найти не могу
Ответ на: комментарий от Evgen25 02.07.12 10:31:22
Ты сначала пробовал правила для iptables очистить?
Ответ на: комментарий от Marchael 02.07.12 10:35:36
правила для VPN идут в первых рядах файрвола. сервер еще является шлюзом для двух сеток. так просто правила не очистить
Ответ на: комментарий от Evgen25 02.07.12 10:40:23
kernel: [128710.512045] ppp0: ppp: compressor dropped pkt
Попробуй поиграться с настройками сжатия
Ответ на: комментарий от Marchael 02.07.12 11:21:39
у меня сжатие не включено. и как бы не хочется включать. лишняя нагрузка на процессор
послушай трафик tcpdump-ом, узнаешь много нового. В частности, такая ошибка(Protocol not available) может возникать из-за кривого файрволла на клиентах, который шлем ICMP Protocol unreachable серверу
Ответ на: комментарий от Pinkbyte 02.07.12 13:13:54
запустил tcpdump host х.х.х.х -i eth1 -n -l | tee out.log по выводу мало чего понял
Ответ на: комментарий от Evgen25 02.07.12 13:35:01
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
я даже не представляю чего я должен увидеть и чего быть не должно
Попробуй выключить шифрование — у меня в своё время тоже какая-то фигня из-за него творилась.
post-factum ★★★★★ (02.07.12 13:38:47)
Ответ на: комментарий от post-factum 02.07.12 13:38:47
в том то и дело что нужен шифрованный канал. иначе бы вообще VPN не поднимал бы. а ошибки именно на одном адресе. остальные клиенты нормально работают вроде как
Все конфиги и логи обрамляй в тег [code], пожалуйста.
post-factum ★★★★★ (02.07.12 13:48:58)
Ответ на: комментарий от post-factum 02.07.12 13:48:58
учту на будущее. замучал просто этот сервак. с пятницы мучаюсь и все выходные груз гранит науки.
Ответ на: комментарий от Evgen25 02.07.12 13:54:37
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 02.07.12 13:41:21
Если ошибки на одном адресе, его и изучайте, запускайте в фоне/в 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 02.07.12 13:59:09
нат нужен. vpn сервер еще является и шлюзом. смущает строчка: 15:30:45.533096 IP client > server: ICMP client protocol 47 unreachable, length 73
Ответ на: комментарий от Evgen25 02.07.12 14:02:06
Да, это то, про что писал Pinkbyte, погуглите про «ICMP protocol 47 unreachable», в одном месте советовали просто рубить подобные пакеты, говорят, помогает, не знаю, не проверял:
iptables -I INPUT -s -p icmp --icmp-type 3 -j DROP
Мне больше не понятно, почему там с server.1723 два соединения (client.1441 и client.2670). Выглядит это так, как будто клиент, имея одно соединение пытается установить второе.
Ответ на: комментарий от mky 02.07.12 14:38:33
там маршрутизатор стоит. за маршрутником 4 компа. и все они должны иметь доступ к впн серверу.
Ответ на: комментарий от Evgen25 02.07.12 14:40:03
смотрел я. говорят что достаточно сделать: modprobe ip_nat_pptp modprobe ip_conntrack_pptp. сделал. но не помогло. может в ядре 3.2.0 как то по другому модуль называется?
Ответ на: комментарий от Evgen25 02.07.12 14:42:49
заказчик врет и мечет, я в панике. ничего не помогает
Ответ на: комментарий от Evgen25 02.07.12 14:43:30
есть модули ip_nat_pptp и ip_conntrack_pptp а есть nf_nat_pptp и nf_conntrack_pptp в чем разница, может они взаимоисключающие?
Ответ на: комментарий от Evgen25 02.07.12 14:43:30
Вы пробовали делать то правило, что я написал "--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 02.07.12 15:05:38
--icmp-type 3 -j DROP написал такое правило. пока ничего плохого не произошло. оно как то хаотично рвется
Ответ на: комментарий от Evgen25 02.07.12 15:09:02
вообщем. пока разрывов соединений не было. сижу жду чего нибудь. оно было и через пол часа рвалось
Ответ на: комментарий от Evgen25 02.07.12 15:00:31
До 2.6.22 (ЕМПИП) модули назывались ip_, потом стали называться nf_. В некоторых дистрибутивах название ip_ сделали алиасом для nf_.
Ответ на: комментарий от mky 02.07.12 14:38:33
мне помогло зарубить подобные пакеты. По крайней мере жалоб со стороны пользователей на разрывы стало гораздо меньше
Ответ на: комментарий от Pinkbyte 02.07.12 15:21:02
а с чем это связано, объясните пожалуйста
Ответ на: комментарий от Evgen25 02.07.12 15:22:39
С чем именно связанно возникновение этих ICMP пакетов врятли вам кто-нибудь объяснит. Может на клинетах кривой софт, может на маршрутнике. Но, когда ваш pptp-сервер получает подобный пакет, то у него возникает ошибка чтения/записи и он разрывает соединение.
В целом, для работы pptp эти пакеты не нужны, с одной стороны ppp отслеживает состояние соединения, с другой стороны, для управления gre-тунелем используется tcp-соединение (1723). Поэтому, в игнорировании этих пакетов (через запись в iptables) ничего особо страшного нет.
Ответ на: комментарий от mky 03.07.12 11:28:21
спасибо, стало намного лучше но, ошибки всё же есть. что еще можно сделать для их уменьшения?
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
52 results found Order by:RelevanceAgeSizeFiles
第一會所新片@SIS001@(OPPAI)(PPPD-440)隣の濡れ乳お姉さんに犯される2_佐山愛
(OPPAI)(PPPD-440)隣の濡れ乳お姉さんに犯される2 佐山愛.avi
(OPPAI)(PPPD-440)隣の濡れ乳お姉さんに犯される2 佐山愛.jpg
第一會所新片@SIS001@(OPPAI)(PPPD-440)隣の濡れ乳お姉さんに犯される2_佐山愛
(OPPAI)(PPPD-440)隣の濡れ乳お姉さんに犯される2 佐山愛.jpg
(OPPAI)(PPPD-440)隣の濡れ乳お姉さんに犯される2 佐山愛.mp4
Watch JAV Stream Online - JAVChan.com.url
PPPD-440.佐山愛.隣の濡れ乳お姉さんに犯される2 佐山愛.mp4
PPPD-440 2 Sayama Love To Be Fucked To Wet Milk Sister Next Door
PPPD-440 2 Sayama Love To Be Fucked To Wet Milk Sister Next Door.avi
简体中文
English
Français
Português do Brasil
Русский
сервер VPN pptp ошибки в логах — Admin — Форум
pppd -440 torrent
P6KE440 A, Защитный диод, 600Вт, 440В, [DO-15] | купить в розницу и оптом
Lewitt LCT 440 Pure - DJSHOP. Купить в Минске. Студийные микрофоны.
HYVST SPT 440 окрасочный аппарат безвоздушный (HYVST SPT 440)
Impossibly Obscene 3
Midget Anal Fisting
Hot Latino Hunk
Pppd-440
