LINUX.ORG.RU
ФорумAdmin

OpenBSD роутер - не пускает на сайт


0

0

Здравствуйте.

Поставил дома на старый комп опен 4.4, в него воткнул несколько сетевушек:
rl0 смотрит во внутреннюю домашнюю сеть (192.168.1.0/24)
rl1 смотрит в районную сеть - нужна для пары локальных ресурсов (IP выделяется динамически из сети 10.0.55.0/24)
rl2 смотрит на adsl модем - основной выход в интернет
pppoe0 - на него создается pppoe-соединение

Настроил PPPoE-соединение, NAT, маршруты - интернет во внутренней сети работает.

sergey@gate:~ & sudo pfctl -s nat
nat on pppoe0 inet from 192.168.1.0/24 to any -> (pppoe0) round-robin
nat on pppoe0 inet from 192.168.2.0/24 to any -> (pppoe0) round-robin
sergey@gate:~ & route show -inet
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default ip78-36-32-1.onego UGS 4 34075 - 48 pppoe0
(ненужное опустил)
В принципе, интернет во внутренней сети есть. Заходит практически на все сайты, где бываю, кроме одного: battle.net. На него с обычного компа (Windows XP, звиняйте) не заходит. Очень долго пытается открыть страницу (больше получаса), не выводит никаких ошибок. Этот самый сайт с роутера (lynx) открывается нормально. Что примечательно, traceroute и с роутера, и с Windows XP нормально выходит за пределы роутера.

Подумалось мне, что это - проблема с MTU. Выставил mtu на rl2 в 1400, на pppoe0 стал 1392. Перезапуск интерфейсов с помощью sh -x /etc/netstart rl2 pppoe0 не принес желаемого результата.

Попробовал tcpdump'ом воспользоваться (хоть сам его не знаю). При запуске на интерфейсе pppoe0 выводит среди всего прочего следующее:
при заходе с Windows XP:
14:45:09.678836 cerber.drevlanka.ru.microsoft-ds > nifnif.drevlanka.ru.2640: R 0:0(0) ack 3943690163 win 0 (DF)
14:45:11.041311 ip78-36-37-57.onego.ru.50489 > battlenet.fr.www: S 2306317242:2306317242(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
при заходе с роутера:
14:48:18.840780 ip78-36-37-57.onego.ru.39209 > battlenet.fr.www: S 965340513:965340513(0) win 16384 <mss 1452,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 198058670 0> (DF)
14:48:19.160860 battlenet.fr.www > ip78-36-37-57.onego.ru.39209: S 1597634117:1597634117(0) ack 965340514 win 17424 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)

можно заметить, что win отличаются, в первом случае они какие-то странные (0 и 65535).

Собственно, вопрос. Куда копать? Буду рад любым ссылкам. Если в гугль - то желательно с набором ключевых слов.


поможем, а как же. только будте человеком, выложите полностью диагностические логи: pf.conf целиком, netstat -rnf inet, ifconfig, tcpdump -ni rl0 при lynx battle.net с обычного компа.

пока что думаю вариантов много. очень вероятно, что проблема в states-handling.

да, и зачем тебе round-robin? у тебя там много айпишек? если да, то это немного меняет дело...

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

> pf.conf целиком
http://www.binpaste.com/v.php?id=fz2q5
в целом, там присутствует только NAT (определение макросов не считаю) и определение block-policy (drop).

> netstat -rnf inet

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 78.36.32.1 UGS 0 641 - 48 pppoe0
10.0.1/24 10.0.55.254 UGS 0 28 - 48 rl1
10.0.10/24 10.0.55.254 UGS 0 0 - 48 rl1
10.0.11/24 10.0.55.254 UGS 0 0 - 48 rl1
10.0.55/24 link#3 UC 1 0 - 48 rl1
10.0.55.43 127.0.0.1 UGHS 0 0 33204 48 lo0
10.0.55.254 00:13:21:c6:15:c7 UHLc 3 0 - 48 rl1
78.36.32.1 78.37.32.22 UH 1 0 - 48 pppoe0
127/8 127.0.0.1 UGRS 0 0 33204 48 lo0
127.0.0.1 127.0.0.1 UH 2 0 33204 48 lo0
192.168.1/24 link#2 UC 1 0 - 48 rl0
192.168.1.1 00:20:ed:6b:0e:77 UHLc 2 1384 - 48 rl0
192.168.2/24 link#1 UC 0 0 - 48 ath0
224/4 127.0.0.1 URS 0 0 33204 48 lo0

