forum.lissyara.su

Добавлено: **2020-07-31 13:13:38**

Добрый день.

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

Есть две физически идентичные машины, которые используются как шлюзы с NAT ну и некоторое количество с реальными адресами без НАТ. Один основной, второй резервный, для физической замены в случае выхода из строя первого. Т.е. включен реально только один.

Суть проблемы в том, что уже второй раз, при замене одного на другой (с идентичным конфигом) - получается проблема с NAT.
Т.е. беру аплинк из первого шлюза втыкаю в wan интерфейс второго - интернет на втором сервере заводится. Включаю клиентский конец в lan интерфейс второго- заводится интернет у всех с реальными адресами, но клиенты сидящие за НАТ не работают - по ipfw show видно, что наружу они вылетают, но правило где они прилетают обратно nat 15 ip from any to 212.xx.xx.35 in recv em1 - пустое, по какой-то причине оно сюда не доходит в фаерволе.

Когда первый раз столкнулся, собрал тестовый стенд, перепроверил, все работает. Вернул те же самые конфиги как были без изменений - все заработало. Единственное что, порядок действий чуть отличался, т.е. переключил аплинк, воткнул ноутбук в lan интерфейс, увидел, что завелся НАТ, и воткнул в лан клиентов и все заработало.

Сегодня снова те же грабли, переткнул wan и lan аплинки, заработало всё, кроме клиентов за НАТ. С учетом того, что дело идет на живую, и клиентов лишний раз дергать не хочется, прежде чем тупо повторять алгоритм с включением ноута - хочу спросить совета. Может дело в чем-то простом, в общем нужен совет.

Конфиги пока не привожу, потому, что как мне кажется, дело вообще не в них, скорее я какой-то момент просто не понимаю в работе сети.

Добавлено: **2020-07-31 14:21:58**

Я на всех тестовых шлюзах использую штатный NAT файрвола...
С такими правилами:

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

${fwcmd} nat 1 config log if $WIF same_ports   
# Включаем открытый NAT 
         
${fwcmd} add 10000 nat 1 all from any to any via $WIF   
# Направляем все запросы в NAT (маршрутизация)

# WIF сетевая карта которая смотри наружу

У меня с этими правилами всё работает...

Добавлено: **2020-07-31 16:44:56**

Reken писал(а): ↑
2020-07-31 14:21:58
У меня с этими правилами всё работает...

У меня этот конфиг который есть сейчас, уже лет 7 работает.

Проблема возникает в момент замены одного системного блока на такой же, с таким же конфигом IP адресов и ipfw.

И именно это ставит меня в тупик. Конфиг 100% рабочий. Может быть из-за смены мак адресов какие-то ошибки маршрутизации возникают, но не понятно почему только для НАТ клиентов.

Я просто в сетях понимаю не особо глубоко, и нужен пинок в нужном направлении от тех, кто хорошо понимает сети.

Добавлено: **2020-07-31 18:30:28**

Нет, из-за смены мак адреса не должно быть никаких ошибок.
Может быть всё таки конфиги разные?
Я бы сделал так, что бы облегчить работу:
На первом шлюзе сделал бы dump
На втором шлюзе восстановился бы из этого дампа (restore)
Дальше останется только названия сетевых карт поменять в rc.conf ну и названия жесткого диска...

Я по такой процедуре много раз переносил интернет шлюз с одного железа на другое.
Заодно точно будет понятно в конфигах дело или нет...

Добавлено: **2020-08-01 12:15:23**

Reken писал(а): ↑
2020-07-31 18:30:28
Может быть всё таки конфиги разные?

Конфиги относящиеся к ip адресам и NAT идентичные, я их скопировал прямо перед переключением. rc.conf, ipfw и sysctl.conf идентичные, в ядро добавлены те же опции путем копирования.

