Перейти до

Рекомендованные сообщения

Опубликовано: (відредаговано)

Шановні підкажіть - є така проблемка.

Є тачка з FreeBSD 9.3 x64 

FreeBSD 9.3-RELEASE FreeBSD 9.3-RELEASE #0 r268512: Thu Jul 10 23:44:39 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

На ній підняті фаєр,днс (бінд), дхцп сервер, апач, усе працює нормально, але для певної діагностики потрібно підняти пптп сервер - ну то не в перше для мене, конфіг доволі стандартний в мпд

startup:
        set user admin admin
# configure the console
        set console self 127.0.0.1 5005
        set console open
# configure the web server
        set web self 127.0.0.1 5006
        set web open

default:
        load pptp_server
pptp_server:
        set ippool add pool1 10.10.10.5 10.10.10.250
        create bundle template B1
        set iface disable proxy-arp
        set iface idle 0
        set iface enable tcpmssfix
        set ipcp yes vjcomp
        set ipcp ranges 172.16.1.1 ippool pool1
        set ipcp dns 10.0.0.1 
#Enable Microsoft Point-to-Point encryption (MPPE)
        set bundle enable compression
        set ccp yes mppc
        set mppc yes e40
        set mppc yes e56
        set mppc yes e128
        set mppc yes stateless
        set mppc yes compress
# Create clonable link template named L
        create link template L10 pptp
# Set bundle template to use
        set link action bundle B1
# Multilink adds some overhead, but gives full 1500 MTU
        set link enable multilink
        set link yes acfcomp protocomp
        set link no pap chap eap
        set link enable pap
        set link enable chap
        set link enable chap-msv1
        set link enable chap-msv2
# We reducing link mtu to avoid GRE packet fragmentation.
        set link mtu 1460
        set link keep-alive 10 60

# Configure PPTP and open link
        set pptp self хх.хх.хх.хх
# Allow to accept calls
        set link enable incoming

Проблема в тому, що коли я з'єднуюсь із цим сервером - то вмирає нат, як би то дивно не було. Тобто усі сервіси працюють, маршрутизація працює, а от нат не хоче (ipfw nat). Лікується тільки ребутом системи.

В логах чисто - ядро не перезбирав, усе модулями завантажується.

Підкажіть, куди копати?

Відредаговано L1ght
Опубліковано: (відредаговано)

Я бы для начала упростил и сократил конфиг до минимума, просто чтоб глаза не ломать. Хотя пптп тут прямое отношение вряд-ли имеет.

"Нат перестаёт работать", т. е. до подключения пптп-клиента он кого-то натит (например эзернет или вилан), а после подключения перестаёт их-же натить? Т. е. со внешнего интерфейса пакеты начинают выходить неоттранслированными? Или по каким признаком проблема с натом диагностирована? Можно на конфиг ipfw или вывод list посмотреть, если не очень громоздкий?

Відредаговано bsdadm
Опубліковано:

дивлюся по ipfw show - просто по нат правилам перестають ходити пакети плюс повне падіння трафіку, що проходить через той компьютер.

це відноситься до всіх користувачів, що виходять в інтернет через ту машину - перезавантаження фаєру не допомогає, тільки повний ребут машини.

06000 nat 1 ip from table(10) to not table(9) out xmit igb0
06001 nat 1 ip from any to xx.xx.xx.xa in recv igb0
06002 nat 2 ip from 10.0.1.0/24 to not table(9) out xmit igb0
06003 nat 2 ip from any to xx.xx.xx.xb in recv igb0
06004 nat 3 ip from table(11) to not table(9) out xmit igb0
06005 nat 3 ip from any to xx.xx.xx.xc in recv igb0
06006 nat 4 ip from 10.0.0.0/24 to not table(9) out xmit igb0
06007 nat 4 ip from any to xx.xx.xx.xd in recv igb0
12000 pipe tablearg ip from table(3) to any via vlan20 in
12001 pipe tablearg ip from any to table(4) via vlan20 out
12002 pipe tablearg ip from any to table(4) via vlan21 out
12003 pipe tablearg ip from table(3) to any via vlan21 in
65535 allow ip from any to any
Опубліковано: (відредаговано)