> ifconfig

http://www.binpaste.com/v.php?id=wdsbc

> tcpdump -ni rl0 при lynx battle.net с обычного компа.

lynx отсутствует, использовал Opera :)

sergey@gate:~ & sudo tcpdump -ni rl0 -w out.log
tcpdump: listening on rl0, link-type EN10MB
^C
15 packets received by filter
0 packets dropped by kernel
sergey@gate:~ & sudo tcpdump -nr out.log
12:01:42.828055 192.168.1.254.22 > 192.168.1.1.1032: P 1515238330:1515238414(84) ack 4184553053 win 17520 (DF) [tos 0x10]
12:01:42.828573 192.168.1.254.22 > 192.168.1.1.1032: P 84:136(52) ack 1 win 17520 (DF) [tos 0x10]
12:01:42.828855 192.168.1.1.1032 > 192.168.1.254.22: . ack 136 win 65035 (DF)
12:01:42.829190 192.168.1.1.1032 > 192.168.1.254.22: P 1:53(52) ack 136 win 65035 (DF)
12:01:42.829594 192.168.1.1.1032 > 192.168.1.254.22: P 53:105(52) ack 136 win 65035 (DF)
12:01:42.829714 192.168.1.254.22 > 192.168.1.1.1032: . ack 105 win 17468 (DF) [tos 0x10]
12:01:44.467120 192.168.1.1.1087 > 216.148.223.71.80: S 1943502202:1943502202(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
12:01:44.692759 216.148.223.71.80 > 192.168.1.1.1087: S 2481018847:2481018847(0) ack 1943502203 win 17520 <mss 1460,nop,nop,sackOK> (DF)
12:01:44.693066 192.168.1.1.1087 > 216.148.223.71.80: . ack 1 win 65535 (DF)
12:01:44.693907 192.168.1.1.1087 > 216.148.223.71.80: P 1:315(314) ack 1 win 65535 (DF)
12:01:45.089973 216.148.223.71.80 > 192.168.1.1.1087: . ack 315 win 17206 (DF)
12:01:45.090244 192.168.1.1.1087 > 216.148.223.71.80: P 315:609(294) ack 1 win 65535 (DF)
12:01:45.321214 216.148.223.71.80 > 192.168.1.1.1087: P 1:132(131) ack 609 win 16912 (DF)
12:01:45.502494 192.168.1.1.1087 > 216.148.223.71.80: . ack 132 win 65404 (DF)

Возможно, это важно - не уверен. При загрузке компа rl1 получает адрес динамически, переписывая при этом таблицу маршрутов (выставляет default route). Я после загрузки (пока что вручную) меняю маршруты и применяю правила файрвола простым скриптом:

#!/bin/sh

adsl_ip=`ifconfig pppoe0 | grep "inet " | sed "s/.*--> \(.\{7,15\}\) .*/\1/"`
cl_gate=` ifconfig rl1 | grep broadcast | sed "s/.*broadcast \(.*\)\..*$/\1/"`".254"

route delete default
route add 10.0.1/24 $cl_gate
route add 10.0.10/24 $cl_gate
route add 10.0.11/24 $cl_gate
route add default $adsl_ip

pfctl -f /etc/pf.conf.progress

> да, и зачем тебе round-robin? у тебя там много айпишек? если да, то это немного меняет дело...


Как я понимаю, это по-умолчанию. Сам не выставлял round-robin. Устройств (и ИП) предполагается немного, не более 10ти.

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

все таки, в первую очередь нужен пф.конф и полный тцпдамп, желательно на рл0 и пппое0. по тому что имеется:

> 14:45:09.678836 cerber.drevlanka.ru.microsoft-ds > nifnif.drevlanka.ru.2640: R 0:0(0) ack 3943690163 win 0 (DF)

ресет на соединении фиг знает кого с кем. (чтобы было понятно, нужны или ваши имена, или ифконфиг и тцпдамп с ключем -н (предпочтительно)). в любом случае, к подключению к баттлнету это отношения не имеет.

> 14:45:11.041311 ip78-36-37-57.onego.ru.50489 > battlenet.fr.www: S 2306317242:2306317242(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)

самый обычный, полностью нормальный syn-сегмент. с окном все впорядке, это винда всегда так на емких каналах себя ведет, это не проблема. (modulate state вы не используете, вестимо). что пришло (или не пришло) в ответ на него, из вашего дампа не ясно =(. технологически, он абсолютно ничем серьезным не отличается от того, что шлет роутер.

> 14:48:18.840780 ip78-36-37-57.onego.ru.39209 > battlenet.fr.www: S 965340513:965340513(0) win 16384 <mss 1452,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 198058670 0> (DF) > 14:48:19.160860 battlenet.fr.www > ip78-36-37-57.onego.ru.39209: S 1597634117:1597634117(0) ack 965340514 win 17424 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)

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

val-amart ★★★★★
()
Ответ на: комментарий от ksv

по поводу перезаписи дефолтного маршрута из-за dhcp rl1, man 5 dhclient.conf

вкратце, надо не запрашивать routers

маршруты вручную можно добавлять из prepend/append или script. ведь дхцп клиент может работать не только при загрузке ;)

