LINUX.ORG.RU
ФорумAdmin

PPTP «ест» траффик

 , ,


0

1

Всем привет. Имеется:

  1. Роутер AsusWRT с локальным адресом 192.168.1.1
  2. PPTP сервер на роутере в подсети 192.168.10.0
  3. VPN клиент, получил адрес 192.168.10.2 на интерфейсе ppp10
  4. На клиенте поднят веб сервер на порту 8080.

SSH на роутер, curl 192.168.10.2:8080 - и ничего. Сервер молчит, curl висит.

В tcpdump port 8080 -i -nn запрос вижу:

21:51:44.975943 IP 192.168.1.1.53149 > 192.168.10.2.8080: Flags [S], seq 2397839047, win 5440, options [mss 1360,sackOK,TS val 499048 ecr 0,nop,wscale 2], length 0

Тот же запрос виден в логе после добавления правила iptables -A OUTPUT -p tcp --dport 8080 -j LOG:

Aug 10 00:39:50 kernel: IN= OUT=ppp10 SRC=192.168.1.1 DST=192.168.10.2 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=62570 DF PROTO=TCP SPT=40334 DPT=8080 WINDOW=5440 RES=0x00 SYN URGP=0 

Но на входе br0 трафика на порт 8080 нет, соответственно до клиента ничего не доходит.

Маршрутизацию не трогал, она выглядит норм:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
78.123.123.123  0.0.0.0         255.255.255.255 UH        0 0          0 eth0
192.168.10.2    0.0.0.0         255.255.255.255 UH        0 0          0 ppp10
78.123.123.120  0.0.0.0         255.255.255.252 U         0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 br0
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0         78.123.123.123  0.0.0.0         UG        0 0          0 eth0

В iptables тоже все вроде в порядке:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N ACCESS_RESTRICTION
-N FUPNP
-N INPUT_ICMP
-N NSFW
-N PControls
-N PTCSRVLAN
-N PTCSRVWAN
-N SECURITY
-N logaccept
-N logdrop
-A INPUT -i ppp10 -j ACCEPT
-A INPUT -i ppp10 -j LOG
-A INPUT -i br0 -p tcp -m tcp --dport 82 -j LOG
-A FORWARD -i ppp10 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i ppp10 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD ! -i br0 -o eth0 -j DROP
-A FORWARD -i eth0 -m state --state INVALID -j DROP
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -j NSFW
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -i br0 -j ACCEPT
-A PControls -j ACCEPT
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j DROP
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -j DROP
-A SECURITY -j RETURN
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP

Подскажите, пожалуйста, в чем может быть проблема?



Последнее исправление: kalayda (всего исправлений: 2)
  1. Трафик не должен попадать в br0, у вас же ppp-интерфейс не в бридже.

  2. Проверьте настройки firewall на 192.168.10.2. Там Windows?

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS
  1. Клиент VPN подключен по Wi-Fi, br0. Всё равно не должен? Тогда куда должен, где его ловить на выходе из роутера?

  2. Да, Windows. 8080 открыт, проверял.

Прикол ещё в том, что если подключаться по OpenVPN, то с VPN сервера клиент и пингуется, и на web-сервер заходится.

То есть косяк именно с PPTP.

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

pptp заворачивает пакеты в GRE, в tcpdump нужно ловить GRE-пакеты, возникающие одновременно с данными tcp порт 8080.

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

Так и оказалось. Подключился к тому же серверу с Linux-а с web сервером на том же 8080 - замечательно и пингуется, и браузится с PPTP сервера.

При этом ни Windows-клиент не доступен с Linux-клиента и с VPN сервера, ни в обратную сторону, даже пинги не проходят.

Причем в Windows TCP SYN приходят, но на этом все заканчивается, ACK-ов нет.

route print выглядит так

          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.122     35
   12.123.123.123  255.255.255.255      192.168.1.1    192.168.1.122     36
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
   172.17.114.176  255.255.255.240         On-link    172.17.114.177   5256
   172.17.114.177  255.255.255.255         On-link    172.17.114.177   5256
   172.17.114.191  255.255.255.255         On-link    172.17.114.177   5256
      192.168.1.0    255.255.255.0         On-link     192.168.1.122    291
    192.168.1.122  255.255.255.255         On-link     192.168.1.122    291
    192.168.1.255  255.255.255.255         On-link     192.168.1.122    291
     192.168.10.0    255.255.255.0      192.168.1.1     192.168.10.3     26
     192.168.10.3  255.255.255.255         On-link      192.168.10.3    281
   192.168.164.80  255.255.255.240         On-link    192.168.164.81   5256
   192.168.164.81  255.255.255.255         On-link    192.168.164.81   5256
   192.168.164.95  255.255.255.255         On-link    192.168.164.81   5256
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link     192.168.1.122    291
        224.0.0.0        240.0.0.0         On-link    172.17.114.177   5256
        224.0.0.0        240.0.0.0         On-link    192.168.164.81   5256
        224.0.0.0        240.0.0.0         On-link      192.168.10.3    281
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link     192.168.1.122    291
  255.255.255.255  255.255.255.255         On-link    172.17.114.177   5256
  255.255.255.255  255.255.255.255         On-link    192.168.164.81   5256
  255.255.255.255  255.255.255.255         On-link      192.168.10.3    281