Через какой интерфейс устанавливаете пптп-соединение? Он как-то связан с igb0? Адрес 172.16.1.1, указанный в конфиге мпд, попадает в приведённые таблицы файрвола или конфиги ната? А адрес из self хх.хх.хх.хх? Нат сконфигурирован как config ip? IP ната на каких-то интерфейсах имеются?

Можете показать вывод kldstat и ngctl list (или как там его)? Если есть возможность с этим сервером экспериментировать, то желательно в разных стадиях - при работающем нате и при неработающем.

Перезагрузку модуля ipfw или ipfw_nat перед повторным запуском файрвола не пробовали? Или убить экземпляр ната и сконфигурировать заново?

В таблице маршрутизации какие-нибудь хитрости применены или всё по умолчанию? Можете попробовать без set pptp self? С ним какие-то трудности были, но подробностей я уже не помню.

sysctl net.inet.ip.fw.one_pass какое значение имеет? Это весь конфиг ipfw или часть? Я правильно понял, что остановка мпд тоже не возвращает нату работоспособность?

Відредаговано bsdadm
Опубліковано:

Что пишет "sysctl net.inet.ip.forwarding" до и после соединения?

хм, интересно - надо поглядеть, но время на тесты только ночью, ибо сожрут х)

ещё варианты? :)

Опубліковано:

Тогда ещё добавить ipfw count на вход и на выход в нескольких местах на тестовую пару ип-адресов, между которыми запустить пинговалку. Чтоб локализовать в каком месте теряется. Ну и снифером посмотреть, ходит ли что-то и что конкретно.

Опубліковано:

Через какой интерфейс устанавливаете пптп-соединение? Он как-то связан с igb0? Адрес 172.16.1.1, указанный в конфиге мпд, попадает в приведённые таблицы файрвола или конфиги ната? А адрес из self хх.хх.хх.хх? Нат сконфигурирован как config ip? IP ната на каких-то интерфейсах имеются?

Можете показать вывод kldstat и ngctl list (или как там его)? Если есть возможность с этим сервером экспериментировать, то желательно в разных стадиях - при работающем нате и при неработающем.

Перезагрузку модуля ipfw или ipfw_nat перед повторным запуском файрвола не пробовали? Или убить экземпляр ната и сконфигурировать заново?

В таблице маршрутизации какие-нибудь хитрости применены или всё по умолчанию? Можете попробовать без set pptp self? С ним какие-то трудности были, но подробностей я уже не помню.

sysctl net.inet.ip.fw.one_pass какое значение имеет? Это весь конфиг ipfw или часть? Я правильно понял, что остановка мпд тоже не возвращает нату работоспособность?

Да именно через igb0, там висит порядка 5 адресов, на 4 из которых нат, нат конфигурирется так: ipfw nat 1 config ip xx.xx.xx.xx log deny_in.

172.16.1.0/24 есть в 11 таблице - т.е. попадает.

Как сказал выше - тесты только ночью ибо машина в бою.

Или убить экземпляр ната и сконфигурировать заново? - не помогает, как и перезагрузка фаера в целом.

С маршрутизацией всё стандартно - дефолт, да и всё.

без set pptp self - это по идее забиндит все доступные адреса?

net.inet.ip.fw.one_pass=1

Остановка\перезагрузка какого-либо сервиса или фаервола не меняет ситуацию до полного ребута машины.

Опубліковано:

Тогда ещё добавить ipfw count на вход и на выход в нескольких местах на тестовую пару ип-адресов, между которыми запустить пинговалку. Чтоб локализовать в каком месте теряется. Ну и снифером посмотреть, ходит ли что-то и что конкретно.

абонентский трафик приходит - т.к. меняются счетчики на правилах шейпа, вот мне пока больше всего нравится идея с net.inet.ip.forwarding = потому что трафик дальше не идет.

Опубліковано:

хм, интересно - надо поглядеть, но время на тесты только ночью, ибо сожрут х)

ещё варианты? :)

Предполагаю, что если в rc.conf отсутствует gateway_enable="YES" и net.inet.ip.forwarding включается только через sysctl.conf, то во время соединения происходит сброс net.inet.ip.forwarding в 0.