dump и restore не подходят, я сейчас еще и обновляюсь с 11.3 до 12.1 и меняю ufs на zfs.
Но когда переносил с 11.3 32-bit на 11.3 64-bit тем же методом - первый раз возникла эта проблема. Потом, волшебным образом, при второй попытке переключения, всё само заработало. Конфиг при этом не менялся. Тогда списал это на глюки\воздействие инопланетян, в общем заработало, и успокоился.

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

Добавлено: **2020-08-01 12:29:15**

Главная проблема в том, что есть около 400 клиентов работающих почти круглосуточно, и просто переключить и начать неспешно разбираться я, увы, не могу.

Минут на 5-10 устроить разрыв еще можно, но больше не хотелось бы. Раньше такой проблемы никогда не возникало, переключали подобным образом десятки раз. Вот последние два раза что-то идет не так, и я не понимаю в чем дело.

Добавлено: **2020-08-01 12:51:47**

Выложу все же конфиги.

rc.ipfw - он исторически мигрирует с незначительными изменениями, может в нем не все оптимально, но он работает 100%

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

#!/bin/sh -

#Variables
ipfw="/sbin/ipfw -q"

ip_main="212.tt.tt.34" # IP-address using for main client gateway

out_if="em1"
int_if="em0"

out_ip=$ip_main

    $ipfw -f flush
    $ipfw pipe flush
    $ipfw table all flush
    
# Delete configured nat
    $ipfw nat show config | awk '{print $3}' | sed 's/://g' |
    while read nat_num
    do
        $ipfw nat delete $nat_num
    done
    
# # # # # # # # # # # # #
# SET 0. GENERAL RULES. #
# # # # # # # # # # # # #

# Dynamic rules
    $ipfw add 1 check-state

# Loopback interface config
    $ipfw add 2 allow all from any to any via lo0
    $ipfw add 3 drop all from any to 127.0.0.0/8
    $ipfw add 4 drop all from 127.0.0.0/8 to any

    $ipfw add 7 allow all from me to any keep-state

# Allow all connection from office-network to outer ip-address
    $ipfw add 9 allow all from 212.xx.xx.128/28 to any
    $ipfw add 10 allow all from any to 212.xx.xx.128/28
    $ipfw add 11 allow all from 212.xx.xx.144/28 to any
    $ipfw add 12 allow all from any to 212.xx.xx.144/28
    $ipfw add 13 allow all from 213.yy.yy.0/25 to any
    $ipfw add 14 allow all from any to 213.yy.yy.0/25

# Deny our temporary unused networks
    $ipfw add 17 drop all from any to 212.tt.tt.40/29
    $ipfw add 18 drop all from any to 212.tt.tt.48/28
    $ipfw add 19 drop all from any to 213.zz.zz.0/24


# Drop bad traffic
    $ipfw add 30 drop all from any to any 445 # virus as usual
    $ipfw add 31 drop tcp from any to any not established tcpflags fin
    $ipfw add 32 drop tcp from any to any tcpflags fin,syn,rst,psh,ack,urg
    $ipfw add 33 drop tcp from any to any tcpflags !fin,!syn,!rst,!psh,!ack,!urg
    

# # # # # # # # # # # #
# SET 1. USERS RULES. #
# # # # # # # # # # # #

    $ipfw add 36 allow all from 10.41.11.129 to 10.41.11.128/26 via $int_if
    $ipfw add 37 allow all from 10.41.11.128/26 to 10.41.11.129 via $int_if
    