Наверное надо добавить какой-то маршрут, но ума не приложу какой. Подскажете?

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

Докопался таки до сути. Дело не в роуминге.

Напомню адреса: 45.33.50.110 - порт-чекер где-то в интернете
12.123.123.123 - внешний роутера
192.168.1.122 - Windows в LAN
192.168.10.3 - Windows в VPN
192.168.1.31 - Linux в LAN
192.168.10.2 - Linux в VPN

Вот tcpdump c клиентом Windows

00:36:10.569852 IP (tos 0x28, ttl 50, id 10590, offset 0, flags [DF], proto TCP (6), length 60)
    45.33.50.110.35912 > 192.168.10.3.8080: Flags [S], cksum 0x5e5f (correct), seq 3013193090, win 64240, options [mss 1460,sackOK,TS val 3155946171 ecr 0,nop,wscale 7], length 0
00:36:10.569977 IP (tos 0x0, ttl 64, id 45989, offset 0, flags [none], proto GRE (47), length 104)
    12.123.123.123 > 192.168.1.122: GREv1, Flags [key present, sequence# present, ack present], call 6281, seq 440, ack 410, length 84
        compressed PPP data
00:00:00.142699 IP (tos 0x0, ttl 128, id 62710, offset 0, flags [none], proto GRE (47), length 32)
    192.168.1.122 > 12.123.123.123: GREv1, Flags [key present, ack present], call 21, ack 440, no-payload, length 12

А вот tcpdump с Linux

00:40:29.440387 IP (tos 0x28, ttl 50, id 57033, offset 0, flags [DF], proto TCP (6), length 60)
    45.33.50.110.35828 > 192.168.10.2.8080: Flags [S], cksum 0x6e5c (correct), seq 1651833791, win 64240, options [mss 1460,sackOK,TS val 3156205047 ecr 0,nop,wscale 7], length 0
00:40:29.440515 IP (tos 0x0, ttl 64, id 27678, offset 0, flags [none], proto GRE (47), length 104)
    12.123.123.123 > 192.168.1.31: GREv1, Flags [key present, sequence# present, ack present], call 38811, seq 2464, ack 2208, length 84
        compressed PPP data
00:40:29.551717 IP (tos 0x0, ttl 64, id 11655, offset 0, flags [DF], proto GRE (47), length 100)
    192.168.1.31 > 12.123.123.123: GREv1, Flags [key present, sequence# present], call 22, seq 2209, length 80
        compressed PPP data
00:40:29.551887 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.2.8080 > 45.33.50.110.35828: Flags [S.], cksum 0x5260 (correct), seq 1900259203, ack 1651833792, win 65535, options [mss 1356,sackOK,TS val 7011857 ecr 3156205047,nop,wscale 8], length 0

То есть Windows в ответ на туннелированный SYN отвечает пустым GRE пакетом! Это баг VPN сервера винды или допустимый пакет? Что с этим можно сделать?

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

баг VPN сервера винды

После того как уже установившая соединение клиентская венда(и не одна) периодически слала на сервер ICMP protocol 47 unreacheable, которое вендовый PPTP-сервер ИГНОРИРУЕТ(!), а линуксовый послушно разрывает соединение(«лечится» дропом пакетов icmp protocol unreachable, ага) - я уже давно не ищу логики в работе вендового PPTP.

Microsoft впрочем тоже шлет всех нах^W на SSTP, так что если у тебя там немного клиентов - стоит задуматься, камон, 2k21 год на дворе, а у тебя VPN без шифрования(ты же не считаешь MPPE адекватным шифрованием, правда?)

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

Есть-то он есть, но я его вживую в продакшене нигде не видел. К тому же, как уже говорилось, шифрование - не единственная проблема PPTP

Update: к слову, EAP-TLS - это про нормальную аутентификацию, в качестве шифрования там всё тот же дуршлаг-MPPE

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.