//дальше будет.. еще хорошо бы tcpdump и на pppoe0...

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

> еще хорошо бы tcpdump и на pppoe0

Одновременно с rl0 или можно разделенные по времени? Отдельно на PPPoE логи уже есть. К сожалению, сейчас на работе - получится их выложить только вечером (эти выложил забежав на обед домой).

> man 5 dhclient.conf

спасибо :) настройка системы в самом разгаре, буквально в конце прошлой недели настроил PPPoE на роутере, NAT и маршруты. Потом убил выходные на поиск хоть какой-то возможной причины неполадок с сайтом.

Если проблема совсем никак не решится - поставлю на роутер squid и сделаю прозрачное проксирование :)

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

так, значит. не знаю, что там было до этого, но теперь все соединение точно нормально работает. это видно тут:

[quote]
12:01:44.467120 192.168.1.1.1087 > 216.148.223.71.80: S 1943502202:1943502202(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
12:01:44.692759 216.148.223.71.80 > 192.168.1.1.1087: S 2481018847:2481018847(0) ack 1943502203 win 17520 <mss 1460,nop,nop,sackOK> (DF)
12:01:44.693066 192.168.1.1.1087 > 216.148.223.71.80: . ack 1 win 65535 (DF)
12:01:44.693907 192.168.1.1.1087 > 216.148.223.71.80: P 1:315(314) ack 1 win 65535 (DF)
12:01:45.089973 216.148.223.71.80 > 192.168.1.1.1087: . ack 315 win 17206 (DF)
12:01:45.090244 192.168.1.1.1087 > 216.148.223.71.80: P 315:609(294) ack 1 win 65535 (DF)
12:01:45.321214 216.148.223.71.80 > 192.168.1.1.1087: P 1:132(131) ack 609 win 16912 (DF)
12:01:45.502494 192.168.1.1.1087 > 216.148.223.71.80: . ack 132 win 65404 (DF)
[/quote]

здесь мы видим абсолютно нормальную установку соединения, и передачу каких-то данных. опера их однозначно получает, и отвечает на них. что она потом показывает, а хз, тебе виднее. кстати, это опять не все соединение ж)
с Опеном тут проблемы нет, это мы установили. чтобы расшифровать странное поведение Оперы, нужно видеть полностью всю http сессию. для этого либо поставь Wireshark на винду, сделаю захват и запость куда-то, либо прямо на Опене sudo tcpdump -ni rl0 -Xs 1500

val-amart ★★★★★
()
Ответ на: комментарий от ksv

всегда рад.
tcpdump -i pppoe0 уже не надо, там проблемы нет.
чем тебе так этот сайт сдался? или это не только с ним такое?
только что проверил, заходит на battle.net и с фокса, и с оперы и с винды и с линукса, все за опеновским роутером.

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

поскольку я подозреваю, что у них совсем не один сервер, зашел и по твоей айпишке тоже. что Опера тебе пишет?

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

> кстати, это опять не все соединение ж)

дык ... а то! я жду пару-тройку минут, потом жму ctrl-c в опене - прерываю лог tcpdump'а. Естественно, опера и не думает открывать страницу.

> поставь Wireshark на винду, сделаю захват и запость куда-то, либо прямо на Опене sudo tcpdump -ni rl0 -Xs 1500

попробую оба способа.

> чем тебе так этот сайт сдался? или это не только с ним такое?

Заметил только на нем. Хочу поправить, чтобы работало нормально. Мало ли еще обнаружатся криво работающие сайты.

