pptpd random eldobálja a pptpd server felé érkező kapcsolatokat!

Linux-kezdő

Sziasztok!

Márciusban tettem egy pptpd-t a serverre , mert a főnök kérése az volt , hogy egyszerűen , windows platformon , egyeb program telepitese nelkul , a windows beepitett pptp kapcsolat kezelojevel el tudja erni otthonrol , a ceges samba megosztasokat!

Ez a pptpd tökéletesen működött a mai napig , amikor megadta magát.

Az, hogy megadta magát , annyit jelent, hogy:

Amikor a kliens csatlakozni akar, akkor a hostot felismeri , viszont a felhasznalonev es jelszo ellenorzesenel megall , es eldobja a kapcsolatot Hiba: 619 hibaüzenettel!

A serveren a syslogban , a kapcsolódáskor az alábbi sorok jelennek meg:

Jul 31 14:11:41 fortunato pptpd[9361]: CTRL: Client 109.105.23.56 control connection started
Jul 31 14:11:41 fortunato pptpd[9361]: CTRL: Starting call (launching pppd, opening GRE)
Jul 31 14:11:41 fortunato pppd[9362]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
Jul 31 14:11:41 fortunato pppd[9362]: pppd 2.4.5 started by root, uid 0
Jul 31 14:11:41 fortunato pppd[9362]: Using interface ppp1
Jul 31 14:11:41 fortunato pppd[9362]: Connect: ppp1 <--> /dev/pts/0
Jul 31 14:11:41 fortunato pptpd[9361]: GRE: Bad checksum from pppd.
Jul 31 14:12:11 fortunato pppd[9362]: LCP: timeout sending Config-Requests
Jul 31 14:12:11 fortunato pppd[9362]: Connection terminated.
Jul 31 14:12:11 fortunato pppd[9362]: Modem hangup
Jul 31 14:12:11 fortunato pppd[9362]: Exit.
Jul 31 14:12:11 fortunato pptpd[9361]: GRE: read(fd=6,buffer=611640,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Jul 31 14:12:11 fortunato pptpd[9361]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
Jul 31 14:12:11 fortunato pptpd[9361]: CTRL: Reaping child PPP[9362]
Jul 31 14:12:11 fortunato pptpd[9361]: CTRL: Client 109.105.23.56 control connection finished

A pptpd telepiteset kovetoen semmi módosítás nem volt a serveren ,ezért nem tudom , mi lehet a gondja!

Fórumokon mondtak , hogy Tűzfal gond lehet , de azt sem piszkáltam , mivel működött , amikor a pptpd telepitesekeor kinyitottam a 47 , 1723-as portot , így sajnos más nem jut eszembe!

Ha valakinek van valami ötlete , akkor írja le legyen szíves , bármilyen ötletet elfogadok!

Köszönöm előre is a segítséget!

  • 12824 megtekintés

( arpi_esp v | 2013. 07. 31., sze – 14:21 )

emlekeim szerint nem portot kell nyitni neki hanem a gre prtokollt(!=port) beengedni

meg aztan a pptp nat traversal tema is ottvan, foleg amikor 1 ip mogott tobb pptp user is van...

A'rpi

na igen , de akkor eddig hogyan működött?csak a 1723 illetve a 47es portot nyitottam ki és minden jó volt , 4 user bőven tudott akár egyszerre is dolgozni , de most meg egy sem tud csatlakozni.

Ezt a pptp nat taversal dolgot ki tudnad fejteni bovebben, legy szives , lehet nem egy dologra gondolunk.

probléma megoldva:

megoldás: a /etc/ppp/chap-secrets file-t a főnök nem UTF8 kódolíással piszkálta , amikor átirta a jelszavát , így az teleszemetelte szóközökkel, illetve egyéb , a karakterkódolásból származó hibás formázásokkal a filet!

Én UTF-8 kodolasban ujradefinialtam a chap-secrets file-t és most működik!

Köszönöm a segítséget mindenkinek!

RE:

mégsincs megoldva a probléma:S

ma megint elszállt a pptp kapcsolat , amikor server1 hálózatáról server 2 hálózatára akarok kapcsolódni:S ugyanez a helyzet visszafele is:S

A lényeg , hogy adott 2 server , amikre otthonról gond nélkül tudok mindig kapcsolódni!

De ha munkahelyen vagyok , akkor az egyik server hálózatáról nem tudok a másik server hálózatára kapcsolódni vpn-en , mert a felhasználónév jelszó ellenőrzésénél eldobja a kapcsolatot:S

Esetleg pptpd helyett tudnátok még olyan csomagot mondani, amit egyszerű ppptp kapcsolatot biztosít.

OpenVPN nem jöhet szóba , mert a főnök nem szereti a bonyolult dolgokat:S

Syslogban ez van:

CTRL: Client 109.105.29.203 control connection started
CTRL: Starting call (launching pppd, opening GRE)
Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
pppd 2.4.5 started by root, uid 0
Using interface ppp1
Connect: ppp1 <--> /dev/pts/1
GRE: Bad checksum from pppd.
GRE: read(fd=8,buffer=6095a0,len=8260) from network failed: status = -1 error = Protocol not available
CTRL: GRE read or PTY write failed (gre,pty)=(8,7)
CTRL: Reaping child PPP[2462]
Modem hangup
Connection terminated.
Exit.
CTRL: Client 109.105.29.203 control connection finished

Tudnátok adni valami támpontot , amin elindulhatnék?

Köszi előre is!

Milyen routered, tűzfalad van? Natolsz? Be van állítva, be van töltve a connection tracking és NAT helper?

"ugyanez a helyzet visszafele is"
Visszafelé?! Van beállítva bármilyen szabály GRE-re vagy TCP/1723-ra vonatkozólag? Pontosan mi és hova?

"4 user bőven tudott akár egyszerre is dolgozni"
Amúgy ha a munkahelyi hálózatból több kliens is csatlakozik egyidejűleg ugyanahhoz a szerverhez, miért nem a routerről indítod a PPTP tunnelt, miért a mögötte lévő gépekről?

Mit látsz a logban, ha bekapcsolod a debugot? És a tűzfaladon, szerveren dump közben?

szerver oldalon
require-mschap-v2
require-mppe-128
megvan?

kliens oldalon kotelezo titkositas mschap-v2 bepipalva?

Milyen Win kliens akap pptpn kapcsolodni?

Szemmel lathaton gre hiba van. Ha minden kulso klienst igy dobal el a pptpd, akkor kernel + conntrack es mppe+ppp csomagok szemebe kell nezni, megis volt-e valtozas. Ha csak bizonyos klienseket dobal el, akkor azokon a kliensek halozatbeallitasa es alhalozati atjaroja kornyeken kell nezelodni. Ha Win a kliens, nyugodtan lehet uj pptp kapcsolatot letrehozni.

Tovabba: gre hiba eseten legalabb teszt erejeig erdemes kikapcsolni a kotelezo titkositas kerest pptpd-n es beallitani a "nem kotelezo titkositas (kapcsolodas titkositas nelkul is) opciot, illetve Win XP|Vista|7|8 kliens eseten a virtualis maganhalozat tipusa legyen Automatikus helyett hatarozott PPTP.

A windows 7 /xp beepitett kliensevel csatlakozom.

A kapcsolat tipusa mar kezdettol hatarozott pptp volt.

A titkositas nem kotelezore van allitva.

ms-chap-v2 a kapcsolódás , és a server csak ezt fogadja el.

mppe-128 bites titkosítás is be van kapcsolva a pptpd server configban.

Új pptp kapcsolatot már hoztam létre , de nem segített , és a főnöknek még sem mondhatom azt , hogy mindig építsen új kapcsolatot , amikor még arra is alig van ideje , hogy beírja a jelszavát a pptp kliensbe :)

