Странная недоступность по второму интерфейсу в локалке

Настройка сетевых служб, маршрутизации, фаерволлов. Проблемы с сетевым оборудованием.
Правила форума
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
Dmitriy_K
сержант
Сообщения: 200
Зарегистрирован: 2009-04-07 6:22:33
Откуда: г.Королёв

Странная недоступность по второму интерфейсу в локалке

Непрочитанное сообщение Dmitriy_K » 2011-04-18 15:31:05

Случился такой неожиданно неразрешимый трабл. :oops:
В нашей локалке есть два сегмента (условно): обычный (10.0.0.0/8) и DMZ (10.48.112.0/24). Всё контролируется всякими ASA/ISA к которым я не имею отношения, и которыми криво рулят виндовые сетевики.
В локалке 10.0.0.0/8 (интерфейс "em1") стоит сервак FreeBSD с jail. По обстоятельствам, возникла необходимость сделать ещё одну jail, которую волевым решением безопасников ( :fool: ) заткнули в DMZ. При этом, новая jail должна была быть доступна из обычной локалки.
Чтобы это сделать, на второй интерфейс сервака "em0" кинули кабель в DMZ и дали пару IP (10.48.112.18, 10.48.112.19) с разрешениями траффика по нужным портам из локалки и ответного в неё (по крайней мере, так утверждали сетевики). Получилась, в принципе, простая схема, которая, вроде бы, должна работать, но не заработала. :pardon:
Траффик оказался односторонним: только из локалки в DMZ.

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

#tcpdump -n -i em0 'tcp[tcpflags] & tcp-syn != 0'
listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
11:42:24.979569 IP 10.48.34.75.49170 > 10.48.112.18.22: Flags [S], seq 2816365520, win 8192, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
11:42:27.976438 IP 10.48.34.75.49170 > 10.48.112.18.22: Flags [S], seq 2597498720, win 8192, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
11:42:33.982555 IP 10.48.34.75.49170 > 10.48.112.18.22: Flags [S], seq 3516789105, win 8192, options [mss 1380,nop,nop,sackOK], length 0
Никакие эксперименты с настройками сетевого роутинга сервера (проверялся и вариант с режимом гэйтвея (форвардинга)) ничего не дали.
Не заработал даже простейший вариант с назначением только IP 10.48.112.18 на "em0". Внутри DMZ коннекты на SSH проходили нормально, но из обычной локалки - ни в какую (см.выше).
Настройки такие:

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

#ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:1b:78:58:2c:c2
        inet 10.48.112.18 netmask 0xffffff00 broadcast 10.48.112.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:1b:78:58:2c:c3
        inet 10.48.33.12 netmask 0xffffff00 broadcast 10.48.33.255
        inet 10.48.33.13 netmask 0xffffffff broadcast 10.48.33.13
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000

#netstat -nr
Routing tables
Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            10.48.33.1         UGS        12    12567    em1
10.48.33.0/24      link#2             U           0       34    em1
10.48.33.12        link#2             UHS         0        0    lo0
10.48.33.13        link#2             UHS         0     2998    lo0 =>
10.48.33.13/32     link#2             U           0        0    em1
10.48.112.0/24     link#1             U           2       54    em0
10.48.112.18       link#1             UHS         0        0    lo0
127.0.0.1          link#3             UH          0        0    lo0

rc.conf
----------------
hostname="ns3"
ifconfig_em0="10.48.112.18 netmask 255.255.255.0"
#ifconfig_em0_alias0="inet 10.48.112.19 netmask 255.255.255.255"
ifconfig_em1="10.48.33.12 netmask 255.255.255.0"
ifconfig_em1_alias0="inet 10.48.33.13  netmask 255.255.255.255"

static_routes="net1"
#route_net1="-net 10.0.0.0/8 10.48.33.1"
route_net1="-net 10.48.112.0/24 10.48.112.1"
defaultrouter="10.48.33.1"     #Пробовал менять дефолт на роутер DMZ 10.48.112.1 - не помогло.

gateway_enable="NO"
При попытке разборок сделали эксперимент: создали виндовую виртуалку в DMZ c IP 10.48.112.18 - она оказалась доступна из обычной локалки по 22 порту.
Просьба подсказать, я чего-то не понимаю в этой жизни или это всё-таки трабл из-за неправильных настроек сетевиков? :crazy:

