[+] po

[mariaczi]

Cześć.

Zastał mnie problem natury: użytkownik próbuje się połączyć ze swoim serwerem do vpn (ja nie mam do niego dostępu). Ruch przechodzi przez router i NAT. Logi jakie wyłapałem tcpdumpem:

Kod: Zaznacz cały

tcpdump -n host IP_DO_SRVVPN

Kod: Zaznacz cały

21:12:59.208784 IP IP_DO_SRVVPN.1723 > 10.0.0.48.7981: F 189:189(0) ack 349 win 7504
21:12:59.264186 IP 10.0.0.48.7981 > IP_DO_SRVVPN.1723: . ack 190 win 4333
21:12:59.264346 IP 10.0.0.48.7981 > IP_DO_SRVVPN.1723: F 349:349(0) ack 190 win 4333
21:12:59.284461 IP IP_DO_SRVVPN.1723 > 10.0.0.48.7981: . ack 350 win 7504
21:13:21.640429 IP 10.0.0.48.7982 > IP_DO_SRVVPN.1723: S 928286376:928286376(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
21:13:21.675776 IP IP_DO_SRVVPN.1723 > 10.0.0.48.7982: S 1890920255:1890920255(0) ack 928286377 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 0>
21:13:21.792448 IP 10.0.0.48.7982 > IP_DO_SRVVPN.1723: . ack 1 win 4380
21:13:21.792810 IP 10.0.0.48.7982 > IP_DO_SRVVPN.1723: P 1:157(156) ack 1 win 4380: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(0) [|pptp]
21:13:21.815177 IP IP_DO_SRVVPN.1723 > 10.0.0.48.7982: . ack 157 win 6432
21:13:21.816948 IP IP_DO_SRVVPN.1723 > 10.0.0.48.7982: P 1:157(156) ack 157 win 6432: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP() BEARER_CAP() MAX_CHAN(0) FIRM_REV(1) [|pptp]
21:13:21.819692 IP 10.0.0.48.7982 > IP_DO_SRVVPN.1723: P 157:325(168) ack 157 win 4341: pptp CTRL_MSGTYPE=OCRQ CALL_ID(32854) CALL_SER_NUM(80) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) [|pptp]
21:13:21.857013 IP IP_DO_SRVVPN.1723 > 10.0.0.48.7982: P 157:189(32) ack 325 win 7504: pptp CTRL_MSGTYPE=OCRP CALL_ID(53567) PEER_CALL_ID(32854) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(64) PROC_DELAY(0) PHY_CHAN_ID(0)
21:13:21.901058 IP 10.0.0.48.7982 > IP_DO_SRVVPN.1723: P 325:349(24) ack 189 win 4333: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(53567) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
21:13:21.910424 IP 10.0.0.48 > IP_DO_SRVVPN: GREv1, call 53567, seq 0, length 37: LCP, Conf-Request (0x01), id 0, length 23
21:13:21.966271 IP IP_DO_SRVVPN.1723 > 10.0.0.48.7982: . ack 349 win 7504
21:13:23.913188 IP 10.0.0.48 > IP_DO_SRVVPN: GREv1, call 53567, seq 1, length 37: LCP, Conf-Request (0x01), id 1, length 23
21:13:27.003633 IP 10.0.0.48 > IP_DO_SRVVPN: GREv1, call 53567, seq 2, length 37: LCP, Conf-Request (0x01), id 2, length 23
21:13:30.912563 IP 10.0.0.48 > IP_DO_SRVVPN: GREv1, call 53567, seq 3, length 37: LCP, Conf-Request (0x01), id 3, length 23
21:13:34.912768 IP 10.0.0.48 > IP_DO_SRVVPN: GREv1, call 53567, seq 4, length 37: LCP, Conf-Request (0x01), id 4, length 23
21:13:38.913027 IP 10.0.0.48 > IP_DO_SRVVPN: GREv1, call 53567, seq 5, length 37: LCP, Conf-Request (0x01), id 5, length 23
21:13:42.913339 IP 10.0.0.48 > IP_DO_SRVVPN: GREv1, call 53567, seq 6, length 37: LCP, Conf-Request (0x01), id 6, length 23
21:13:46.913558 IP 10.0.0.48 > IP_DO_SRVVPN: GREv1, call 53567, seq 7, length 37: LCP, Conf-Request (0x01), id 7, length 23
21:13:50.914342 IP 10.0.0.48 > IP_DO_SRVVPN: GREv1, call 53567, seq 8, length 37: LCP, Conf-Request (0x01), id 8, length 23
21:13:51.992776 IP IP_DO_SRVVPN.1723 > 10.0.0.48.7982: F 189:189(0) ack 349 win 7504
21:13:52.103288 IP 10.0.0.48.7982 > IP_DO_SRVVPN.1723: . ack 190 win 4333
21:13:52.103401 IP 10.0.0.48.7982 > IP_DO_SRVVPN.1723: F 349:349(0) ack 190 win 4333
21:13:52.124078 IP IP_DO_SRVVPN.1723 > 10.0.0.48.7982: . ack 350 win 7504

Czy powyższy wycinek tcpdumpa jest poprawny? Powyższa sekwencja powtarza się i połączenie nie może zostać nawiązane. Nie wiem jaki komunikat dostaje klient, nie było mnie przy jego komputerze.

Dodane:
Będzie dla potomnych.
Problem rozwiązany poprzez załadowanie modułów

Kod: Zaznacz cały

modprobe ip_nat_pptp
modprobe ip_conntrack_pptp

oraz akceptację protokołu gre na łańcuchu FORWARD (w odpowiednim miejscu firewalla):

Kod: Zaznacz cały

iptables -A FORWARD -p gre -j ACCEPT