#bloger without table 99
        $ipfw add 45 skipto 51 ip from 213.yy.yy.190 to any
        $ipfw add 46 skipto 51 ip from any to 213.yy.yy.190
        $ipfw add 47 skipto 51 ip from 172.21.15.167 to any
        $ipfw add 48 skipto 51 ip from any to 172.21.15.167

  
    $ipfw table 15 flush
    $ipfw table 15 add 172.21.15.0/24
    $ipfw table 15 add 172.21.150.0/24
    $ipfw table 18 flush
    $ipfw table 18 add 172.21.18.0/24
    $ipfw table 20 flush
    $ipfw table 20 add 172.21.20.0/24
    $ipfw table 22 flush
    $ipfw table 22 add 172.21.22.0/24
    
    $ipfw nat 15 config ip 212.tt.tt.35 reset same_ports deny_in        redirect_port tcp 172.21.15.254:15115 1015 \
                                                                        redirect_port tcp 172.21.15.254:15116 1016 \
                                                                        redirect_port tcp 172.21.15.254:15117 1017 \
                                                                        redirect_port tcp 172.21.15.254:15118 1018 \
                                                                        redirect_port tcp 172.21.15.254:15119 1019 \

    $ipfw nat 18 config ip 212.tt.tt.36 reset same_ports deny_in
    $ipfw nat 20 config ip 212.tt.tt.37 reset same_ports deny_in
    $ipfw nat 22 config ip 212.tt.tt.38 reset same_ports        redirect_port tcp 172.21.22.52:22 2222 83.242.180.2 \
                                                                 redirect_port tcp 172.21.22.148:3389 1015 \
                                                                 redirect_port tcp 172.21.22.153:3389 1011 \
                                                                 redirect_port tcp 172.21.22.153:4000 49153 \
                                                                 redirect_port tcp 172.21.22.154:3389 1012 \
                                                                 redirect_port tcp 172.21.22.160:3389 1013 \
                                                                 redirect_port tcp 172.21.22.165:3389 1014 \
                                                                 redirect_port tcp 172.21.22.219:3389 1016 \
                                                                 redirect_port tcp 172.21.22.225:3389 1020

    $ipfw add 51 nat 15 all from table\(15\) to any out via $out_if
    $ipfw add 52 nat 18 all from table\(18\) to any out via $out_if
    $ipfw add 53 nat 20 all from table\(20\) to any out via $out_if
    $ipfw add 54 nat 22 all from table\(22\) to any out via $out_if
    
    $ipfw add 61 nat 15 all from any to 212.tt.tt.35 in recv $out_if
    $ipfw add 62 nat 18 all from any to 212.tt.tt.36 in recv $out_if
    $ipfw add 63 nat 20 all from any to 212.tt.tt.37 in recv $out_if
    $ipfw add 64 nat 22 all from any to 212.tt.tt.38 in recv $out_if

    $ipfw table 1 flush
    cat /usr/local/etc/ipfw_table |
    while read ip
    do
        $ipfw table 1 add $ip
    done
    $ipfw add allow all from table\(1\) to any
    $ipfw add allow all from any to table\(1\)

    $ipfw add allow ip from 212.tt.tt.35 to any
    $ipfw add allow ip from any to 212.tt.tt.35
    $ipfw add allow ip from 212.tt.tt.36 to any
    $ipfw add allow ip from any to 212.tt.tt.36
    $ipfw add allow ip from 212.tt.tt.37 to any
    $ipfw add allow ip from any to 212.tt.tt.37
    $ipfw add allow ip from 212.tt.tt.38 to any
    $ipfw add allow ip from any to 212.tt.tt.38

    $ipfw add allow icmp from any to any icmptypes 0,3,8,11

rc.conf

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

clear_tmp_enable="YES"
syslogd_flags="-ss"

hostname="gate01.wwwww.ru"
defaultrouter="212.tt.tt.33"

ifconfig_em1="inet 212.tt.tt.34 netmask 255.255.255.248"
ifconfig_em1_alias0="inet 212.tt.tt.35 netmask 255.255.255.255"
ifconfig_em1_alias1="inet 212.tt.tt.36 netmask 255.255.255.255"
ifconfig_em1_alias2="inet 212.tt.tt.37 netmask 255.255.255.255"
ifconfig_em1_alias3="inet 212.tt.tt.38 netmask 255.255.255.255"
ifconfig_em0="inet 172.21.0.1 netmask 255.255.0.0"
ifconfig_em0_alias0="inet 212.xx.xx.161 netmask 255.255.255.224"
ifconfig_em0_alias1="inet 10.41.11.129 netmask 255.255.255.192"
ifconfig_em0_alias2="inet 213.yy.yy.129 netmask 255.255.255.128"
ifconfig_em0_alias3="inet 212.xx.xx.129 netmask 255.255.255.240"

