[Aircom]

Приветствую, уважаемые!

Ситуация такая... Работаем в 5 ГГц 3 года. Есть несколько шлюзов на Pfsense (dhcp связка ip+mac, captivportal, trafic shaper) на разных аплинках от разных провайдеров (везде статик айпи). СОРМ поставили рядом с одним из них. Там с настройкой зеркалирования не возникнет проблем. Даже Des3026 справиться. Всю голову сломал - как других (удаленных) сормить.

Вот схемка, которую в МФИ Софт отправляли.

[rdc]

На удалённых - весь абонентский трафик заворачивается в VPN, и через интернет идёт только этот VPN.

На центральной - этот VPN разворачивается обратно. В итоге удалённые абоненты пользуются интернетом центральной точки.

 

Минусы такого решения:

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

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

Плюсы:

- общий СОРМ

- общий NAT/DHCP/Firewall

- на центральной можно анонсировать свои ip-адреса по BGP и распределять их по любому количеству удалённых объектов.

 

В качестве VPN можно использовать L2 gif туннель на фряхе.

Тогда на верхней фряхе на схеме, добавляется ещё одна сетевуха в сторону свича, и туннель бриджуется с ней. Для свича и СОРМа это выглядит так, как будто удалённую БС воткнули напрямую в свич.

На нижней фряхе, вместо NAT/DHCP делается только туннель.

 

Также на удалённых точках можно настроить скрипт резервирования - чтобы в случае падения центральной точки, временно включился местный NAT/DHCP, а когда центр подымется - вернулся туннель.

[Aircom]

EoIP на мкротиках спарвиться? То есть, вместо удаленных шлюзов ставлю микроты и поднимаю EoIP до центрального. На нем делаю брижд с портом, подключаемым к СОРМ?

[rdc]

Понятия не имею. Я это на фряхе делаю, на неттопах.

[Constantin]

EoIP на мкротиках спарвиться?

все упирается в объем....eoip довольно прожерливо в плане ресурсов.....

[rdc]

Неттоп Pegatron на фряхе, на проце J1800, спокойно тянет сотни мегабит. Для радиосетей его хватит по уши.

А на центральном узле его можно терминировать на имеющемся тазике.

[Saab95]

EoIP на мкротиках спарвиться? То есть, вместо удаленных шлюзов ставлю микроты и поднимаю EoIP до центрального. На нем делаю брижд с портом, подключаемым к СОРМ?

 

Справится, только объем трафика польется в центр такой же, как и передача тех же объемов по туннелю, то есть предлагаемая уже выше схема с единым центром. Ну и надо понимать то, что передача L2 трафика поверх интернета может иметь потери, а если на СОРМе будут потери то часть информации может оказаться потерянной, например архивы и т.п.

[rdc]

Если какой-то пакет потеряется, он будет перепослан абонентом, и дойдёт до СОРМ в любом случае. С точки зрения СОРМ, это потери "у абонента".

[Saab95]

Если какой-то пакет потеряется, он будет перепослан абонентом, и дойдёт до СОРМ в любом случае. С точки зрения СОРМ, это потери "у абонента".

 

Нет, если на удаленной стороне коммутатор зеркалирует трафик на порт, допустим микротика, который пакует данные в EoIP туннель и передает в центр, и эти данные потерялись, то до СОРМа уже никаких переповторов не будет.

 

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

[rdc]

Я как раз и предложил вариант пропуска трафика через единый центр

[Aircom]

Спасибо за ответы. Прочитав их на 2-х форумах, склоняюсь к созданию мостов до ядра сети на 5 Ггц (только для миррора). Это наименьшим образом скажется на качестве связи в удаленных точках, точнее никак не скажется. Максимальный пролет 7 км с частично перекрытой зоной Френеля, но как показывает практика (есть действующий мост через лес по верхушкам деревьев на Airgrid M5) их пропускной способности должно хватить. По крайней мере на ближайший год. Что посоветуете бюджетного поставить до NATа на удаленных точках (Source Port и Target Port)? Возможно и Pfsense умеет это делать (поставить еще 1 сетевку и LAN-интерфейс бриджом сделать), но это на другом профильном форуме спрошу.

Edited July 20, 2016 by Aircom

[rdc]

Отзеркаленный трафик через радиомост не пролезет.

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

 

По поводу NAT - фряха на писюке может натить много гигабит, всё зависит только от проца и сетевух.

Но это лучше делать не на pfsense, а вручную настроить ipfw nat.

[Aircom]

Хмм.. Может я что-то недопонял, а какие причины ему не пойти со Span-порта удаленного шлюза? Ведь мост в прозрачном режиме это "удлиннитель" ютипихи.

[rdc]

Не совсем. Мост - это "свич на два порта". Пример, как ведёт себя мост на зеркальном трафике:

- зеркалируется пакет с mac-адреса А на mac-адрес Б. Мост запоминает, что mac-адрес А у него "на входе", отправляет пакет далее.

- зеркалируется ответный пакет, с mac-адреса Б на mac-адрес А. Мост дропает пакет, а также запоминает, что mac-адрес Б у него тоже "на входе".

- зеркалируются следующие пакеты А->Б, Б->А, А->Б, Б->А, А->Б, Б->А… Мост их дропает, для него они все "местные", пропускать их не нужно.

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

 

В итоге, для передачи зеркального трафика нужно этот механизм как-то убрать.

Теоретически можно приделать к мосту скрипт, который будет выкручивать в ноль arp aging timer на линуксе моста - но гарантий, что это решит проблему, я бы не дал.

 

И ещё одна проблема.

На мосту неминуемо будут потери пакетов. СОРМ этого очень не любит.

[Aircom]

Завтра проверю вышеуказанную схему Wireshark-ом. Что значит "не нравятся СОРМ"? ФСБ придираться будет?

Edited July 20, 2016 by Aircom

[rdc]

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

[Saab95]

Конечно сдать не получится. Когда сормится весь трафик без потерь, но у абонента есть потери, то абонент перезапросит данные и они к нему попадут, так же они попадут на СОРМ, то есть он соберет их из полученных пакетов. Если же до абонента нет потерь, а зеркалированный трафик потерялся, то его никто для переповтора не запросит и работать ничего толком не будет. Кроме всего, если будут наплывы трафика больше пропускной способности канала, то битыми окажутся все данные.