[vfiuchcikicshuusrch]

@Saab95

да, спасибо за подробное и простое разъяснение. я принцип понял. nth немного ранее так же перенастроил, т.е. получается смешанный тип создание списков из nth + классификация пакетов по исходящему адресу. после этого адреса в списки стали корректно попадать, c nth они почти все в первый список лезут и некоторые проскакивают во второй, что плохо.

проброс портов работает с двух каналов хорошо, интересно как будет работать опенвпн... если не делать, то что ниже написал.

 

настройку маршрутов проводить с маркировкой ? или дополнительно не нужно больше ничего маркировать для базовой работы ?

я их промаркировал отдельным правилом после pcc и создал 2 дефолтных маршрута с соответствующим роутинг-марк. и теперь из вне не проходит трафик до сервера если он оказался в другом списке.

 

 

Изменено 29 апреля, 2020 пользователем vfiuchcikicshuusrch

[vfiuchcikicshuusrch]

@Saab95 

 

вобщем вопрос с роутами открыт, на самом то деле.

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

как проще решить эту проблему ? или тут для серверов применять другой тип балансировки, не записывая их в списки ?

 

upd:

создал статический список серверов, в манглах поправил правила, если src-address-list = !Servers то правило выполняется и помещает адрес в список.

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

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

 

upd:

так как сделано чуть выше, трафик ходит из вне, т.е. проброс портов работает корректно, но сам сервер не может доступ в инет получить вообще %) странная ситуация...

 

upd: настроил такую конфигурацию, при которой всё, что мне было нужно работает и балансируется, но есть одно но. Если падает один канал, то все переходят на другой, некоторые даже не замечают обрыва. Но когда канал восстанавливается и в работе оказывается снова два канала, то остаётся подключение к старому шлюзу, т.е. по правилам пакеты должны лететь на другой шлюз а в подключениях микротика (firewall - connections) висит подключением на старый шлюз в строке Reply Dst. Address. Приходится очищать в микротике подключения (firewall -> Connections) и тогда всё начинает работать как положено. Можно ли сделать так, чтобы все установленные на данный момент соединения обрывались корректно и не мешали новым ?

172.16.1.10 и 172.16.2.10 - это шлюзы в интернет на убунту с ip_forwarding = 1

/ip address
add address=172.16.1.1/24 interface=wan1 
add address=172.16.2.1/24 interface=wan2
add address=10.0.0.0/24 interface=lan

/ip firewall mangle
add action=add-src-to-address-list address-list=wan1 address-list-timeout=1h chain=prerouting dst-address=!10.0.0.0/24 per-connection-classifier=src-address:2/0 src-address=10.0.0.0/24
add action=mark-routing dst-address=!10.0.0.0/24 src-address-list=wan1 chain=prerouting new-routing-mark=wan1

add action=add-src-to-address-list address-list=wan2 address-list-timeout=1h chain=prerouting dst-address=!10.0.0.0/24 per-connection-classifier=src-address:2/1 src-address=10.0.0.0/24
add action=mark-routing dst-address=!10.0.0.0/24 src-address-list=wan2 chain=prerouting new-routing-mark=wan2

/ip firewall nat
add action=masquerade chain=srcnat dst-address=!10.0.0.0/24

/ip route
add distance=1 dst-address=0.0.0.0/0 gateway=172.16.1.10 routing-mark=wan1
add distance=1 dst-address=0.0.0.0/0 gateway=172.16.2.10 routing-mark=wan2
add distance=1 dst-address=0.0.0.0/0 gateway=172.16.2.10
add distance=2 dst-address=0.0.0.0/0 gateway=172.16.1.10

 

Изменено 30 апреля, 2020 пользователем vfiuchcikicshuusrch

[RN3DCX]

@vfiuchcikicshuusrch , вот тут объясняется твоя проблема: Три шага к фейлу

 

[vfiuchcikicshuusrch]

@RN3DCX спасибо! а кроме проблемы с соединением, конфиг правильный или можно внести поправки какие-нибудь ?

 

не очень понятно, там вписали одну строку и cделано там немного не так как я копипастил %)))... применительно к моему конфигу в роуты дописать новый тип ?

 