static_routes="pt1 pt2 pt3 pt4 prgz"
route_pt1="-net 213.yy.yy.0/25 212.xx.xx.142"
route_pt2="-net 212.xx.xx.144/28 212.xx.xx.142"
route_pt3="-net 212.tt.tt.40/29 212.xx.xx.142"
route_pt4="-net 212.tt.tt.48/28 212.xx.xx.142"
route_prgz="-net 213.zz.zz.0/24 212.xx.xx.142"

gateway_enable="YES"
firewall_enable="YES"
firewall_nat_enable="YES"
firewall_script="/etc/rc.ipfw"
inetd_enable="YES"
zfs_enable="YES"

sendmail_enable="NO"
sendmail_submit_enable="YES"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

ntpd_enable="YES"
ntpd_sync_on_start="YES"
sshd_enable="YES"

dumpdev="NO"

sysctl.conf

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

security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
security.bsd.unprivileged_read_msgbuf=0
security.bsd.unprivileged_proc_debug=0
kern.randompid=1
security.bsd.stack_guard_page=1
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.icmp.maskrepl=0
net.inet.ip.sourceroute=0
net.inet.ip.accept_sourceroute=0
net.inet.icmp.bmcastecho=0
net.inet.icmp.icmplim=100
net.inet.ip.fw.autoinc_step=10
net.inet.ip.fw.one_pass=0

и опции добавленные в ядро

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

options         IPFIREWALL
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_VERBOSE_LIMIT=500
options         DUMMYNET
options         IPDIVERT
options         MROUTING
options         HZ=2000
options         IPFIREWALL_NAT
options         LIBALIAS
options         NETGRAPH
options         NETGRAPH_ETHER
options         NETGRAPH_SOCKET
options         NETGRAPH_TEE

Добавлено: **2020-08-03 9:13:09**

Даже не знаю в чем может быть проблема...

Я на вашем месте сделал бы наверное так:
1) Со шлюза №1 снял бы полный dump
2) В виртуальной машине развернул бы этот dump
3) Обновил бы в виртуальной машине всё что нужно обновить
4) Снял бы dupm с виртуальной машины
5) Развернул бы dupm на шлюзе №2

Ну это бы прокатило с UFS. На счет ZFS не знаю...

P.S. У меня как то было наподобие:
На FreeBSD который был интернет шлюзом, был установлен jabber сервер
При переносе шлюза на другое железо (как раз через dupm/restore) клиенты перестали подключаться к jabber серверу
Причина оказалась в том, что на шлюзе до переноса было правило:
Пропускать пакеты от клиентов jabber до jabber сервера

После переноса, пока не добавил 2-е правило, ничего не работало...
Пропускать пакеты от jabberd сервера к клиентам jabber

Добавлено: **2020-08-03 13:13:08**

Не совсем уверен, что дам какой-то реальный совет,
но просто опишу какие-то моменты которые тоже могут влиять при похожем раскладе.

1. На одной удаленной точке, выявлено, что при переподключении пров менял ип гейта.
Подключение шло по pppoe (авторизация, получение фиксированного внешнего ип, репорт проверки баланса, запуск ракуна2 для связи локальных сетей).

Пров подставлял, по очереди, три разных гейта.
И третий не работал никогда.
Реакция прова на исправление косяка - 0 (у нас ошибок не бывает, Оруэл 1984).

