Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Petr 26. 01. 2017, 12:48:21
-
Zdravím,
snažím se rozchodit připojení ke korporátní VPN z Raspberry Pi, nebo prostě z linuxu.
Jde o PPTP s ověřením přes certifikáty, tj. EAP-TLS a s MPPE-128. Opatchoval jsem si PPPD aby to uměl (http://www.nikhef.nl/~janjust/ppp/ (http://www.nikhef.nl/~janjust/ppp/)), je to verze 2.4.6.
Klient se mi autentifikuje oproti Win serveru, dostane od něj IP a DNSka, vytvoří se rozhraní ppp0, přidá se routa na endpoint a za pár sekund se vše rozpadne (pokaždé to trvá stejně dlouho). Neprojde žádný paket, resp. od serveru ke mě se žádný nedostane skrz rozhraní ppp0 - nejde ping, nic.
Jiný klient, postavený na windows, ze stejné sítě za stejným routerem se stejným protokolem připojí a jede.
Mohl by mě prosím někdo nakopnout správným směrem? Posílám konfiguraci (ale ta je asi správně) a logy.
konfigurace pppd - různé pokusy s parametry co jsou zakomentované nepomůžou...
pty "pptp xxx --nolaunchpppd"
#novj
noauth
#ipcp-accept-local
#ipcp-accept-remote
#noipdefault
nodefaultroute
#nodeflate
#nobsdcomp
#nopredictor1
#nopcomp
#noaccomp
#lcp-echo-failure 0
#lcp-echo-interval 0
#proxyarp
usepeerdns
refuse-pap
refuse-chap
refuse-mschap
#mru 1500
#mtu 1500
name xxx
remotename xxx
domain xxxx
require-mppe-128
debug
logfile /tmp/pppd.log
syslog - od okamžiku kdy to spadne...
Jan 26 12:29:06 raspberrypi pptp[5357]: anon log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed
Jan 26 12:29:06 raspberrypi pptp[5357]: anon log[callmgr_main:pptp_callmgr.c:258]: Closing connection (shutdown)
Jan 26 12:29:06 raspberrypi pptp[5357]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Jan 26 12:29:06 raspberrypi pptp[5357]: anon log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed
Jan 26 12:29:06 raspberrypi pptp[5357]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)
Jan 26 12:29:06 raspberrypi pppd[5344]: Script pptp xxx --nolaunchpppd finished (pid 5345), status = 0x0
Jan 26 12:29:06 raspberrypi pppd[5344]: Modem hangup
Jan 26 12:29:06 raspberrypi pppd[5344]: Connect time 0.6 minutes.
Jan 26 12:29:06 raspberrypi pppd[5344]: Sent 0 bytes, received 0 bytes.
Jan 26 12:29:06 raspberrypi pppd[5344]: Script /etc/ppp/ip-down started (pid 5437)
Jan 26 12:29:06 raspberrypi pppd[5344]: MPPE disabled
Jan 26 12:29:06 raspberrypi pppd[5344]: sent [LCP TermReq id=0x2 "MPPE disabled"]
Jan 26 12:29:06 raspberrypi pppd[5344]: Connection terminated.
Jan 26 12:29:06 raspberrypi avahi-daemon[538]: Withdrawing workstation service for ppp0.
Jan 26 12:29:06 raspberrypi pppd[5344]: Waiting for 1 child processes...
Jan 26 12:29:06 raspberrypi pppd[5344]: script /etc/ppp/ip-down, pid 5437
Jan 26 12:29:06 raspberrypi pppd[5344]: Script /etc/ppp/ip-down finished (pid 5437), status = 0x0
Jan 26 12:29:06 raspberrypi pppd[5344]: Exit.
Jan 26 12:29:07 raspberrypi ntpd[702]: Deleting interface #25 ppp0, 10.100.8.11#123, interface stats: received=0, sent=0, dropped=0, active_time=31 secs
pppd.log - od okamžiku úspěšné autentifikace
....
EAP authentication succeeded
sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0xd <mppe +H -M +S -L -D +C>]
sent [CCP ConfNak id=0xd <mppe +H -M +S -L -D -C>]
rcvd [IPCP ConfReq id=0xe <addr 10.100.8.10>]
sent [IPCP TermAck id=0xe]
rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0xf <mppe +H -M +S -L -D -C>]
sent [CCP ConfAck id=0xf <mppe +H -M +S -L -D -C>]
MPPE 128-bit stateless compression enabled
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [IPCP ConfNak id=0x2 <addr 10.100.8.28> <ms-dns1 10.100.100.101> <ms-dns2 10.100.100.102>]
sent [IPCP ConfReq id=0x3 <addr 10.100.8.28> <ms-dns1 10.100.100.101> <ms-dns2 10.100.100.102>]
rcvd [IPCP ConfAck id=0x3 <addr 10.100.8.28> <ms-dns1 10.100.100.101> <ms-dns2 10.100.100.102>]
rcvd [IPCP ConfReq id=0x10 <addr 10.100.8.10>]
sent [IPCP ConfAck id=0x10 <addr 10.100.8.10>]
local IP address 10.100.8.28
remote IP address 10.100.8.10
primary DNS address 10.100.100.101
secondary DNS address 10.100.100.102
Script /etc/ppp/ip-up started (pid 4893)
Script /etc/ppp/ip-up finished (pid 4893), status = 0x0
Script pptp xxx --nolaunchpppd finished (pid 4880), status = 0x0
Modem hangup
Connect time 0.6 minutes.
Sent 1092 bytes, received 0 bytes.
Script /etc/ppp/ip-down started (pid 4975)
MPPE disabled
sent [LCP TermReq id=0x2 "MPPE disabled"]
Connection terminated.
Waiting for 1 child processes...
script /etc/ppp/ip-down, pid 4975
Script /etc/ppp/ip-down finished (pid 4975), status = 0x0
routy
root@raspberrypi:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.99.100 0.0.0.0 UG 303 0 0 wlan0
10.8.0.0 10.8.0.1 255.255.255.0 UG 0 0 0 tun0
10.8.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0
**10.100.0.0 10.100.8.10 255.255.0.0 UG 0 0 0 ppp0
10.100.8.10 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.99.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0
193.84.175.148 192.168.99.100 255.255.255.255 UGH 0 0 0 wlan0
------------------------
root@raspberrypi:~# ip route get 10.100.8.10
10.100.8.10 dev ppp0 src 10.100.8.21
cache
------------------------
tu routu označenou hvězdičkami si přidávám sám, ale nechodí to ani bez ní ani s ní. Rozhraní tun0 je jiná vpn, ale nechodí to ani když ji shodím.
Přidal jsem ještě tyto ... modprobe...
nf_nat_pptp
nf_conntrack_pptp
nf_conntrack_proto_gre
-
zeby...?
MPPE disabled
sent [LCP TermReq id=0x2 "MPPE disabled"]
-
zeby...?
MPPE disabled
sent [LCP TermReq id=0x2 "MPPE disabled"]
tak nic, to je az po rozpojeni.
ale skus odkomentovat "nobsdcomp"...
-
Ideálne skús pozrieť cez wireshark čo sa tam naozaj deje. Celkom častý problem s PPTP je, že pokiaľ server pošle GRE/PPP paket pred tým ako je otvorený RAW socket obsluhujúci PPP spojenie (Po prijatí správy OutgoingCallReply cez riadiace TCP spojenie), kernel pošle späť ICMP procol-unreacheable správu, na ktorú server zareaguje prerušením spojenia. Dá sa to nepekne obísť tým že zablokuješ ICMP protol-unreachable cez iptables:
iptables -I OUTPUT -p icmp --icmp-type protocol-unreachable -j DROP
iptables -I FORWARD -p icmp --icmp-type protocol-unreachable -j DROP
... ale je možné, že problém je niekde inde.
-
Tak popořadě - nobsdcomp nepomůže, vyzkoušeno, ani žádný jiný z těch parametrů co jsou zakomentované...
Vyzkoušel jsem přidat ty iptables pravidla -> protocol-unreachable, ale nemá to žádný pro mě viditelný efekt....
Tady je záznam z wireshark, je tam vidět jak se dohodnou na šifrování a pak si pošlou ty konfigurační data - IP, DNS atd. To je čas 538 až 871, pak se už nestane nic a pošle se nějaké Call-Clear-Request a v čase 1220 (???) to server zařízene. Nebo o kus dřív? Tomu úplně nerozumím.
Nějaké GRE pakety se tedy vymění - jestli to dobře chápu je v nich konfigurace, ale pak už nic.
No. Time Source Destination Protocol Length Info
201 3.063047 192.168.99.6 xxx.xxx.xxx.xxx TCP 74 42256→1723 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=189466 TSecr=0 WS=128
202 3.066901 xxx.xxx.xxx.xxx 192.168.99.6 TCP 74 1723→42256 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 TSval=66587157 TSecr=189466
203 3.067031 192.168.99.6 xxx.xxx.xxx.xxx TCP 66 42256→1723 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=189466 TSecr=66587157
204 3.068657 192.168.99.6 xxx.xxx.xxx.xxx PPTP 222 Start-Control-Connection-Request
205 3.072573 xxx.xxx.xxx.xxx 192.168.99.6 PPTP 222 Start-Control-Connection-Reply
206 3.072736 192.168.99.6 xxx.xxx.xxx.xxx TCP 66 42256→1723 [ACK] Seq=157 Ack=157 Win=30336 Len=0 TSval=189467 TSecr=66587158
500 4.069242 192.168.99.6 xxx.xxx.xxx.xxx PPTP 234 Outgoing-Call-Request
501 4.073723 xxx.xxx.xxx.xxx 192.168.99.6 PPTP 98 Outgoing-Call-Reply
502 4.073829 192.168.99.6 xxx.xxx.xxx.xxx TCP 66 42256→1723 [ACK] Seq=325 Ack=189 Win=30336 Len=0 TSval=189567 TSecr=66587258
503 4.074697 192.168.99.6 xxx.xxx.xxx.xxx PPP LCP 66 Configuration Request
504 4.078274 xxx.xxx.xxx.xxx 192.168.99.6 PPP LCP 106 Configuration Request
505 4.078289 xxx.xxx.xxx.xxx 192.168.99.6 PPP LCP 66 Configuration Ack
506 4.079186 192.168.99.6 xxx.xxx.xxx.xxx PPP LCP 69 Configuration Reject
507 4.081651 xxx.xxx.xxx.xxx 192.168.99.6 PPP LCP 95 Configuration Request
508 4.082398 192.168.99.6 xxx.xxx.xxx.xxx PPP LCP 95 Configuration Ack
509 4.084972 xxx.xxx.xxx.xxx 192.168.99.6 PPTP 90 Set-Link-Info
510 4.085108 192.168.99.6 xxx.xxx.xxx.xxx TCP 66 42256→1723 [ACK] Seq=325 Ack=213 Win=30336 Len=0 TSval=189568 TSecr=66587259
511 4.085270 xxx.xxx.xxx.xxx 192.168.99.6 EAP 59 Request, Identity
512 4.085946 192.168.99.6 xxx.xxx.xxx.xxx EAP 68 Response, Identity
513 4.176158 xxx.xxx.xxx.xxx 192.168.99.6 GRE 46 Encapsulated PPP
514 4.399602 xxx.xxx.xxx.xxx 192.168.99.6 EAP 56 Request, TLS EAP (EAP-TLS)
515 4.416784 192.168.99.6 xxx.xxx.xxx.xxx TLSv1 253 Client Hello
516 4.422381 xxx.xxx.xxx.xxx 192.168.99.6 IPv4 1514 Fragmented IP protocol (proto=Generic Routing Encapsulation 47, off=0, ID=0d66) [Reassembled in #517]
517 4.422601 xxx.xxx.xxx.xxx 192.168.99.6 TLSv1 70 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
518 4.423636 192.168.99.6 xxx.xxx.xxx.xxx EAP 60 Response, TLS EAP (EAP-TLS)
519 4.428069 xxx.xxx.xxx.xxx 192.168.99.6 IPv4 1514 Fragmented IP protocol (proto=Generic Routing Encapsulation 47, off=0, ID=0d67) [Reassembled in #520]
520 4.428278 xxx.xxx.xxx.xxx 192.168.99.6 TLSv1 70 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
521 4.429260 192.168.99.6 xxx.xxx.xxx.xxx EAP 60 Response, TLS EAP (EAP-TLS)
522 4.433826 xxx.xxx.xxx.xxx 192.168.99.6 IPv4 1514 Fragmented IP protocol (proto=Generic Routing Encapsulation 47, off=0, ID=0d68) [Reassembled in #523]
523 4.434053 xxx.xxx.xxx.xxx 192.168.99.6 TLSv1 70 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
524 4.435019 192.168.99.6 xxx.xxx.xxx.xxx EAP 60 Response, TLS EAP (EAP-TLS)
525 4.438107 xxx.xxx.xxx.xxx 192.168.99.6 TLSv1 800 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
526 4.537509 192.168.99.6 xxx.xxx.xxx.xxx TLSv1 1450 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
527 4.541665 xxx.xxx.xxx.xxx 192.168.99.6 EAP 60 Request, TLS EAP (EAP-TLS)
528 4.542657 192.168.99.6 xxx.xxx.xxx.xxx TLSv1 1446 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
529 4.547162 xxx.xxx.xxx.xxx 192.168.99.6 EAP 60 Request, TLS EAP (EAP-TLS)
530 4.548296 192.168.99.6 xxx.xxx.xxx.xxx TLSv1 1446 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
531 4.552394 xxx.xxx.xxx.xxx 192.168.99.6 EAP 60 Request, TLS EAP (EAP-TLS)
532 4.553328 192.168.99.6 xxx.xxx.xxx.xxx TLSv1 1446 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
533 4.559427 xxx.xxx.xxx.xxx 192.168.99.6 EAP 60 Request, TLS EAP (EAP-TLS)
534 4.560143 192.168.99.6 xxx.xxx.xxx.xxx TLSv1 220 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
535 4.574649 xxx.xxx.xxx.xxx 192.168.99.6 TLSv1 123 Change Cipher Spec, Encrypted Handshake Message
536 4.578235 192.168.99.6 xxx.xxx.xxx.xxx EAP 60 Response, TLS EAP (EAP-TLS)
537 4.581378 xxx.xxx.xxx.xxx 192.168.99.6 EAP 58 Success
538 4.582308 192.168.99.6 xxx.xxx.xxx.xxx PPP CCP 64 Configuration Request
539 4.584956 xxx.xxx.xxx.xxx 192.168.99.6 PPP CCP 60 Configuration Request
540 4.584973 xxx.xxx.xxx.xxx 192.168.99.6 PPP IPCP 60 Configuration Request
541 4.585300 192.168.99.6 xxx.xxx.xxx.xxx GRE 46 Encapsulated PPP
542 4.585630 192.168.99.6 xxx.xxx.xxx.xxx PPP CCP 60 Configuration Nak
543 4.585826 192.168.99.6 xxx.xxx.xxx.xxx PPP IPCP 54 Termination Ack
544 4.587365 xxx.xxx.xxx.xxx 192.168.99.6 PPP CCP 64 Configuration Ack
545 4.587822 xxx.xxx.xxx.xxx 192.168.99.6 PPP CCP 64 Configuration Request
546 4.588054 192.168.99.6 xxx.xxx.xxx.xxx GRE 46 Encapsulated PPP
547 4.589279 192.168.99.6 xxx.xxx.xxx.xxx PPP CCP 60 Configuration Ack
548 4.589499 192.168.99.6 xxx.xxx.xxx.xxx PPP IPCP 72 Configuration Request
549 4.592930 xxx.xxx.xxx.xxx 192.168.99.6 PPP IPCP 76 Configuration Nak
550 4.593654 192.168.99.6 xxx.xxx.xxx.xxx PPP IPCP 76 Configuration Request
551 4.596120 xxx.xxx.xxx.xxx 192.168.99.6 PPP IPCP 76 Configuration Ack
552 5.096997 192.168.99.6 xxx.xxx.xxx.xxx GRE 46 Encapsulated PPP
870 6.095748 xxx.xxx.xxx.xxx 192.168.99.6 PPP IPCP 60 Configuration Request
871 6.099616 192.168.99.6 xxx.xxx.xxx.xxx PPP IPCP 64 Configuration Ack
872 6.115393 xxx.xxx.xxx.xxx 192.168.99.6 PPTP 82 Call-Clear-Request
873 6.115602 192.168.99.6 xxx.xxx.xxx.xxx TCP 66 42256→1723 [ACK] Seq=325 Ack=229 Win=30336 Len=0 TSval=189771 TSecr=66587462
1220 37.128129 xxx.xxx.xxx.xxx 192.168.99.6 TCP 66 1723→42256 [FIN, ACK] Seq=229 Ack=325 Win=131584 Len=0 TSval=66590563 TSecr=189771
1221 37.128482 192.168.99.6 xxx.xxx.xxx.xxx PPTP 82 Call-Clear-Request
1222 37.128940 192.168.99.6 xxx.xxx.xxx.xxx TCP 66 42256→1723 [FIN, ACK] Seq=341 Ack=230 Win=30336 Len=0 TSval=192873 TSecr=66590563
1223 37.131587 xxx.xxx.xxx.xxx 192.168.99.6 TCP 66 1723→42256 [ACK] Seq=230 Ack=342 Win=131584 Len=0 TSval=66590564 TSecr=192873
Prosímtě johnyseb, vypadá že do toho vidíš, mohl bych ti poslat i detailnější data, ale mimo veřejnost, kdybys měl čas/ochotu pomoct... ? Jinak i za ten tip s IPTABLES samozřejmě díky.
Nemůže to být nějaký bordel jen v routování? Když všechny svoje zásahy vyhodím, udělá PPPD jen routu
10.100.8.10 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0což se ni zdá dobře, aby to teklo k tomu endpointu, ale ... nevím.
Nějak nefunguje přihlášení k tomuhle fóru mimochodem...
-
Jo ty poslední TCP pakety to je konec toho řídícího TCP spojení asi... mezi tím není tedy nic. Poslední Configuration Ack je potvrzení že klient přijímá IP adresu od serveru. Ten další Call-Clear-Request nevím proč tam je a pak se uzavře TCP spojení... kurňa proč.
-
873 6.115602 192.168.99.6 xxx.xxx.xxx.xxx TCP 66 42256→1723 [ACK] Seq=325 Ack=229 Win=30336 Len=0 TSval=189771 TSecr=66587462
1220 37.128129 xxx.xxx.xxx.xxx 192.168.99.6 TCP 66 1723→42256 [FIN, ACK] Seq=229 Ack=325 Win=131584 Len=0 TSval=66590563 TSecr=189771
Jak rikas Petre. Nevim co presne nastavujete/provozujete na tom Windowsu, protoze mozna vam chybi L2TPD, protoze to mate za natem, jestli IPSec tak urcite L2TPD.
Jinak zapnete si debug vypisy na pppd, zapnete si tcpdump a snad na to prijdete. Popr. zkuste nejdriv rozbehat MS-CHAP a pak teprve EAP-TLS at vite jestli je to tunelem nebo necim jinym. Jeste me napada jedna vec MTU! Jestli se vam nahodou ten packet nefragmentuje, kdyz ho encapsulujete, dejte si MTU 1400 na PPPD.
-
Nemám bohužel v moci server na win, ani nevím co tam přesně je. Mám jen klienta na win, který se připojit dokáže.
Zkouším MS-CHAPv2 na jiné VPN, která ho podporuje (tato problematická už ale ne - jen EAP-TLS).
Jenže zde mi pppd zase odmítá najít hesla... nechápu. Mám tu soubor chap-secrets a stejně mi to tvrdí
pppd: The remote system is required to authenticate itself
pppd: but I couldn't find any suitable secret (password) for it to use to do so.
zkouším různé varianty ale stejně to na mě kašle...
Podezřívám, že patchovaná verze pppd na EAP-TLS to má zas s MS-CHAP nějak jinak...
-
No, tak tu druhou VPN přes MS CHAP jsem rozchodil (chap-secrets musí mít dva řádky na jeden secret... logic!)
Tenhle tunel funguje, dopingnu se na endpoint. Routu na ostatní ve vzdálené síti jsem neřešil, ale prostě ten PPTP tunel je průchozí. Takže: routerem to není, pppd to není - jinou autentifikací přes jiný server to jde.
MTU to není, zkoušel jsem snížit... nefunguje. I tento tunel používá MPPE128, takže v tom problém není.
Tak babo... raď...
Jinak samozřejmě děkuji za asistenci...
Bohužel je to tedy fyzicky jiný server, jiné IP z jiného rozsahu dostanu, všechno jinak. Zkontroluju tím vlastně jen PPPD u sebe (částečně, bez EAP-TLS) a router...
-
Podle toho co pises tak to bude tim dokompilovanym modulem. Zkus si stahnout starsi zdrojak, nebo se podivej jestli tam nejsou nejaky known issues predevsim kompatibility. Je taky mozny, ze se bude muset neco nastavit na tom serveru, tezko hadat.
-
Zkusil jsem tedy verzi 2.4.5, ale je to totéž.
Zajímalo by mě, jestli něčemu vadí, že v jádře je toto
[11681.714995] PPP generic driver version 2.4.2
[15901.644622] PPP MPPE Compression module registered
Tj. je to jiná verze. Protože s jádrem jsem nic nedělal. Ale tuším pro Raspbian je aktuálně: ppp 2.4.6-3.1 a v jádře je ten modul 2.4.2. Takže to asi nevadí/je jedno.
Taky vzhledem k tomu že přes ten MSCHAP to chodí...
Jaké jsou další možnosti, napadá prosím někoho něco?
Abych to shrnul: pppd s eap-tls mppe patchem FUNGUJE oproti win serveru s MS CHAP + MPPE-128. Nefunguje oproti jinému win serveru s EAP-TLS + MPPE 128, přestože se úspěšně autentifikuje certifikáty, obdrží IP adresu, DNSka a tak. Skrz tunel neprochází (zřejmě) pakety (alespoň ne zpět) a do pár sekund (zřejmě server) ukončí spojení signálem "Call-Clear-Request" (i když podle všeho toto by měl posílat klient, když chce rozvázat spojení).
-
V tomhle stavu bych se asi uz zvrhnul v ocumovani komunikace ve wireshark na funkcnim widlim klientovi a zkousel zjistit co dela jinak ze to jede, pokud najdu neco podezreleho tak pak zkusit vyhledat Issue zabyvajici se danou problematikou. Kdyz bych nic nenasel tak pak bych se pokusil rozrejpat clienta na linuxu tak aby delal vice mene to same dokud se to nerozjede a to Issue zalozil sam :-D
No ale prvne bych vyzkousel jak se chovaji jina linux distra na normal PC, napr takove ubuntu a archlinux... dost casto se mi stava ze mi pod Archlinuxem jedou veci ktere jsem nemohl sprovoznit na ubuntu ani kdyz jsem se malem pretrhl a to za stejneho postupu. Osobne z toho duvodu pouzivam na RPI ARM Archlinux, oproti Raspbianu je to cele light (tedy pokud nechci GUI).
Bojuj! :)
-
Takže z win klienta:
38 6.525716 192.168.4.13 xxx.xxx.xxx.xxx TCP 66 55206 → 1723 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
39 6.537998 xxx.xxx.xxx.xxx 192.168.4.13 TCP 66 1723 → 55206 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
40 6.538091 192.168.4.13 xxx.xxx.xxx.xxx TCP 54 55206 → 1723 [ACK] Seq=1 Ack=1 Win=17520 Len=0
41 6.538844 192.168.4.13 xxx.xxx.xxx.xxx PPTP 210 Start-Control-Connection-Request
43 6.559223 xxx.xxx.xxx.xxx 192.168.4.13 PPTP 210 Start-Control-Connection-Reply
44 6.559358 192.168.4.13 xxx.xxx.xxx.xxx PPTP 222 Outgoing-Call-Request
45 6.570087 xxx.xxx.xxx.xxx 192.168.4.13 PPTP 86 Outgoing-Call-Reply
46 6.577223 192.168.4.13 xxx.xxx.xxx.xxx PPTP 78 Set-Link-Info
47 6.586785 192.168.4.13 xxx.xxx.xxx.xxx PPP LCP 98 Configuration Request
48 6.597074 xxx.xxx.xxx.xxx 192.168.4.13 PPP LCP 106 Configuration Request
49 6.597148 xxx.xxx.xxx.xxx 192.168.4.13 PPP LCP 98 Configuration Ack
50 6.598152 192.168.4.13 xxx.xxx.xxx.xxx PPP LCP 106 Configuration Ack
51 6.598401 192.168.4.13 xxx.xxx.xxx.xxx PPP LCP 66 Identification
52 6.598467 192.168.4.13 xxx.xxx.xxx.xxx PPP LCP 74 Identification
53 6.598546 192.168.4.13 xxx.xxx.xxx.xxx PPP LCP 72 Identification
54 6.607823 xxx.xxx.xxx.xxx 192.168.4.13 EAP 57 Request, Identity
55 6.607876 xxx.xxx.xxx.xxx 192.168.4.13 PPTP 78 Set-Link-Info
56 6.607914 192.168.4.13 xxx.xxx.xxx.xxx PPTP 78 Set-Link-Info
57 6.613966 192.168.4.13 xxx.xxx.xxx.xxx EAP 75 Response, Identity
58 6.689280 xxx.xxx.xxx.xxx 192.168.4.13 GRE 46 Encapsulated PPP
59 6.735782 xxx.xxx.xxx.xxx 192.168.4.13 EAP 54 Request, TLS EAP (EAP-TLS)
60 6.759219 192.168.4.13 xxx.xxx.xxx.xxx TLSv1 165 Client Hello
61 6.782836 xxx.xxx.xxx.xxx 192.168.4.13 TLSv1 1448 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
62 6.783462 192.168.4.13 xxx.xxx.xxx.xxx EAP 58 Response, TLS EAP (EAP-TLS)
64 6.805668 xxx.xxx.xxx.xxx 192.168.4.13 TLSv1 1448 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
65 6.811807 192.168.4.13 xxx.xxx.xxx.xxx EAP 58 Response, TLS EAP (EAP-TLS)
67 6.828292 xxx.xxx.xxx.xxx 192.168.4.13 TCP 54 1723 → 55206 [ACK] Seq=213 Ack=373 Win=131072 Len=0
68 6.838227 xxx.xxx.xxx.xxx 192.168.4.13 TLSv1 1448 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
69 6.838709 192.168.4.13 xxx.xxx.xxx.xxx EAP 58 Response, TLS EAP (EAP-TLS)
70 6.869823 xxx.xxx.xxx.xxx 192.168.4.13 TLSv1 1102 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
72 6.889722 192.168.4.13 xxx.xxx.xxx.xxx TLSv1 1450 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
73 6.913378 xxx.xxx.xxx.xxx 192.168.4.13 EAP 58 Request, TLS EAP (EAP-TLS)
74 6.913809 192.168.4.13 xxx.xxx.xxx.xxx TLSv1 1450 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
75 6.927043 xxx.xxx.xxx.xxx 192.168.4.13 EAP 58 Request, TLS EAP (EAP-TLS)
76 6.927406 192.168.4.13 xxx.xxx.xxx.xxx TLSv1 1450 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
77 6.938023 xxx.xxx.xxx.xxx 192.168.4.13 EAP 58 Request, TLS EAP (EAP-TLS)
78 6.938459 192.168.4.13 xxx.xxx.xxx.xxx TLSv1 125 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
80 6.976430 xxx.xxx.xxx.xxx 192.168.4.13 TLSv1 121 Change Cipher Spec, Encrypted Handshake Message
81 7.011369 192.168.4.13 xxx.xxx.xxx.xxx EAP 58 Response, TLS EAP (EAP-TLS)
82 7.034482 xxx.xxx.xxx.xxx 192.168.4.13 EAP 56 Success
83 7.034529 xxx.xxx.xxx.xxx 192.168.4.13 PPP CBCP 54 Callback Request
84 7.037745 192.168.4.13 xxx.xxx.xxx.xxx PPP CBCP 58 Callback Response
85 7.063726 xxx.xxx.xxx.xxx 192.168.4.13 PPP CBCP 58 Callback Ack
86 7.063769 xxx.xxx.xxx.xxx 192.168.4.13 PPP CCP 58 Configuration Request
87 7.063791 xxx.xxx.xxx.xxx 192.168.4.13 PPP IPCP 58 Configuration Request
88 7.066581 192.168.4.13 xxx.xxx.xxx.xxx PPP CCP 62 Configuration Request
89 7.066827 192.168.4.13 xxx.xxx.xxx.xxx PPP IPCP 82 Configuration Request
90 7.067003 192.168.4.13 xxx.xxx.xxx.xxx PPP CCP 58 Configuration Ack
91 7.067534 192.168.4.13 xxx.xxx.xxx.xxx PPP IPCP 58 Configuration Ack
92 7.090041 xxx.xxx.xxx.xxx 192.168.4.13 PPP CCP 62 Configuration Ack
93 7.090086 xxx.xxx.xxx.xxx 192.168.4.13 PPP IPCP 64 Configuration Reject
94 7.090523 192.168.4.13 xxx.xxx.xxx.xxx PPP IPCP 74 Configuration Request
95 7.112249 xxx.xxx.xxx.xxx 192.168.4.13 PPP IPCP 74 Configuration Nak
96 7.112560 192.168.4.13 xxx.xxx.xxx.xxx PPP IPCP 74 Configuration Request
97 7.131901 xxx.xxx.xxx.xxx 192.168.4.13 PPP IPCP 74 Configuration Ack
101 7.195768 192.168.4.13 xxx.xxx.xxx.xxx GRE 46 Encapsulated PPP
103 7.271801 192.168.4.13 xxx.xxx.xxx.xxx PPP Comp 87 Compressed data
105 7.274335 192.168.4.13 xxx.xxx.xxx.xxx PPP Comp 104 Compressed data
107 7.279597 192.168.4.13 xxx.xxx.xxx.xxx PPP Comp 108 Compressed data
108 7.296875 192.168.4.13 xxx.xxx.xxx.xxx PPP Comp 136 Compressed data
109 7.297019 192.168.4.13 xxx.xxx.xxx.xxx PPP Comp 125 Compressed data
....
tj. vidím, že až po 97 7.131901 je to prakticky stejné, tam končí konfigurace tunelu a potvrdí se dohoda na IP adresách...
Pak klient pošle GRE paket a tak nějakou další komunikaci uvnitř PPP...
ten GRE paket:
Frame 101: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) on interface 0
Ethernet II, Src: xxx, Dst: xxx
Internet Protocol Version 4, Src: 192.168.4.13, Dst: xxx
Generic Routing Encapsulation (PPP)
Flags and Version: 0x2081
Protocol Type: PPP (0x880b)
Payload Length: 0
Call ID: 12728
Acknowledgment Number: 20
nic zajímavého...
Nevím jestli má smysl se koukat do toho co se děje uvnitř toho tunelu, ale nevím ani jak - to síťové rozhraní PPTP najede až po připojení a nevím jak wireshark donutit koukat se na něj od začátku.
Ale nemyslím si, že by to pomohlo.
Ale jedna věc tam zajímavá je. Win2win diskuze po EAP success pokračuje výměnou PPP CBCP - callback req, callback resp, callback ack. Nevím co to je. Ale na Linuxu to nedělá. Nicméně to posílá server...
Ještě je tam třeba rozdál v Set-Link-Info, na to linux klient neodpovi, win ano, nevím co to je.
No prostě, semtam tam rozdíly trochu jsou, ale nejsem schopen je interpretovat...
-
Ha, problém bude asi toto!
https://github.com/paulusmack/ppp/blob/master/README.cbcp
CBCP!
-
Hm tak to byl asi přehnaný optimismus. Je to nějaká prastará MS technologie a pochybuju že by na tom záviselo setrvání linky v provozu.
-
urcite by stalo zato navazat komunikaci s autorem toho patchu
-
Ono to asi nemá moc cenu, protože jsem to zkusil přeložit s podporou CBCP a nemá to na to vliv. Klient stejně žádné CBCP pokusy neprojedná. Ale server ani nevydá ten CBCP request.
Sice něco se v popisu o tom protokolu píše, že když se na tom dohodnou, tak se to spojení zavěsí a zkusí se vytočit nějaké číslo, ale podrobnosti mi nejsou jasné. Ani jsem nikde nezaznamenal, že by to někomu dělalo problémy.
Udivuje mě, že nikdo podobný problém nemá, zdá se že EAP-TLS s PPTP je docela běžná konfigurace na win serveru...
MS CHAP je už dost mimo, ale lidi řeší především to.
Jinou distribuci jsem, pravda, ještě nezkoušel, ale mou situaci by to možná stejně neřešilo.... nějaký nápad ještě?
-
Takže jak už to tak bývá, tak řešení bylo velmi jednoduché, ale pomohlo mi k tomu až dohodnout se s adminem win serveru, který se koukal u sebe a říkal mi co vidí, když se připojil funkční win klient a když nefunkční linux klient.
No a důvod byl, že já měl v konfiguraci podle různých návodů parametr
name [domena]\\[uzivatelskejmeno]
ale on to tam chtěl ten server mít to jméno jinak, jako uzivatelske.jmeno@domena.cz
Popravdě moc nechápu jak to s těmi jmény domén je.
Existuje nějaké zkrácené jméno, třeba BLB.
Pak máme zavedenu klasicky doménu na www třeba TRUBKA.CZ
Emaily máme josef.novak@trubka.cz
K win se hlasim jako novak respektive blb\novak
Můžu se asi přihlásit i jako josef.novak@trubka.cz, nebo mozna josef.novak@blb.trubka.cz
Každopádně mám představu že plné jméno domény je blb.trubka.cz
Já tam měl jen blb\\novak
a ono to tam chce josef.novak@trubka.cz což má zřejmě server k dispozici v LDAP nebo to nějak ověřuje podle certifikátu, který je na toto...
No, nerozumím tomu...
Což otevírá další téma, že bych chtěl rozchodit Kerberos, ale neumím to nastavit, na to otevřu jiné téma...
Díky všem za hlp