Хостинговая компания Host-Food.ru
Хостинг HostFood.ru
 

Услуги хостинговой компании Host-Food.ru

Хостинг HostFood.ru

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

Аватара пользователя
ADRE
майор
Сообщения: 2641
Зарегистрирован: 2007-07-26 8:53:49
Контактная информация:

Re: Странная недоступность по второму интерфейсу в локалке

Непрочитанное сообщение ADRE » 2011-04-18 15:38:17

Маршруты смотите, скорее всего в другую сетку по дефолтному роутеру отпускает, а не через нужный интерфейс.
//del

Dmitriy_K
сержант
Сообщения: 200
Зарегистрирован: 2009-04-07 6:22:33
Откуда: г.Королёв

Re: Странная недоступность по второму интерфейсу в локалке

Непрочитанное сообщение Dmitriy_K » 2011-04-18 18:58:44

Как именно смотреть? Я по-разному пытался.
У меня форвардинг запрещён. Ответный пакет, вроде, не должен при этом уходить через другой интерфейс.
Или может? Если да, то как это запретить?

sch
сержант
Сообщения: 282
Зарегистрирован: 2009-05-28 14:36:50
Откуда: Кишинев

Re: Странная недоступность по второму интерфейсу в локалке

Непрочитанное сообщение sch » 2011-04-18 22:33:04

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

Аватара пользователя
hizel
дядя поня
Сообщения: 9031
Зарегистрирован: 2007-06-29 10:05:02
Откуда: Выборг

Re: Странная недоступность по второму интерфейсу в локалке

Непрочитанное сообщение hizel » 2011-04-18 22:36:59

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

10.48.34.75.49170 > 10.48.112.18.22
тут что-то не так

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

route_net1="-net 10.48.112.0/24 10.48.112.1"

телепатирую изменение к виду:

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

route_net1="-net 10.48.34.0/24 10.48.112.1"
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн --- это Боль.

Dmitriy_K
сержант
Сообщения: 200
Зарегистрирован: 2009-04-07 6:22:33
Откуда: г.Королёв

Re: Странная недоступность по второму интерфейсу в локалке

Непрочитанное сообщение Dmitriy_K » 2011-04-19 9:32:58

hizel писал(а):

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

10.48.34.75.49170 > 10.48.112.18.22
Это, собственно, попытка осуществить требуемый доступ из обычной сети в DMZ. Это просто принципиальный тест дотупности, использоваться будут другие порты и сервисы.
тут что-то не так

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

route_net1="-net 10.48.112.0/24 10.48.112.1"
телепатирую изменение к виду:

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