в 9.2 с этим точно были проблемы. по поводу 9.3 не знаю.

http://lists.freebsd.org/pipermail/freebsd-net/2013-October/037012.html

Опубліковано:

 

хм, интересно - надо поглядеть, но время на тесты только ночью, ибо сожрут х)

ещё варианты? :)

Предполагаю, что если в rc.conf отсутствует gateway_enable="YES" и net.inet.ip.forwarding включается только через sysctl.conf, то во время соединения происходит сброс net.inet.ip.forwarding в 0.

в 9.2 с этим точно были проблемы. по поводу 9.3 не знаю.

http://lists.freebsd.org/pipermail/freebsd-net/2013-October/037012.html

 

да, обычно ставлю gateway_enable="yes", но в этом случае он там отсутствует

#cat /etc/sysctl.conf

net.inet.ip.fw.one_pass=1 
net.inet.ip.fastforwarding=1 
net.inet.tcp.nolocaltimewait=1 
net.inet.ip.portrange.randomized=0
net.inet.ip.dummynet.io_fast=1
net.inet.ip.forwarding=1
Опубліковано: (відредаговано)

Предполагаю, что если в rc.conf отсутствует gateway_enable="YES" и net.inet.ip.forwarding включается только через sysctl.conf, то во время соединения происходит сброс net.inet.ip.forwarding в 0.

в 9.2 с этим точно были проблемы. по поводу 9.3 не знаю.

http://lists.freebsd.org/pipermail/freebsd-net/2013-October/037012.html

да, обычно ставлю gateway_enable="yes", но в этом случае он там отсутствует

При таком раскладе вероятность, что это сбрасывающийся форвардинг, стремится к бесконечности. Но тогда как понимать

усі сервіси працюють, маршрутизація працює

? Відредаговано bsdadm
Опубліковано:

 

Предполагаю, что если в rc.conf отсутствует gateway_enable="YES" и net.inet.ip.forwarding включается только через sysctl.conf, то во время соединения происходит сброс net.inet.ip.forwarding в 0.

в 9.2 с этим точно были проблемы. по поводу 9.3 не знаю.

http://lists.freebsd.org/pipermail/freebsd-net/2013-October/037012.html

да, обычно ставлю gateway_enable="yes", но в этом случае он там отсутствует

При таком раскладе вероятность, что это сбрасывающийся форвардинг, стремится к бесконечности. Но тогда как понимать

усі сервіси працюють, маршрутизація працює

?

 

Да, срасывался форвардинг, ну я почему-то убедил себя, что не работает именно нат, а с форвардингом всё ок, вот и выпалил так "с горяча".

Опубліковано: (відредаговано)

 

 

 

хм, интересно - надо поглядеть, но время на тесты только ночью, ибо сожрут х)

ещё варианты? :)

Предполагаю, что если в rc.conf отсутствует gateway_enable="YES" и net.inet.ip.forwarding включается только через sysctl.conf, то во время соединения происходит сброс net.inet.ip.forwarding в 0.

в 9.2 с этим точно были проблемы. по поводу 9.3 не знаю.

http://lists.freebsd.org/pipermail/freebsd-net/2013-October/037012.html

да, обычно ставлю gateway_enable="yes", но в этом случае он там отсутствует
#cat /etc/sysctl.conf

net.inet.ip.fw.one_pass=1 
net.inet.ip.fastforwarding=1 
net.inet.tcp.nolocaltimewait=1 
net.inet.ip.portrange.randomized=0
net.inet.ip.dummynet.io_fast=1
net.inet.ip.forwarding=1
И да - оно без gateway_enable в rc.conf иногда отлетает при дауне интерфейса, что с этими вашими рррое/пптп - норма. Відредаговано nightfly
Опубліковано:

Ну добавь просто gateway_enable и сделай рестарт нетворкинга. Должно быть ок. Это для юзеров пптп должен быть, или себе?

та то себе просто

Опубліковано:

Ну так взял бы юзерспейсный поптоп - его для себя как раз хватает. И да - он скорее всего тоже будет отстреливать форвардинг, по причине убиения интерфейсов.

 

ЗЫ а мпд - та еще сука :-Р

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
×
×
  • Створити нове...