Решение: В скрипт подъема коннекта внесено изменение, как выдан кривой гейт, перезапустить подключение с временной паузой, чтобы получить следующий адрес гейта.
Банальщина.

2. Правила вида:

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

    $ipfw nat 22 config ip 212.tt.tt.38 reset same_ports        redirect_port tcp 172.21.22.52:22 2222 83.242.180.2 \
                                                                 redirect_port tcp 172.21.22.148:3389 1015 \
                                                                 redirect_port tcp 172.21.22.153:3389 1011 \
                                                                 redirect_port tcp 172.21.22.153:4000 49153 \
                                                                 redirect_port tcp 172.21.22.154:3389 1012 \
                                                                 redirect_port tcp 172.21.22.160:3389 1013 \
                                                                 redirect_port tcp 172.21.22.165:3389 1014 \
                                                                 redirect_port tcp 172.21.22.219:3389 1016 \
                                                                 redirect_port tcp 172.21.22.225:3389 1020

Попробовать привести к виду без переноса строк.
К сожалению бывали косяки, иной раз банальные, нечитаемый символ в текст закрадывался или юникод в середине и только в хексе видно...
Есть неплохая статья https://www.lissyara.su/articles/freebs ... /ipfw_nat/ Но нужно учесть, что там размещено: 2009-08-30, т.е. на текущий момент могут быть отступления.

3. Часть скрипта:

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

    cat /usr/local/etc/ipfw_table |
    while read ip
    do
        $ipfw table 1 add $ip
    done

Проверить очень внимательно содержимое ipfw_table (лучше через хекс, hexdump -C /etc/rc.conf и т.д.), права.

У себя использую конструкцию вида:

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

if [ -f "${dir}/firewall.table18" ]
then
/bin/cat ${dir}/firewall.table18 | /usr/bin/sed '/ *#/d; /^ *$/d' | while read ip; do
  ${fw} table 18 add ${ip}
done

Ничего особенного, просто проверка наличия файла, полные пути к программам и возможность комментария (блокирования) загрузки того или иного ип из файла.
Очень помогает когда firewall.table*, т.е. много файлов.
В начале каждого файлика таблиц написал себе:

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

# Комментарии в firewall.table только с начала строки!
# Наличие комментария в конце строки исключит
# текущую запись из загрузки в таблицу

4. Переподъем таблицы всех маршрутов после подключения/переподключения. Но это больше относится к п.1.
Несмотря на то, что Ваша схема иная, маршруты делали вынос мозга.
Причем иногда крышу сносило самой фре, а иногда что-то прилетало из вне.
Не часто, но бывало, потихоньку раскурил этот момент.
И только когда удалось поймать примерное понимание "почему это, возможно, происходит" были написаны эти скрипты, а проблема ушла или замаскировалась.
Т.к. скрипт в атомате каждые 5 минут проверял "нужные точки самой системы" и если, что не так, то все передергивал.
И это получалось быстрее, чем успевал получить вопрос от пользователей "а чего это у меня не работает".

5. п.4 примеры привести не могу, никак не добраться до площадки отключенной пару лет назад машины.

6. Есть что-то, что немного мешает, стало мешать, при замене шлюза.
Может таблицы arp, но нат-то тут причем? (Это просто вслух).

Я-бы посмотрел правила при работающем и не работающем варианте.
ipfw -d show.

Не догнал, как делается обратное правило для ната в Вашем варианте.
Вроде должно быть два правила.

В классике, для одного ната, это так:

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

${fw} add divert natd all from ${intnet},${intvmnet},${intvmsrvip},${intwifinet} to any out via ${extif}
${fw} add divert natd all from any to ${extip} in via ${extif}

10900   191388811    47202662728 divert 8668 ip from 192.168.6.0/24,192.168.21.0/24,192.168.23.2,192.168.224.0/24 to any out via em1
10950   576208608   368406800438 divert 8668 ip from any to х.х.х.х in via em1