Amikor itthonról csatlakozom , akkor gond nélkül működik, viszont amikor a munkahelyen akarok csaltakozni server1 halozatarol, server2 halozatara, akkor hol működik, hol nem , de 90%-ban nem!

Ha server1-ről server2-re akarok csatlakozni , akkor a server2 logjában ez van:

http://pastebin.com/ZnmXzf1r

"Amikor itthonról csatlakozom , akkor gond nélkül működik, viszont amikor a munkahelyen akarok csaltakozni server1 halozatarol, server2 halozatara, akkor hol működik, hol nem , de 90%-ban nem!"
Éppen ezért esélyes, hogy a munkahelyi hálózatnál van valami. Erre vonatkoztak a fenti kérdéseim, de elismétlem. Milyen tűzfal, router, ALG, tűzfalszabályok? A tűzfal logjában mit látsz? Miért nem egyetlen tunnelt építesz a routerről az elérendő szerverig?

  

"Aug  2 11:19:31 NAGYERDO pppd[20414]: mru 1890          # (from /etc/ppp/pptpd-options)"
"Aug  2 11:19:31 NAGYERDO pppd[20414]: mtu 1890          # (from /etc/ppp/pptpd-options)"

Nem ez a probléma oka, de biztos kell neked ez az 1890 byte MTU/MRU?