ещё одна проблема всё таки присутствует, очень медленно всё работает на железном микротике, т.е. я сейчас тестировал всё в виртуальной среде с mikrotik chr, но потом перенес конфигурацию уже в настоящий микротик, и тут наблюдает сильное замедление работы интернета, странички открываются медленно... могут вообще не открыться.

при это если отключить один wan программно, то сразу всё начинает летать и все переходят на второй канал.

почему тормозит всё ? %) не так уж и много правил ведь...

Изменено 30 апреля, 2020 пользователем vfiuchcikicshuusrch

[RN3DCX]

1 час назад, vfiuchcikicshuusrch сказал:

почему тормозит всё

модель некротика?

[vfiuchcikicshuusrch]

@RN3DCX Работаю с RB962UiGS-5HacT2HnT

прочитал про рекурсивные маршруты,

но у меня всё равно в итоге соединения остаются %)... настроил всё как положено в них..

Изменено 30 апреля, 2020 пользователем vfiuchcikicshuusrch

[RN3DCX]

1 час назад, vfiuchcikicshuusrch сказал:

но потом перенес конфигурацию уже в настоящий микротик, и тут наблюдает сильное замедление работы интернета

это на скольких пользователях? т.е. от какого количества начинаются проблемы?

[vfiuchcikicshuusrch]

@RN3DCX 58, в итоге будет больше, сейчас карантин действует ещё.. рассчитываю на 100 пк + телефоны пользователей. примерно 200 активных клиентов будет.

в виртуалке на сервере, всего 2 клиента и 1 сервер, всё летает даже с ограничением скорости с демо лицензией микротика в 1 мбит/с

Изменено 30 апреля, 2020 пользователем vfiuchcikicshuusrch

[RN3DCX]

@vfiuchcikicshuusrch , не прожуёт такие объемы одноядерный проц на 700 Mgz

[vfiuchcikicshuusrch]

@RN3DCX что посоветуете ? вариант купить новый есть, нужно быть уверенным в том, что нам хватит и запас оставить на расширение....

или взволить эту ношу на mikrotik chr ? под виртуалкой.

[RN3DCX]

глянь еще конфиг в ссылках, и дополни свой: 

 

 

 

4 минуты назад, vfiuchcikicshuusrch сказал:

вариант купить новый есть, нужно быть уверенным в том, что нам хватит и запас оставить на расширение....

Быть уверенным в некротике - пока это только мечты.

 

8 минут назад, vfiuchcikicshuusrch сказал:

взволить эту ношу на mikrotik chr ? под виртуалкой.

Если с лицензией всё ок!? это самый надежный вариант, т.к. у некротика относительно хороший софт, но слабое железо.

[vfiuchcikicshuusrch]

@RN3DCX естественно с лицензией всё будет ок :)

[vfiuchcikicshuusrch]

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

[McSea]

9 hours ago, vfiuchcikicshuusrch said:

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

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

В вашем конфиге не вижу этого.

Изменено 30 апреля, 2020 пользователем McSea

[vfiuchcikicshuusrch]

@McSea судя по всему, и без этого работает, шанс есть... но пока при тестировании это работает однозначно.

 

сейчас 2 проблемы.

 1) тормозит

 2) при отключении одного канала оба списка начинают работать через один шлюз (всё ок), а вот при возвращении второго канала, те, что в списке на второй канал были назначены - не работают, до тех пор, пока не очистишь их соединения в файрволе микротика.

[RN3DCX]

1 час назад, vfiuchcikicshuusrch сказал:

сейчас 2 проблемы.

 1) тормозит

 2) при отключении одного канала оба списка начинают работать через один шлюз (всё ок), а вот при возвращении второго канала, те, что в списке на второй канал были назначены - не работают, до тех пор, пока не очистишь их соединения в файрволе микротика.

1. лечиться маркировкой в / ip firewall mangle, ссылка с примерами выше. А вот по этой ссылке еще детально разжёвывают (ТыЦ)

2. выложите конфиг /ip route

[vfiuchcikicshuusrch]

@RN3DCX 