И еще, вполне возможно, что отдыхавший хост помнит устарешие маршруты.
А "Потом, волшебным образом, при второй попытке переключения, всё само заработало."
Именно переключения или после второй перезагрузки второго, заменившего хоста?

Главное не спешить и внимательно все изучить.
Уверен, что где-то банальщина.

У Вас есть код:

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

# Delete configured nat
    $ipfw nat show config | awk '{print $3}' | sed 's/://g' |
    while read nat_num
    do
        $ipfw nat delete $nat_num
    done

Но это только лишь правила ipfw, т.е. это никак не влияет на текущую маршрутизацию хоста, которая м.б. "из кеша".

Как-то много букаф получилось, сорри...

Добавлено: **2020-08-03 14:48:10**

Добавлю еще пару мыслей на подумать.

а) Проверить правила на перехлест.
Что имею ввиду?

Есть такой текст:
https://www.freebsd.org/doc/ru_RU.KOI8- ... -ipfw.html
26.6.5.7. Пример правил с сохранением состояний и поддержкой NAT
Смотрим третий абзац, написано: "При использовании skipto нумерация правил становится обязательной"

У Вас часть правил с номерами, а часть без.
Т.е. вторые будут иметь стандартную, последовательную, нумерацию с шагом в 100 (по дефолту).

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

ipfw -d show

поможет сравнить где правило находится в скрипте и где расположено оное, а также его "ответка", в рельной обстановке. Соответствуют-ли оные ожидаемому?

б) Есть еще такой момент, использование правил с "check-state/skipto" работает "изнутри сети".

Т.е. ответка создается только при инициализации соединения изнутри сети наружу.
Т.о., если расчитывать, что соединение "снаружи" на порт 3389 (1015)
(из Вашей части правила redirect_port tcp 172.21.22.148:3389 1015)
может еще не существовать, т.к. "изнутри не было такого коннекта".
Да и как его создать? Ведь нужен еще и номер исходящего порта от клиента, а он всегда меняется и заранее его не узнать, пока не прилетит пакетик.
Что само по себе место затыка, т.к. 172.21.22.148:3389 не может "само по себе" инициировать такое подключение, а значит и ответка не создастся.

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

Добавлено: **2020-10-23 19:27:20**

В общем проблему решили

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

После замены одного шлюза на другой - из 5-х внешних IP прописанных на интерфейсе em1 (4 как алиасы для 4-х НАТов), почему-то начинал работать только один, который отвечал за интернет самого сервера и за реальные адреса, а все что за НАТ не работало.

Начинает работать только после ребута этого свитча SNR преобразователя из оптики в медь.

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

з.ы. работа на удаленке помогла, пока коллеги переключали, сидел снаружи и пинговал, поэтому и заметил, что алиасы не работают. А если решать проблему чисто изнутри сети - то поди еще догадайся, почему все работает кроме НАТ.

Добавлено: **2020-12-24 12:54:08**

dalt писал(а): ↑
2020-10-23 19:27:20
проблемы понять не могу, но явно что-то с мак адресами

Есть такой порт "net-mgmt/arpwatch".
Когда настроите на гейте, то много интересного можно увидеть.
И еще может влиять "старая" маршрутизация на гейте, которую можно "просто передернуть", например из крона. Поставить на проверку каждую минуту и баста. Как правило никто не успевает за эту минуту понять, что что-то не работает...

forum.lissyara.su

проблема с NAT при замене шлюзов

проблема с NAT при замене шлюзов

проблема с NAT при замене шлюзов

проблема с NAT при замене шлюзов

проблема с NAT при замене шлюзов

проблема с NAT при замене шлюзов

проблема с NAT при замене шлюзов

проблема с NAT при замене шлюзов

проблема с NAT при замене шлюзов

проблема с NAT при замене шлюзов

проблема с NAT при замене шлюзов

проблема с NAT при замене шлюзов

проблема с NAT при замене шлюзов