Ez egyébként a múltkori PPTP-s hálózat? Annak mi lett a megoldása?

Ha jol ertem, akkor server2 es alhalozatat vizsgaljuk.

Akkor hajra! server2 atjaro vagy router mogott van? Ha router mogott, akkor annak mi a tipusa? server2 -n aktiv az iptables? server2 milyen distro? server2-n mi a ppp es a pptpd verzioja? mi lsmod | grep ppp kimenete?

server2 -n, ha nem aktiv require-mschap-v2 es require-mppe-128 direktiva, akkor Win kliens nem kotelezo titkositasi opcioju kapcsolodaskor nemtitkositott modon fog csatlakozni. Kovetkezeskeppen nem lehet gre hiba sem. Probald ki ezt is, nemcsak a kotelezo titkositast kliens kapcsolodaskor (persze, hogy nemkotelezo titkositas is MPPE es MSCHAP-V2 kapcsolatot eredmenyez, ha pptpd require- direktivaiban megkoveteli).

Bar tobbszor irtad, hogy par perc utan szakad meg a pptp kapcsolat, a kapott naploreszletekbol ez nem latszik. Csak az, hogy kb 30-40 mpen belul nem jon letre.

Es a beszedes GRE read or PTY write failed (gre,pty)=(8,7) uzenettel esik szet. Aminek oka lehet, hogy GRE protokollban (ebbe burkolva jonne letre a atunnel)nem jut egyezsegre a ppp+pptpd a kapcsolodo klienssel. Ennek oka lehet, hogy atjaron/routeren nem jut at NAT-T, ALG, contrack egyeztetesben a GRE, vagy mert server2-d pppje nem ismeri az mppe-t.

( dj | 2013. 08. 04., v – 10:33 )

Ha van a cégnél egy windows 7, akkor abból is lehet vpn (pptp) kiszolgálót csinálni.

Jo en mindig kicsit elore tervezek, ha a management megneszeli, hogy van ilyen, ok is akarnak majd ilyet. Es jobb elore felkeszulni 4-5 useres kornyezetre, mint utolag a fonokot megkerni, hogy lesz szives akkor masik gepet hasznalni kapcsolodashoz.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Fent ezt írta: "4 user bőven tudott akár egyszerre is dolgozni , de most meg egy sem tud csatlakozni." Tehát a jelenlegi használati mód mellett több tunnel is kellene neki. Persze ha a kedves kérdező válaszolna a már kétszer is feltett kérdésre, hogy miért nem a routerből indít egyetlen tunnelt, és miért minden kliens egymástól függetlenül egyesével, többet tudnánk a részletekről.

És bár elvileg megoldódott, de elég furcsa ez az autentikációs beállítással összefüggő ügy. Már ha valóban összefügg, és nem véletlen egybeeesésről van szó.

Mert talan a routeruk nem olyan okos, vagy van olyan okos, de annyira mar nincs okos, hogy le is tudja korlatozni, hogy a tunnelt bizonyos cimekrol hasznalhassak csak.