/ip firewall mangle
add action=add-src-to-address-list address-list=wan1 address-list-timeout=1d chain=prerouting \
    dst-address=!10.0.0.0/24 per-connection-classifier=src-address:2/0 src-address=10.0.0.0/24 \
    src-address-list=!Servers
add action=mark-routing chain=prerouting dst-address=!10.0.0.0/24 new-routing-mark=wan1 \
    passthrough=no src-address-list=wan1

add action=add-src-to-address-list address-list=wan2 address-list-timeout=1d chain=prerouting \
    dst-address=!10.0.0.0/24 per-connection-classifier=src-address:2/1 src-address=10.0.0.0/24 \
    src-address-list=!Servers
add action=mark-routing chain=prerouting dst-address=!10.0.0.0/24 new-routing-mark=wan2 \
    passthrough=no src-address-list=wan2

/ip firewall nat
add action=masquerade chain=srcnat src-address=10.0.0.0/24
add action=dst-nat chain=dstnat dst-port=10022 protocol=tcp to-addresses=10.0.0.198 to-ports=22

/ip route
add distance=1 gateway=8.8.8.8 routing-mark=wan1
add distance=1 gateway=8.8.4.4 routing-mark=wan2
add check-gateway=ping distance=1 gateway=8.8.8.8
add check-gateway=ping distance=2 gateway=8.8.4.4
add distance=1 dst-address=8.8.4.4/32 gateway=172.168.2.10 scope=10
add distance=1 dst-address=8.8.8.8/32 gateway=172.168.1.10 scope=10
add distance=10 dst-address=8.8.8.8/32 type=blackhole
add distance=10 dst-address=8.8.4.4/32 type=blackhole

вообще не ощутил эффекта когда переделал всё в рекурсивный роутинг и добавил blackhole.
 

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

Изменено 1 мая, 2020 пользователем vfiuchcikicshuusrch

[vfiuchcikicshuusrch]

задействовал netwatch, выставил задержку в 5 сек, хотелось бы, чтобы само всё мнгновенно отрабатывало.

cделал так:

/ip firewall filter
add action=reject chain=output dst-address=8.8.8.8 out-interface=ISP2 reject-with=icmp-network-unreachable
add action=reject chain=output dst-address=8.8.4.4 out-interface=ISP1 reject-with=icmp-network-unreachable

добавил в netwatch проверку двух адресов 8.8.8.8 и 8.8.4.4 соответственно для wan1 и wan2

и вписал скрипты в UP. Во время падения т.е. события DOWN скрипт выполнять не нужно, т.к. и без него всё хорошо переключается.

:log warning ("WAN1 UP")
/ip firewall connection remove [find]

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

Думаю, дополнительно промаркировать соединения, чтобы очищать только те, канал для которых вернулся в работу.

 

результата добился, более менее всё устраивает в этом плане, Может быть можно всё это сделать лучше ?
 

[feeman]

 

Цитата

/ip firewall mangle

 

1#маркируем входящий трафик с внешних интерфейсов

add action=mark-connection chain=input in-interface=FirstISP new-connection-mark=connections-FirstISP

add action=mark-connection chain=input in-interface=SecondISP new-connection-mark=connections-SecondISP

 

2#маркируем трафик входящий от клиентов  на маршутизатор + балансировка PCC

add action=mark-connection chain=prerouting dst-address-type=!local in-interface=LAN new-connection-mark=connections-FirstISP per-connection-classifier both-addresses:2/0

add action=mark-connection chain=prerouting dst-address-type=!local in-interface=LAN new-connection-mark=connections-SecondISP per-connection-classifier both-addresses:2/1

 

3#ответ маршрутизатора с правильного внешнего интерфейса

add action=mark-routing chain=prerouting connection-mark=connections-FirstISP dst-address-type=!local new-routing-mark=route-FirstISP
add action=mark-routing chain=prerouting connection-mark=connections-SecondISP dst-address-type=!local new-routing-mark=route-SecondISP

 

4#ответ маршрутизатора с правильного внешнего интерфейса
add action=mark-routing chain=output connection-mark=connections-FirstISP dst-address-type=!local new-routing-mark=route-FirstISP
add action=mark-routing chain=output connection-mark=connections-SecondISP dst-address-type=!local new-routing-mark=route-SecondISP

 