> только что проверил, заходит на battle.net и с фокса, и с оперы и с винды и с линукса, все за опеновским роутером.

не сомневался :) Практически уверен, что проблемы с именно моей установкой. Потому как у меня как-то криво работал syslogc (syslogc -q не выводит никаких логов, хотя они должны быть - настраивал как минимум логирование ftpd), почему-то не работал пакет pcitools, в частности - lspci. В общем, вопросов много, а времени у меня мало, все до конца не донастроить, хоть что-нибудь хочется чтобы работало нормально. Осталось всего немного - squid (с работы в инет выходить, ибо там он меееедленный, надо только админов попросить доступ открыть до дому), samba (раздача в локальной сети файлов), torrent и выключение по нажатию кнопки питания :) и будет полное счастье :) Но это все - дело времени, сам потихоньку читаю маны / форумы и настраиваю (первый реальный опыт с опеном в частности и с настройкой роутера в целом).

> что Опера тебе пишет

Opera, как и IE (проверил просто - мало ли это opera-specific feature :)), не пишет _ничего_. Совсем ничего. Полчаса соединяется - все время виден прогресс, он на нуле. Никуда не двигается. После получаса ожидания терпение у меня пропадает :)

ksv
() автор топика
Ответ на: комментарий от val-amart

> с Опеном тут проблемы нет, это мы установили.

Спасибо за консультацию! Сам в tcpdump'е полный нуль - до такого уровня никогда не спускался, протоколы не реализовывал - изучал чисто теоретически и поверхностно.

> чтобы расшифровать странное поведение Оперы

вот здесь совсем не уверен, что только оперы. Опасаюсь, все браузеры на компе будут так шалить. Как минимум, шалят опера 9.60 и ослик 6й. Надо бы еще ФФ проверить. Как вариант еще - зайти на сайт с другого устройства (есть Nokia N810, wi-fi с НАТом на роутере уже настроен) - может, проблема именно в компе?

ksv
() автор топика
Ответ на: комментарий от val-amart

Завел N810, подключил сеть, зашел на сайт - та же ситуация: очень долго нет реакции браузера. Перед этим открыл гугль - все нормально.

Решил выложить лог tcpdump на ath0 - wifi интерфейс подключения N810 к роутеру. Думаю, разницы никакой.

sergey@gate:~ & sudo tcpdump -ni ath0 -Xs 1500 -w wifi.log
tcpdump: listening on ath0, link-type EN10MB
^C
104 packets received by filter
0 packets dropped by kernel
sergey@gate:~ & sudo tcpdump -nr wifi.log > wifi.dump
sergey@gate:~ & sudo tcpdump -nr wifi.log -Xs 1500 > wifi.dump

wifi.dump выложил на рапиду:
http://www.rapidshare.ru/868214
Попутно вычислил еще один "неработающий" сайт - ifolder.ru - полюбому надо чинить соединение :)

После запуска tcpdump'а открыл (попытался :) на N810 battle.net и отошел от компа минут на 15. Вернувшись нажал отмену в браузере, отключил сеть и только после этого прекратил выполнение tcpdump'а (-c ключ не использовал ибо не знаю, сколько пакетов ожидать).

Через некоторое время выложу логи Wideshark'а.

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