route_net1="-net 10.48.34.0/24 10.48.112.1"
Общий смысл идеи понял, спасибо. Но роуты при этом, конечно, валятся, поскольку это назначение распространяется одновременно на два интерфейса, но интерфейс "em1" не может использовать роутер сети DMZ 10.48.112.1 для роутинга обычной сети 10.0.0.0/8.
Теперь, собственно, стала понятна ситуация. :(
Я предполагал, что роутер DMZ 10.48.112.1 будет как-то натить адреса в обычной сетке (я почти не работаю с местной локалкой и мне никто не объяснял как там что), но оказалось, что они передаются как есть. В принципе, я уже заранее пытался найти способ обойти эту проблему. Но она обходится только за счёт раздельного назначения роутов каждому интерфейсу. В Linux такое возможно, но для BSD я такого способа не обнаружил. Может, кто-то сможет подсказать? Или это принципиально невозможно?

Dmitriy_K
сержант
Сообщения: 200
Зарегистрирован: 2009-04-07 6:22:33
Откуда: г.Королёв

Re: Странная недоступность по второму интерфейсу в локалке

Непрочитанное сообщение Dmitriy_K » 2011-04-29 18:16:38

Как оказалось, на уровне простой маршрутизации вопрос не решается. Но его можно решить другим путём через Policy-Based Routing (PBR) с помощью файрволла. В моём случае помогла фича PF "reply-to":
http://house.hcn-strela.ru/BSDCert/BSDA ... #pf-filter
http://ipfw.ism.kiev.ua/pbr.html
http://www.lissyara.su/articles/freebsd ... =1&print=1
К большому сожалению, получается весьма запутанное разруливание, с которым мне пока не удалось справиться до конца. :(
Пока заработал только SSH (причём для него пришлось делить правила на две зоны). Попытка переноса такого же подхода на траффик по порту 21 успеха не принесла. Причём по дампингу обмен пакетами проходит в обе стороны нормально, авторизация тоже проходит. Но клиент FTP в локалке не получает ответа от сервера в DMZ (список директории не проходит и дальше вылет по пределу ожидания).

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

#tcpdump -nA -i em0 'host 10.48.112.19 and port 21'

16:42:59.576160 IP 10.48.34.75.55195 > 10.48.112.19.21: Flags [F.], seq 3845794686, ack 107339338, win 255, length 0
E..(D.@.....
0"K
0p......:+~.e.JP...:.........

16:42:59.576182 IP 10.48.112.19.21 > 10.48.34.75.55195: Flags [.], ack 1, win 8280, length 0
E..(..@.@..i
0p.
0"K.....e.J.:+.P. X....

16:43:04.664310 IP 10.48.34.75.55216 > 10.48.112.19.21: Flags [S], seq 1360132974, win 8192, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
E..4T)@.....
0"K
0p.....Q..n...... ..\.....d........

16:43:04.664368 IP 10.48.112.19.21 > 10.48.34.75.55216: Flags [S.], seq 1759184192, ack 1360132975, win 65535, options [mss 1380,nop,wscale 3,sackOK,eol], length 0
E..4..@.@...
0p.
0"K....h..@Q..o....76.....d........

16:43:04.664684 IP 10.48.34.75.55216 > 10.48.112.19.21: Flags [.], ack 1, win 258, length 0
E..(T*@.....
0"K
0p.....Q..oh..AP...u.........

16:43:04.666039 IP 10.48.112.19.21 > 10.48.34.75.55216: Flags [P.], ack 1, win 8280, length 265
E..1..@.@...
0p.
0"K....h..AQ..oP. X.`..220---------- Welcome to Pure-FTPd [privse

16:43:04.666559 IP 10.48.34.75.55216 > 10.48.112.19.21: Flags [P.], ack 266, win 257, length 12
E..4T+@.....
0"K
0p.....Q..oh..JP.......USER makar

16:43:04.666642 IP 10.48.112.19.21 > 10.48.34.75.55216: Flags [P.], ack 13, win 8280, length 38
E..N..@.@...
0p.
0"K....h..JQ..{P. X^...331 User makar OK. Password required

16:43:04.667058 IP 10.48.34.75.55216 > 10.48.112.19.21: Flags [P.], ack 304, win 257, length 19
E..;T,@.....
0"K
0p.....Q..{h..pP.......PASS **********

16:43:04.676687 IP 10.48.112.19.21 > 10.48.34.75.55216: Flags [P.], ack 32, win 8280, length 92
E.....@.@...
0p.
0"K....h..pQ...P. X.W..230-User makar has group access to:  nobod

16:43:04.677302 IP 10.48.34.75.55216 > 10.48.112.19.21: Flags [P.], ack 396, win 257, length 6
E...T-@.....
0"K
0p.....Q...h...P....B..SYST

16:43:04.677339 IP 10.48.112.19.21 > 10.48.34.75.55216: Flags [P.], ack 38, win 8280, length 19
E..;.   @.@...
0p.
0"K....h...Q...P. X.?..215 UNIX Type: L8

16:43:04.677801 IP 10.48.34.75.55216 > 10.48.112.19.21: Flags [P.], ack 415, win 257, length 6
E...T.@.....
0"K
0p.....Q...h...P....=..FEAT

16:43:04.677833 IP 10.48.112.19.21 > 10.48.34.75.55216: Flags [P.], ack 44, win 8280, length 226
E..
.
@.@...
0p.
0"K....h...Q...P. XX...211-Extensions supported:
 EPRT
 IDLE

16:43:04.678301 IP 10.48.34.75.55216 > 10.48.112.19.21: Flags [P.], ack 641, win 256, length 14
E..6T/@.....
0"K
0p.....Q...h...P....:..OPTS UTF8 ON

16:43:04.678331 IP 10.48.112.19.21 > 10.48.34.75.55216: Flags [P.], ack 58, win 8280, length 23
E..?..@.@...
0p.
0"K....h...Q...P. X....200 OK, UTF-8 enabled

16:43:04.702287 IP 10.48.34.75.55216 > 10.48.112.19.21: Flags [P.], ack 664, win 256, length 5
E..-TZ@.....
0"K
0p.....Q...h...P....q..PWD
.
16:43:04.702321 IP 10.48.112.19.21 > 10.48.34.75.55216: Flags [P.], ack 63, win 8280, length 34
E..J..@.@...
0p.
0"K....h...Q...P. X....257 "/" is your current location

16:43:04.703911 IP 10.48.34.75.55216 > 10.48.112.19.21: Flags [P.], ack 698, win 256, length 8
E..0T^@.....
0"K
0p.....Q...h...P.......TYPE A

16:43:04.703942 IP 10.48.112.19.21 > 10.48.34.75.55216: Flags [P.], ack 71, win 8280, length 23
@.@...
0p.
0"K....h...Q...P. X....200 TYPE is now ASCII

16:43:04.704536 IP 10.48.34.75.55216 > 10.48.112.19.21: Flags [P.], ack 721, win 255, length 6
E...T`@.....
0"K
0p.....Q...h...P.......PASV

16:43:04.704619 IP 10.48.112.19.21 > 10.48.34.75.55216: Flags [P.], ack 77, win 8280, length 49
E..Y..@.@...
0p.
0"K....h...Q...P. X....227 Entering Passive Mode (10,48,112,19,62

16:43:04.705035 IP 10.48.34.75.55216 > 10.48.112.19.21: Flags [P.], ack 770, win 255, length 6
E...Tb@.....
0"K
0p.....Q...h..BP.......LIST

16:43:04.805257 IP 10.48.112.19.21 > 10.48.34.75.55216: Flags [.], ack 83, win 8280, length 0
E..(..@.@...
0p.
0"K....h..BQ...P. XS...

16:43:20.245710 IP 10.48.34.75.55216 > 10.48.112.19.21: Flags [R.], seq 83, ack 770, win 0, length 0
E..(\.@.....
0"K
0p.....Q...h..BP...s\........
^C
Шаманил с этим много, но бестолку. Даже самый простой вариант при максимальных разрешениях и отсутствии блокировки траффика не проходит. :st:
Конфигурация PF пока такая (лишнее убрано):

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

 eface="em0"
 iface="em1"
 dmz_gw="10.48.112.1"
 dmz_main="10.48.112.18"
 dmz_jail="10.48.112.19"

 table <dmz_ssh_users>  { 10.48.112.15 } persist
 table <ssh_users>  { 10.48.34.75, 10.64.128.0/24 } persist
 table <ftp_users>  { 10.48.34.75, 10.64.128.0/24 } persist
 table <int_net>    { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 } persist

 set skip on lo0
 scrub in all

# Allow ssh connections
 pass  in  quick on $eface proto tcp from <dmz_ssh_users> to $dmz_main port 30900 keep state $options
 pass  in  quick on $eface proto tcp from <dmz_ssh_users> to $dmz_jail port 30900 keep state $options
 pass  in  quick on $eface reply-to ($eface $dmz_gw) proto tcp from <ssh_users> to $dmz_main port 30900 keep state $options
 pass  in  quick on $eface reply-to ($eface $dmz_gw) proto tcp from <ssh_users> to $dmz_jail port 30900 keep state $options

# Allow http/https access from any
# pass  in  quick on $eface proto tcp from any   to $dmz_jail port 80  keep state
 pass  in  quick on $eface reply-to ($eface $dmz_gw) proto tcp from <int_net>   to $dmz_jail port 80  keep state

# Allow ftp connections
#anchor "ftpsesame/*" in on $eface
# pass  in  quick on $eface reply-to ($eface $dmz_gw) proto tcp from <ftp_users> to $dmz_jail port 21 keep state
# Temporal
 pass  in  quick on $eface reply-to ($eface $dmz_gw) proto tcp from any to $dmz_jail port 21 keep state


# Allow ping
 pass  in  quick on $eface inet proto icmp all icmp-type echoreq keep state $options

# Allow all outgoing connections
 pass  out quick all keep state

# Block all
# block drop in all
Может кто подскажет в чём затык? :cz2:


Dmitriy_K
сержант
Сообщения: 200
Зарегистрирован: 2009-04-07 6:22:33
Откуда: г.Королёв

Re: Странная недоступность по второму интерфейсу в локалке

Непрочитанное сообщение Dmitriy_K » 2011-04-30 8:30:45

ADRE писал(а):в маршрутизации.
Вопрос как это разрулить. :(
Очень непонятен такой момент: По дампу видно, что обмен пакетами FTP внешне нормален (всё отправляется по правильному интерфейсу, клиент, вроде, даже что-то получает от сервера). Тогда из-за чего может не проходить листинг директории клиенту?

Dmitriy_K
сержант
Сообщения: 200
Зарегистрирован: 2009-04-07 6:22:33
Откуда: г.Королёв

Re: Странная недоступность по второму интерфейсу в локалке

Непрочитанное сообщение Dmitriy_K » 2011-05-01 8:54:19

Кажется, разобрался. Похоже, оставшиеся проблемы связаны с попыткой переноса содержимого jail с одного сервера на другой. Из-за этого что-то не так отрабатывает в части программ внутри перенесённой jail. (Версии FreeBSD на серверах одинаковые, но могли нюансы железа повлиять из-за применения оптимизации gmake при сборке софта.). Пересоберу начисто и посмотрим.

Dmitriy_K
сержант
Сообщения: 200
Зарегистрирован: 2009-04-07 6:22:33
Откуда: г.Королёв

Re: Странная недоступность по второму интерфейсу в локалке

Непрочитанное сообщение Dmitriy_K » 2011-05-01 15:54:23

Поторопился, всё-таки проблемы с маршрутизаций. Проверил поменяв местами jail-ы.
Траффик из DMZ проходит как-то очень с трудом, медленнее, чем через старый модем.

Dmitriy_K
сержант
Сообщения: 200
Зарегистрирован: 2009-04-07 6:22:33
Откуда: г.Королёв

Re: Странная недоступность по второму интерфейсу в локалке

Непрочитанное сообщение Dmitriy_K » 2011-05-02 21:43:25

Может кто подскажет почему у меня не проходят никакие варианты пропускания траффика FTP с интерфейса из DMZ в локалку? Точнее, траффик проходит с каким-то очень сильным урезанием скорости пропускания (до нескольких килобитов в секунду). Из-за этого приложение FTP вылетает по таймауту ожидания ответа. Ниже прилагаю опробованные варианты правил PF. Для случая WWW порт 80 они срабатывают, но для FTP нет.

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

# Пропускание траффика FTP не срабатывает
anchor "ftpsesame/*" in on $eface
pass  in  quick on $eface reply-to ($eface $dmz_gw) proto tcp from any to $dmz_jail port 21 keep state
-----------------------------------------

# Редирект WWW срабатывает
rdr pass on $iface proto tcp from any to $int_main port 80  -> $dmz_jail port 80

# Редирект FTP не срабатывает
rdr pass on $iface proto tcp from any to $int_main port 21  -> $dmz_jail port 21
-----------------------------------------

# Редирект WWW срабатывает
rdr on $iface inet proto tcp to $int_main port 80 tag WEB_SERVER -> $dmz_jail port 80
nat on $iface inet proto tcp tagged WEB_SERVER -> ($eface)
pass in on $iface reply-to ($iface $int_gw) inet proto tcp tagged WEB_SERVER keep state

# Редирект FTP не срабатывает
rdr on $iface inet proto tcp to $int_main port 21 tag FTP_SERVER -> $dmz_jail port 21
nat on $iface inet proto tcp tagged FTP_SERVER -> ($eface)
pass in on $iface reply-to ($iface $int_gw) inet proto tcp tagged FTP_SERVER keep state
Пробовал использовать ftpsesame в разных вариантах (с варианта с ним и начинал), но никак не влияет (правила фильтрации по таблице для простоты пока не использовал).

Dmitriy_K
сержант
Сообщения: 200
Зарегистрирован: 2009-04-07 6:22:33
Откуда: г.Королёв

Re: Странная недоступность по второму интерфейсу в локалке

Непрочитанное сообщение Dmitriy_K » 2011-05-04 16:51:55

У меня сложилось впечатление, что проблема всё-таки в системе. Может, глюки моей версии FreeBSD v8.0 (обновиться пока времени не хватает).
Иначе не понятны причины того, что эффект "пережатия" траффика по портам кроме 80 проявляется точно также при попытке обойти пересылку через em0 с помощью редиректа или ната с em1.