Здравствуйте,
Симптомы следующие:
- Система FreeBSD 7.2
- Стоит quagga
- настравивал не Я
- 2 сетевые 1.1.1.1 - внешний 2.2.2.2 - внутреннийВопрос в следующем:
Я нахожусь в локальной сети (т.е. мой шнур втыкнут в 2.2.2.2)
Если я посылаю запрос на адрес 1.1.1.1 то отвечает мне с адреса 2.2.2.2
1. Это в ПРИНЦЫПЕ правильное построение или нет? Так как тот же openvpn клиент шибко матюкается на такое поведение и требует установки дополнительных опций в конфигурацию что подхватывать эти ответы.
2. Как это лечить
>[оверквотинг удален]
> - настравивал не Я
> - 2 сетевые 1.1.1.1 - внешний 2.2.2.2 - внутренний
> Вопрос в следующем:
> Я нахожусь в локальной сети (т.е. мой шнур втыкнут в 2.2.2.2)
> Если я посылаю запрос на адрес 1.1.1.1 то отвечает мне с адреса
> 2.2.2.2
> 1. Это в ПРИНЦЫПЕ правильное построение или нет? Так как тот же
> openvpn клиент шибко матюкается на такое поведение и требует установки дополнительных
> опций в конфигурацию что подхватывать эти ответы.
> 2. Как это лечитьне правильно.
возможно пакеты под nat попадают
> не правильно.
> возможно пакеты под nat попадаютКак это можно проверить
>> не правильно.
>> возможно пакеты под nat попадают
> Как это можно проверитьсмотреть конфиги, следить за счетчиками правил
А Можно какието более конкретные примеры.
Дополнитальная информацыя: НАТ есть, построен на PF
где-то так:external_addr="1.1.1.1"
ext_if="vlan5"
table <internal_net> persist {..........., 2.2.2.2}
set optimization normal
set limit table-entries 600000.
nat on $ext_if from <internal_net> to any -> ($ext_if)
Но по ходу по єтому правилу никто не ходит:
[ Evaluations: 60375 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 31689 ]Это не может быть связанно с quagg-ой и её неправильной настройкой
>[оверквотинг удален]
> table <internal_net> persist {..........., 2.2.2.2}
> set optimization normal
> set limit table-entries 600000.
> nat on $ext_if from <internal_net> to any -> ($ext_if)
> Но по ходу по єтому правилу никто не ходит:
> [ Evaluations: 60375 Packets: 0
> Bytes: 0
> States: 0
> ]
> [ Inserted: uid 0 pid 31689 ]с pf по идеи такого получится не должно было, тем более что для nat указан интерфейс. посмотрите не запущен ли ipfw.
запустите tcpdump на внутреннем интерфейсе.
pftop - наглядная штука для pf
> с pf по идеи такого получится не должно было, тем более что
> для nat указан интерфейс. посмотрите не запущен ли ipfw.
> запустите tcpdump на внутреннем интерфейсе.
> pftop - наглядная штука для pfipfw - стоит но там только allow\deny и все
tcpdump показывает тоже самое:
12:18:05.179328 IP 10.0.11.16.63183 > 1.1.1.1.1194: UDP, length 42
12:18:05.179489 IP 2.2.2.2.1194 > 10.0.11.16.63183: UDP, length 50Шас иду мониторить pftop-ом
.........
В нем нет ни одной записи связанной с openvpn (смотрел по порту 1194)
>> с pf по идеи такого получится не должно было, тем более что
>> для nat указан интерфейс. посмотрите не запущен ли ipfw.
>> запустите tcpdump на внутреннем интерфейсе.
>> pftop - наглядная штука для pf
> ipfw - стоит но там только allow\deny и все
> tcpdump показывает тоже самое:
> 12:18:05.179328 IP 10.0.11.16.63183 > 1.1.1.1.1194: UDP, length 42
> 12:18:05.179489 IP 2.2.2.2.1194 > 10.0.11.16.63183: UDP, length 50а если обращаться не к openvpn
> Шас иду мониторить pftop-ом
> .........
> В нем нет ни одной записи связанной с openvpn (смотрел по порту
> 1194)
telnet 1.1.1.1 80
на tcpdump показывает правильно
> telnet 1.1.1.1 80
> на tcpdump показывает правильното есть ответ от 1.1.1.1 отправляет?
а неправильный адрес только при обращении к openvpn? если да, то что у него в конфиге
>> telnet 1.1.1.1 80
>> на tcpdump показывает правильно
> то есть ответ от 1.1.1.1 отправляет?
> а неправильный адрес только при обращении к openvpn? если да, то что
> у него в конфигеserver.conf:
port 1194
proto udp
dev tap
tls-server
tls-auth ta.key 0
ca /etc/ssl/crts/rootCA.crt
cert /etc/ssl/openvpn_serv.crt
key /etc/ssl/openvpn_serv.key # This file should be kept secret
comp-lzo
dh dh1024.pem
server 10.67.33.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 120
cipher DES-EDE3-CBC
#log openvpn_serv.log
#log-append openvpn_serv.log
#verb 3
>[оверквотинг удален]
> comp-lzo
> dh dh1024.pem
> server 10.67.33.0 255.255.255.0
> ifconfig-pool-persist ipp.txt
> client-to-client
> keepalive 10 120
> cipher DES-EDE3-CBC
> #log openvpn_serv.log
> #log-append openvpn_serv.log
> #verb 3или используйте proto tcp, или обращайтесь на внутренний ip
Да пошло спасибо
> или используйте proto tcp, или обращайтесь на внутренний ip
> Это не может быть связанно с quagg-ой и её неправильной настройкойэто относится к маршрутизации и на заголовки пакетов влиять не должно
Это известная проблема openvpn и freebsd. Не знаю как сейчас дела обстоят на фряхе, но на линухе это лечится указанием опции multihome в конфиге openvpn. Появилась начиная с 2.1 кажетсяЛибо как вариант создавать несколько кинфигов openvpn и в каждом явно привязывать его к необходимому интерфейсу.
> Это известная проблема openvpn и freebsd. Не знаю как сейчас дела обстоят
> на фряхе, но на линухе это лечится указанием опции multihome в
> конфиге openvpn. Появилась начиная с 2.1 кажется
> Либо как вариант создавать несколько кинфигов openvpn и в каждом явно привязывать
> его к необходимому интерфейсу.Именно. multihome во фре не работает. решение - только несколько конфигов. Вот мой пример:
http://www.mahno.su/freebsd/network/openvpn-tcp-udp