Страница 1 из 1

MPD5 pppoe client + ipfw

Добавлено: 2014-06-09 14:01:48
Kaspian
Привет,

Есть роутер

Код: Выделить всё

FreeBSD bender.xz.local 9.1-RELEASE-p15 FreeBSD 9.1-RELEASE-p15 #19 r267242: Mon Jun  9 00:49:16 EEST 2014     root@bender.xz.local:/usr/obj/usr/src/sys/XZ9  i386
Сейчас подключён к провайдеру с помощью mpd5 PPTP client + ipfw kernel nat = всё работает отлично. Как на самом роутере так и на клиентах в локальной сети интернет работает отлично.

Но провайдер начал переход на pppoe - казалось бы всё просто, меняем немного настройки MPD и проблем быть не должно - но они есть:
- На клиентах в локальной сети не достпны некоторые сайты, например speedtest.net, хотя некоторые открываются нормально.
- На самом роутере всё работает нормально, в целях эксперимента на роутере поднял прокси и в клиентах указываю ходить через него - тоже всё в порядке.
- Пинг проходит от клиентов куда угодно, даже на тот-же speedtest.net

Ниже конфиги:

mpd.conf

Код: Выделить всё

startup:

default:
   load pppoe_client

pppoe_client:
  create bundle static B1
  set iface route default
  set iface name briz_vpn
  set iface disable on-demand
  set iface idle 0
  set iface tcpmssfix

  set ipcp ranges 0.0.0.0/0 0.0.0.0/0

  create link static L1 pppoe
  set link action bundle B1
  set auth authname kasp*****
  set auth password ************
  set link max-redial 0
  set link mtu 1460
  set link keep-alive 10 60
  set pppoe iface re0
  set pppoe service ""
  open
Думал проблема в моём конфиге ipfw - но проблема даже если включить стандартный OPEN
rc.conf

Код: Выделить всё

firewall_enable="YES"
firewall_nat_enable="YES"
firewall_type="OPEN"
firewall_nat_interface="briz_vpn"
firewall_logging="YES"
ipfw show

Код: Выделить всё

00050 48852 36470070 nat 123 ip4 from any to any via briz_vpn
00100   272    33386 allow ip from any to any via lo0
00200     0        0 deny ip from any to 127.0.0.0/8
00300     0        0 deny ip from 127.0.0.0/8 to any
00400     0        0 deny ip from any to ::1
00500     0        0 deny ip from ::1 to any
00600     0        0 allow ipv6-icmp from :: to ff02::/16
00700     0        0 allow ipv6-icmp from fe80::/10 to fe80::/10
00800     0        0 allow ipv6-icmp from fe80::/10 to ff02::/16
00900     0        0 allow ipv6-icmp from any to any ip6 icmp6types 1
01000     0        0 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
65000 42504 38145005 allow ip from any to any
65535   433    51761 deny ip from any to any


Win клиент в сети:

Код: Выделить всё

C:\WINDOWS\system32>ping www.speedtest.net

Pinging cs62.adn.edgecastcdn.net [93.184.219.82] with 32 bytes of data:
Reply from 93.184.219.82: bytes=32 time=40ms TTL=59
Reply from 93.184.219.82: bytes=32 time=40ms TTL=59
Reply from 93.184.219.82: bytes=32 time=40ms TTL=59
Reply from 93.184.219.82: bytes=32 time=40ms TTL=59

Ping statistics for 93.184.219.82:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 40ms, Maximum = 40ms, Average = 40ms

Пример когда нет ответа на http запрос

Код: Выделить всё

C:\WINDOWS\system32>d:\bin\curl.exe -vL www.speedtest.net
* Rebuilt URL to: www.speedtest.net/
* Hostname was NOT found in DNS cache
*   Trying 93.184.219.82...
* Connected to www.speedtest.net (93.184.219.82) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.37.0
> Host: www.speedtest.net
> Accept: */*
>
^C
Вот пример когда всё нормально:

Код: Выделить всё

C:\WINDOWS\system32>d:\bin\curl.exe -vL ya.ru
* Rebuilt URL to: ya.ru/
* Hostname was NOT found in DNS cache
*   Trying 213.180.204.3...
* Connected to ya.ru (213.180.204.3) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.37.0
> Host: ya.ru
> Accept: */*
>
< HTTP/1.1 200 Ok
* Server nginx is not blacklisted
< Server: nginx
< Date: Mon, 09 Jun 2014 10:56:09 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 8224
< Connection: close
< Cache-Control: no-cache,no-store,max-age=0,must-revalidate
< Expires: Mon, 09 Jun 2014 10:56:10 GMT
< Last-Modified: Mon, 09 Jun 2014 10:56:10 GMT
< P3P: policyref="/w3c/p3p.xml", CP="NON DSP ADM DEV PSD IVDo OUR IND STP PHY PR
E NAV UNI"
< Set-Cookie: yandexuid=395205381402311370; Expires=Thu, 06-Jun-2024 10:56:09 GM
T; Domain=.ya.ru; Path=/
< X-Frame-Options: DENY
< X-XRDS-Location: http://openid.yandex.ru/server_xrds/
<
<!DOCTYPE html><html lang="ru">...
Я конечно понимаю что вариантов море, начиная от перехода на ppp\pf\natd до попытаться обновится до 10 - но хотелось бы разрулить как есть, т.к. однажды из-за проблем ppptp + pf уже пришлось переходить на ipfw :)
Может у кого есть идеи ?

Re: MPD5 pppoe client + ipfw

Добавлено: 2014-06-09 16:58:20
Kaspian
Т.к. выдалось свободное время попробовал заменить ipfw на pf - проблема осталась.
Заменил mpd на ppp - полёт нормальный

:(

Re: MPD5 pppoe client + ipfw

Добавлено: 2014-06-10 11:15:06
Dmitriy_3206
Почти уверен - фрагментация пакетов.
ICMP type=3, code=4
в MPD не разбираюсь и доки русифицированной не нашел, а иностранную не читал, но тыкаю пальцем в опции:

Код: Выделить всё

 set iface enable tcpmssfix
У Вас без enable
Ну и разрешить файрволу входящие ICMP (для начала все)

Смысл что сайт (или кто то на маршруте) возвращает ICMP сообщение что ожидает пакеты меньшего размера. Шлюз его режет, и клиент за шлюзом тупо ждет...... При чем интересно иногда получается, что часть сайта работает, а часть не работает.

Re: MPD5 pppoe client + ipfw

Добавлено: 2014-06-15 11:38:08
Kaspian
Dmitriy_3206, спасибо огромное - это действительно решило проблему.
Что самое удивительное для pptp эта опция у меня прописана, но для pppoe почему-то была добавлена как "set iface tcpmssfix" - на что mpd выдавал warning нет такого - и я её просто убрал посчитав что её больше нет (исчезла при переходе от версии 4 к 5). А всё оказалось так просто :)

Re: MPD5 pppoe client + ipfw

Добавлено: 2014-10-13 16:09:49
Dmitriy_3206
Вот спустя 4ре месяца, при смене провайдера я сам наступил на эти же грабли :) но у меня все интересней было:
Клиенты подключенные по "шнурку" отлично работали (кроме одного)
Клиенты подключенные по Wifi разделились на два лагеря, люди со "стокгольмским" синдромом (афоноводы) работали не заметив проблемы (скорее всего ios сам подбирает mtu mru и нащупав работает). А вот дроидо владельцы получали "правильные" симптомы - часть сайтов работает часть нет.

set iface enable tcpmssfix решило проблему