Egyebkent a topicnyito igy indit:

kérése az volt , hogy egyszerűen , windows platformon , egyeb program telepitese nelkul , a windows beepitett pptp kapcsolat kezelojevel el tudja erni otthonrol , a ceges samba megosztasokat

Vagyis kintrol befele jott a PPTP kapcsolat, nem bentrol kifele. Nincs egy darab kozponti router, amirol lehetne inditani a kapcsolatokat, mindenki ul otthon a foteljaban, es nyomkodja a connect gombot.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Meglátásom szerint rosszul értelmezed, persze lehet az is, hogy én.

Van valahol egy hálózatuk Windows szerverekkel (például hosting, vagy másik telephely stb.). Van gedg87 otthoni hálózata. Van a főnök. És van gedge87-ék munkahelyi hálózata, ahol természetesen többen is ülnek.
Erre a topológiára ez a két mondat világít rá: "ma megint elszállt a pptp kapcsolat , amikor server1 hálózatáról server 2 hálózatára akarok kapcsolódni", illetve "De ha munkahelyen vagyok , akkor az egyik server hálózatáról nem tudok a másik server hálózatára kapcsolódni vpn-en".

A normális állapot az lenne, és a kérdező elmondása szerint működött is, hogy bárhonnan, akár a munkahelyi hálózatról többen egyidőben, akár otthonról, akár máshonnan be tudott jelentkezni a szervereire.

A kérdező problémája most az volt, hogy otthonról, illetve mindenhonnan máshonnan megy, de a munkahelyi hálózatról ("server1 hálózata") már nem tudott senki sem PPTP kapcsolatot létesíteni a szerverek ("server 2 hálózata") felé, és ráadásul a főnök ideges.

"Vagyis kintrol befele jott a PPTP kapcsolat, nem bentrol kifele. Nincs egy darab kozponti router, amirol lehetne inditani a kapcsolatokat, mindenki ul otthon a foteljaban, es nyomkodja a connect gombot. "
A fentiek alapján vélhetőleg lenne ilyen router a "server1 hálózatában", azaz a munkahelyen. A "server 2 hálózata" felé indíthatana erről a routerről, és nem lenne szükség a munkahelyen 4 ember által 4 külön tunnelt kihúzni.

Én legalábbis ezt hámoztam ki a hozzászólásokból.

Ebben a formaban igazad van.

Viszont ezzel visszajutunk oda, hogy a server1 halozataban korant sem biztos, hogy van olyan router, ami kepes egyszerre VPN-t felepiteni es erre valamilyen ACL-eket rahuzni (hiszen egyaltalan nem biztos, hogy a server2 halozatat minden server1 halozati tagnak el kell tudnia erni. Marpedig amennyiben nem publikus a server2 halozata, abban az esetben nem biztos, hogy jo otlet a server1 kozponti routererol inditani a kapcsolatot (hiszen nagyon jo esellyel default route-kent funkcional, ami nem csak az internet fele valo routolast teszi tovabbi konfiguracio nelkul lehetove, hanem a server2 halozata fele is.

Tekintve, mivel csak 4-5 emberrol tudunk, akik hasznalnak a server2 halozatat a server1 felol, en valamilyen VIP dologra gyanakszom.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

3 konkurrens ppp alapu kapcsolatot szolgal ki egy nem szerver azaz rras nelkuli windows xp|vista|7 (8-at nem tudom, de gyanitom, mint a 7). Ez a 3 konkurrens bejovo kapcsolat lehet pptp, l2tp.

Licensz nem szabalyozza, illetve a tavoli eleres == helyi belepes, mint tavoli asztal hozzaferesek szamara vonatkozo megkotes nem ervenyes ra, ugyanis egy halozatban hozzaferesi routerkent viselkedik es nem kimondottan a helyi gepen valo bejelentkezeseket szolgalja.

( phr3ak | 2013. 08. 05., h – 10:49 )

Megvan a megfejtés, hogy hogyan működött ez eddig és mi változott?