Здравствуйте. Я понимаю, что может задаю вопрос из разряда FAQ, но ответа самостоятельно найти не смог.
Конфигурация такая: FreeBSD 6.2, две сетевые карты. rl0 смотрит в мою сеть (10.1.0.0:255.255.255.0), rl1 - в сеть провайдера (192.168.2.1.0:255.255.255.0), через rl1 есть PPPoE соединение, через которое собственно и раздается интернет. Обе мои машины нормально видят и интернет, и провайдерскую сеть тех пор, пока есть PPPoE соединение. Если пропадает PPPoE соединение, провайдерская сеть тоже исчезает из виду, хотя шлюз продолжает ее видеть. ipfw show показывает нулевые счетчики для первого правила из rc.fw и наращивает счетчики для второго при попытке обратится к провайдерской сетке. Вопрос собственно, почему возникает описанная ситуация и как с ней бороться?---------------------
rc.conf:
---------------------
natd_enable="YES"
natd_interface="rl1"
firewall_enable="YES"
firewall_script="/etc/rc.fw"
defaultrouter="192.168.2.1"ppp_enable="YES"
ppp_mode="ddial"
ppp_nat="YES"
ppp_profile="homelan"gateway_enable="YES"
---------------------
rc.fw:
---------------------
#!/bin/sh
ipfw='/sbin/ipfw -q'${ipfw} -f flush
${ipfw} add divert natd all from 10.1.0.0:255.255.255.0 to 192.168.2.0:255.255.255.0 via rl1
${ipfw} add allow all from any to any
>[оверквотинг удален]
>самостоятельно найти не смог.
>Конфигурация такая: FreeBSD 6.2, две сетевые карты. rl0 смотрит в мою сеть
>(10.1.0.0:255.255.255.0), rl1 - в сеть провайдера (192.168.2.1.0:255.255.255.0), через rl1 есть PPPoE
>соединение, через которое собственно и раздается интернет. Обе мои машины нормально
>видят и интернет, и провайдерскую сеть тех пор, пока есть PPPoE
>соединение. Если пропадает PPPoE соединение, провайдерская сеть тоже исчезает из виду,
>хотя шлюз продолжает ее видеть. ipfw show показывает нулевые счетчики для
>первого правила из rc.fw и наращивает счетчики для второго при попытке
>обратится к провайдерской сетке. Вопрос собственно, почему возникает описанная ситуация и
>как с ней бороться?Потому-что, по-видимому, вы недавно пользовались iptables, и хотите по его принципу сделать тут. Но ipfw - это не айпитаблесы, тут другая тема.
Пакет должен заворачиваться на натд как "в ту", так и "в обратную" стороны.
Не хватает правила вида:ipfw add dvert natd all from any to <rl1_natd_ip> in via rl1
ну и первое правило тоже надо подточить, чтобы применялось только к исходящим пакетам.
firewall_type="OPEN"
>Потому-что, по-видимому, вы недавно пользовались iptables, и хотите по его принципу сделать
>тут.Я на FreeBSD пересел совсем недавно с Win2000+WinRoute попричине тормознутости данной связки как шлюза, так и сервера печати.
>Пакет должен заворачиваться на натд как "в ту", так и "в обратную"
>стороны.Хорошо, тогда почему при живом PPPoE соединении все работает?
>ipfw add dvert natd all from any to <rl1_natd_ip> in via rl1
Завтра попаду домой - попробую.
По поводу mpd я чего-то не понял, зачем он мне, если в pppd есть nat?
Nat на rl1 нужен, шлюз смотрит в три сети: мою, провайдера и интернет. Или я чего-то непонял?
>>Потому-что, по-видимому, вы недавно пользовались iptables, и хотите по его принципу сделать
>>тут.
>
>Я на FreeBSD пересел совсем недавно с Win2000+WinRoute попричине тормознутости данной связки
>как шлюза, так и сервера печати.
>
>>Пакет должен заворачиваться на натд как "в ту", так и "в обратную"
>>стороны.
>
>Хорошо, тогда почему при живом PPPoE соединении все работает?ppp_nat="YES" - обратите внимание на эту опцию.
>
>>ipfw add dvert natd all from any to <rl1_natd_ip> in via rl1
>
>Завтра попаду домой - попробую.
>
>По поводу mpd я чего-то не понял, зачем он мне, если в
>pppd есть nat?Netgraph - это ядерный функционал, должен работать быстрее/эффективнее за счет того что код работает на уровне ядра.
>Nat на rl1 нужен, шлюз смотрит в три сети: мою, провайдера и
>интернет. Или я чего-то непонял?Все верно.
>ppp_nat="YES" - обратите внимание на эту опцию.С этого места поподробнее, пожалуйста. В handbook написано: "PPP has ability to use internal NAT without kernel diverting capabilities." Как я понял нат у PPP собственный, отношения к natd не имеет.
>
>Netgraph - это ядерный функционал, должен работать быстрее/эффективнее за счет того что
>код работает на уровне ядра.Сам натить умеет или настраивать файрволом?
>>ppp_nat="YES" - обратите внимание на эту опцию.
>
>С этого места поподробнее, пожалуйста. В handbook написано: "PPP has ability to
>use internal NAT without kernel diverting capabilities." Как я понял нат
>у PPP собственный, отношения к natd не имеет.ну блин:
>Хорошо, тогда почему при живом PPPoE соединении все работает?
ppp_nat="YES" - обратите внимание на эту опцию.
+ локалка провайдера маршрутизируется через PPPoE, я уже писал об этом ниже.
>
>>
>>Netgraph - это ядерный функционал, должен работать быстрее/эффективнее за счет того что
>>код работает на уровне ядра.
>
>Сам натить умеет или настраивать файрволом?я не использую, точно сказать не могу, функционал нат (ng_nat) реализован совсем недавно.
Но, ИМХО, дополнительные настройки файрволла для реализации трансляции адресов при использовании MPD+ng_nat не требуются.
Если вы используете PPPoE, то вешать nat на rl1 как минимум глупо.вешайте на tun, что не столь коряво, либо пользуйте ppp_nat, а еще лучше отказаться от poptop. И PPPoE организовать через mpd. Тогда вы получите постоянный интерфейс, например ng0, на который смело можете вешать свой nat.
Еще лучше повесить оный на IP, хотя тоже такая себе шаткая система получиться, при условии что у вас динамически IP.
Проблема в том что у вас нат валиться как-только tun0 уходит в даун. Особенно если повторно ppp сессия открывается на tunN (N>0), а не tun0.
>Если вы используете PPPoE, то вешать nat на rl1 как минимум глупо.вешайте
>на tun, что не столь коряво, либо пользуйте ppp_nat,...
>Проблема в том что у вас нат валиться как-только tun0 уходит в даун. Особенно если
>повторно ppp сессия открывается на tunN (N>0), а не tun0.Вы бы в исходное сообщение заглянули повнимательнее, а ?
>а еще лучше отказаться от poptop. И PPPoE организовать через mpd. Тогда вы
>получите постоянный интерфейс, например ng0, на который смело можете вешать свой
>nat.
>Еще лучше повесить оный на IP, хотя тоже такая себе шаткая система
>получиться, при условии что у вас динамически IP.Если использовать мпд, то там есть встроенная поддержка ng_nat.
Можно нат вешать и на айпи, и никакой шаткости не будет, если использовать скрипты, вызываемые при установлении соединения.
>>Если вы используете PPPoE, то вешать nat на rl1 как минимум глупо.вешайте
>>на tun, что не столь коряво, либо пользуйте ppp_nat,
>
>...
>>Проблема в том что у вас нат валиться как-только tun0 уходит в даун. Особенно если
>>повторно ppp сессия открывается на tunN (N>0), а не tun0.
>
>Вы бы в исходное сообщение заглянули повнимательнее, а ?Цитирую: "Обе мои машины нормально видят и интернет, и провайдерскую сеть тех пор, пока есть PPPoE соединение. Если пропадает PPPoE соединение, провайдерская сеть тоже исчезает из виду, хотя шлюз продолжает ее видеть".
Что из мною перечисленного подпадает под категорию "Вы бы в исходное сообщение заглянули повнимательнее", и не соответствует действительности? Распишите дословно, а?
>
>>а еще лучше отказаться от poptop. И PPPoE организовать через mpd. Тогда вы
>>получите постоянный интерфейс, например ng0, на который смело можете вешать свой
>>nat.
>>Еще лучше повесить оный на IP, хотя тоже такая себе шаткая система
>>получиться, при условии что у вас динамически IP.
>
>Если использовать мпд, то там есть встроенная поддержка ng_nat.Не спорю.
>Можно нат вешать и на айпи, и никакой шаткости не будет, если
>использовать скрипты, вызываемые при установлении соединения.Можно и так, забыл про оные.
>[оверквотинг удален]
>>...
>>
>>Вы бы в исходное сообщение заглянули повнимательнее, а ?
>
>Цитирую: "Обе мои машины нормально видят и интернет, и провайдерскую сеть тех
>пор, пока есть PPPoE соединение. Если пропадает PPPoE соединение, провайдерская сеть
>тоже исчезает из виду, хотя шлюз продолжает ее видеть".
>
>Что из мною перечисленного подпадает под категорию "Вы бы в исходное сообщение
>заглянули повнимательнее", и не соответствует действительности? Распишите дословно, а?Цитирую и расписываю дословно:
ppp_enable="YES"
ppp_mode="ddial"
ppp_nat="YES"
^^^^^^^^^^^^^
ppp_profile="homelan"PPPoE натится отдельно, rl1 в локальную сеть провайдера натит отдельно. Вполне разумные желания натить свою локальную сеть как в интернет, так и к внешней локальной сети.
>>>Если вы используете PPPoE, то вешать nat на rl1 как минимум глупо.вешайте
>>>на tun, что не столь коряво, либо пользуйте ppp_nat,Так что (1) - глупости в этом нет, (2) ppp_nat уже используется.
>>>Проблема в том что у вас нат валиться как-только tun0 уходит в даун. Особенно если
>>>повторно ppp сессия открывается на tunN (N>0), а не tun0.Соответственно проблема не в этом. _Ситуация_ возникает из-за того, что нат валится как только тун0 уходит в даун, поскольку:
1. локалка провайдера также маршрутизируется через ПППоЕ соединение
2. Отсутствует указание (статический маршрут) маршрутизировать локалку провайдера через rl1
3. Некорректно настроен нат на rl1.Все вышеперечисленные пункты как раз и являются проблемами настройки маршрутизатора, при этом никак не важно, на каком tunN (N=0 или N>0) откроется PPPoE соединение.
>
>Не спорю.Я тоже не спорю, просто указал доп возможности.
>>Можно нат вешать и на айпи, и никакой шаткости не будет, если
>>использовать скрипты, вызываемые при установлении соединения.
>
>Можно и так, забыл про оные.