Если в 2-ом понятна логика dst-address-type=!, то вот в не пойму, в 3-м и 4-м нужны ли они тут!?

 

Кто подскажет!?

Изменено 1 мая, 2020 пользователем feeman

[vfiuchcikicshuusrch]

Подскажите, почему pcc по src-address (наверное и по другим параметрам) не поровну раскидывает клиентов по спискам ? системы какой то вообще не наблюдаю, даже на тестовом виртуальном микротике из двух клиентов оба в один список попадают и причём удаление одного из них из списка не помогает, он опять туда же залетает...

 

гугл подсказал. создал больше правил с pcc для уверенной классификации по ip.

Изменено 2 мая, 2020 пользователем vfiuchcikicshuusrch

[vfiuchcikicshuusrch]

наконец-то запустилась балансировка на железе, всё работает, ничего не тормозит, файловер отрабатывает корректно и быстро.

но есть одно составное НО:

один провайдер тупо статику даёт, а второй даёт статику, но через dhcp.

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

поднял dhcp на ван порту, и шлюзы все поднялись и начала работать балансировка.

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

как победить ?... куда копать ?

 

pcc src-address всё таки не очень ровно раскидывает клиентов :( 

Изменено 4 мая, 2020 пользователем vfiuchcikicshuusrch

[vfiuchcikicshuusrch]

/ip firewall mangle
add action=accept chain=prerouting dst-address=172.16.1.0/24 in-interface="LAN Bridge"
add action=accept chain=prerouting dst-address=172.16.2.0/24 in-interface="LAN Bridge"
add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=ISP1 new-connection-mark=wan1 passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=ISP2 new-connection-mark=wan2 passthrough=yes

add action=add-src-to-address-list address-list=wan1 address-list-timeout=1d chain=prerouting dst-address=!10.0.0.0/24 dst-address-type=!local \
    per-connection-classifier=src-address:2/0 src-address=10.0.0.0/24 src-address-list=!servers
add action=mark-routing chain=prerouting connection-mark=no-mark dst-address=!10.0.0.0/24 new-routing-mark=wan1 passthrough=no src-address-list=wan1
add action=add-src-to-address-list address-list=wan2 address-list-timeout=1d chain=prerouting dst-address=!110.0.0.0/24 dst-address-type=!local \
    per-connection-classifier=src-address:2/1 src-address=10.0.0.0/24 src-address-list=!servers
add action=mark-routing chain=prerouting connection-mark=no-mark dst-address=!10.0.0.0/24 new-routing-mark=wan2 passthrough=no src-address-list=wan2

add action=mark-connection chain=input connection-mark=no-mark in-interface=ISP1 new-connection-mark=wan1 passthrough=yes
add action=mark-routing chain=output connection-mark=wan1 new-routing-mark=wan1 passthrough=no
add action=mark-connection chain=input connection-mark=no-mark in-interface=ISP2 new-connection-mark=wan2 passthrough=yes
add action=mark-routing chain=output connection-mark=wan2 new-routing-mark=wan2 passthrough=no

посмотрите конфигурацию, почему из вне проброс портов работает только через первый ван, а через второй не хочет, при одновременной работе обоих ванов. Если один порт отключить, то через второй работает.

что тут нужно исправить ?

Изменено 4 мая, 2020 пользователем vfiuchcikicshuusrch

[feeman]

В 01.05.2020 в 16:51, vfiuchcikicshuusrch сказал:

Думаю, дополнительно промаркировать соединения, чтобы очищать только те, канал для которых вернулся в работу.

В итоге дополнил? или забил на это?

[vfiuchcikicshuusrch]

@feeman пока забил, да и не требуется это вроде.

проброс портов доделал. теперь микротик в работе с балансировкой и пробросом портов с обоих каналов интернета. и всё вроде бы работает. и загрузка проца 1% что радует очень!

[feeman]

@vfiuchcikicshuusrch , если не сложно выложи конфиг, для тех кто столкнется с похожей проблемой.