жаль, что ты выслал текстовые файлы, а не сами файлы дампов, мне было бы проще их анализировать(
тем не менее: по вайфай логу видно, что клиент подключился к серверу, получил от него favicon.ico (иконка сайта) и запросил от него корневую страницу. сервер ведет себя странно - он отправляет один большой кусок, а потом шлем мелкими кусочками по 12 байт. абсурд, учитывая, что ты открываешь нормальное окно на прием, никак не меньше одного mss-сегмента. и так продолжается 15 секунд, потом сервер шлет TCP reset. т.е. сервер по какой-то причине не может тебя обслужить.
по второму логу: подключились, отправили запрос, получили в ответ только заголовок хттп, никаких данных. клиент ждет данных ровно минуту, сервер ничего не шлет (а должен). потом клиент шлет Фин-Ак, заявку на разрыв (а что ему еще остается?).
непонятно, почему вы получаете от сервера такие странные результаты. особенно, если страничка нормально ГЕТиться с роутера...
у меня все нормально, отсылает по 2-3 куска размера мсс, как и положено...
значит, наверное стоит добавить
"
pass out
pass in log (all, to pflog2) on rl0 proto tcp to 216.148.223.71 port 80 modulate state
"
и посмотреть еще раз на роутере, теперь уже пфлог (пожалуйста, скиньте просто файл-дамп)

п.с. странно это все...

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

> посмотреть еще раз на роутере, теперь уже пфлог (пожалуйста, скиньте просто файл-дамп)

Прошу прощения за текстовые форматы - посчитал их удобнее.

Вечером помучаю pflog, появятся результаты - выложу и отпишусь.

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

Новый дамп: http://www.rapidshare.ru/869742

Мои манипуляции:
1. Добавил строчки
pass out
pass in log (all, to pflog2) on rl0 proto tcp to 216.148.223.71 port 80 modulate state
в конец pflog.conf.progress

2. Создал интерфейс pflog2
ifconfig pflog2 create ; ifconfig pflog2 up

3. Применил изменения pf.conf
pfctl -f /etc/pf.conf.progress

4. Запустил новый экземпляр pflogd
sudo pflogd -s 1500 -i pflog2 -f /var/log/pflog2

5. В браузере открыл баттл.нет, подождал минут 20, нажал отмену. Подождал минуту, слил /var/log/pflog2 на рапидшару.

ksv
() автор топика
Ответ на: комментарий от val-amart

http://ifolder.ru/9753079

Можно еще сливать с ftp://78.36.33.33/pub/incoming/pflog2 - ftp сервер на этом самом роутере. ИП не сменится до полуночи (МСК) точно, после полуночи может уйти в ребут / выключиться.

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

по этому логу видно, что соединение проходит, опера посылаеи запрос, сервер подтверждает прием запроса, но данных не посылает.

хз что это может быть... такое ощущение, что либо роутер не получает ответов от сервера, либо не роутит их клиенту (что совсем маловероятно, т.к. установка соединения проходит успешно, да и на другие сайты заходит). можно конечно еще посмотреть на лог с пппое0 при запросе с Оперы и с линкса с роутера. Вам, наверное, надоело уже давать мне диагностическую информацию, по которой я ничего дельного предложить не могу, сорри =(

может, стоит еще попробовать спросить в месте тусовки самых компетентных людей - в misc@openbsd.org

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

> можно конечно еще посмотреть на лог с пппое0 при запросе с Оперы и с линкса с роутера.

Думаю, я этим и займусь. Ручками, глазками ловя различия. Если что - гугль поможет :)

Спасибо за помощь и сочувствие!

> может, стоит еще попробовать спросить в месте тусовки самых компетентных людей - в misc@openbsd.org

Об этом думал, решил для начала на ЛОРе спросить :)

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

Помучал логи tcpdump'а - и не обнаружил ничего существенного. Да, конечно, логи отличаются, запросы на сервер разные. Но, боюсь, моя квалификация не позволяет мне судить о существенности отличий. К тому же, в последнее время все больше склоняюсь к мысли, что использование tcpdump'а для диагностики в моем случае - это примерно то же самое, что пытаться определить траекторию движения тела, измеряя энергии его молекул.

Завтра попробую задать вопрос в misc@openbsd.org. Что узнаю - отпишусь сюда.

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

к счастью, умные дядьки в миске не пропустили столь очевидный момент, что пропустил я. все дело в мту!
просто вы сказали, что меняли мту для интерфейса, ну вот я и не обратил внимания, что эти изменения-то имеют силу только для локально генерируемых пакетов. чтобы заставить пф насильно удалять пакеты с большим мту, чем это допустимо для вашего соединения, нужна строчка, которую вам посоветовали:
scrub out on $adsl_if all max-mss 1352
могу еще предложить небольшую корректировку - используйте 1352, если это то значение, которое установилось для пппое0 автоматом, а не вы сделали это вручную. если же это вы установили, то начинайте с max-mss 1492, и постепенно уменьшайте на 4, пока все не заработает.

ЗЫ. tcpdump - отличный инструмент, а я олух. там же наглядно видно было, что соединения устанавливаются с разным max-mss.

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

перечитал внимательно ваш первый пост. верните мту для рл2 в 1500, пппое0 сам должен откорректироваться (после перезапуска) в 1492. это же значение используйте для правила в пф.

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

Да, в misc@ сидят умные дядечки, у них глаз наметан уже :)

Вернул mtu на rl2 в 1500, на pppoe0 выставилась 1492. Но в pf.conf пришлось оставить значение max-mss 1440 - с большими значениями проблема не пропадает.

ksv
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.