Pfsence оптимизация VPN и mapping с подменой src и dst IP адресов.

Накопилось куча VPN подключений, попросили сделать ещё 2.
Решил их сделать на собранном ранее кластере pfsence, смотрящим в BGP AS, с 2-я аплинками.
Главная цель - полная горячая отказоустойчивость, реализованная на всех компонентах инфраструктуры, как связи так и виртуализации.
Вторая цель это возможность проверки соединений  к самим  сервисам внутри ВПН, т.к. при обычном построении IPSEC фазы 2 всегда указываются IP конечных хостов (сетей) к которым у меня нет доступа, чтобы  прямо с них проверить.
Третья цель это не мусорить маршрутизацию внутри своей локальной сети, адресами контрагентов, и решить возможные проблемы при их совпадении.
Для решения этих проблем выделил виртуальный IP адрес на pfsence, который разделяется между нодами (CARP)  pfsence и указал его в качестве нашего внутреннего для фазы 2 (для контрагентов). На этот же  виртуальный IP повесил port-forwarding с произвольными (но систематизированными) TCP портами, начиная с 5000, последовательно примапливая каждый следующий порт к необходимому TCP сервису внутри VPN:
Pfsence-virt-IP:5000->insideVPN-IP:80
Pfsence-virt-IP:5001->insideVPN-IP:443
и т.д.

Таким образом для клиента с нашей стороны полностью подменивается и dst:port , а для сервера на стороне контрагента  подменивается src (и port) и все запросы приходят с Pfsence-virt-IP.

Обычно это делается  прописыванием 2-х правил в секции NAT: port-forward и outbound ,
сначала (NAT->port-forward) начинаем слушать на нужном порту, подменяем dst:port и посылаем внутрь pfsence, затем на выходном интерфейсе (NAT->outbound) подмениваем src.
всё это прекрасно работает для статических интерфейсов. Но с IPSEC трафиком это не проходит, хотя  в настройках NAT->outbound есть интерфейс IPSEC, всё равно всё шлётся согласно существующей статической маршрутизации, т.е. не уходит в интерфейс IPSEC (pfsence не понимает что есть connected "insideVPN-IP" через IPSEC) и NAT-outbound не работает, и действительно, в какой из множества живых IPSEC его посылать?.
Как оказалось это связано с особенностями обработок цепочек фаервола при IPSEC.
Решается это применением NAT/BINAT в самой настройкt фазы 2 IPSEC подключения.

Далее приведу 2 примера полного Порт-IP маппинга для обычных интерфейсов и для IPSEC.

1) Между обычными интерфейсами:

Внутренний хост  10.143.8.26 цель которого попасть на 10.0.1.186:80, у  10.143.8.26 нет возможности быть смаршрутизированным на 10.0.1.186, но есть возможность достигнуть 10.129.170.130 (виртуальный IP pfsence) на  интерфейсе ОРТ2.
Pfsence не является шлюзом и пропускает простой транзитный трафик.
10.0.1.128 это IP LAN интерфейса pfsence, хост 10.0.1.186  не имеет маршрутной информации о 10.143.8.26, но достижим с 10.0.1.128. Выберем порт 9191, который будет слушать на 10.129.170.130.
Для этого прописываем в разделе:

принимаем подключение с определенного IP  10.143.8.26 (указываем в advanced option), иначе будет создано (автоматически в разделе Rules/OPT2) правило которое разрешит ВСЕМ доступ к данному форвардингу: 10.129.170.130:9191
Обязательно пишем дескрипшен, чтобы потом найти созданное автоматом правило в Rules, оно будет таким: "NAT <desc...>"

Затем создаем ещё одну трансляцию, но уже outbound:

Здесь указываем, что выходя через LAN (а определяется это статической маршрутизацией), то подменить для совпадающих IP , src на "Interface Address".

2) Маппинг в VPN

Внутренний хост  10.30.0.62 (которому надо через ВПН подключиться (в идеале) к внешнему 192.168.99.1)

Виртуальный IP на pfsence (Pfsence-virt-IP)  10.129.170.130 , он доступен внутренним хостам (и 10.30.0.62) без дополнительной маршрутизации. 10.129.170.130 будет слушать на 5000 порту, 10.129.170.130 также является нашим внутренним IP для VPN (т.е. у него 2 независимых роли, можно использовать и 2 разных IP).

Опускаю процесс поднятия IPSEC Phase 1 - он обычный.
Фазу 2 поднимаем для оговоренных с Той стороной пары IP адресов (сетей)   10.129.170.130 <->  192.168.99.1

Первое:
прописываем Port-Forward (аналогично пункту 1), в котором описываем подмену DST IP(:port) с 10.129.170.130:5000 на 192.168.99.1:80

Второе:
Для IPSEС обычный NAT - Outbound не работает, поэтому будем использовать опцию NAT/Binat в phase2 IPSEC соединения.
Добавляем еще одну запись phase2 (2-ю, 3-ю если понадобится), где указываем  SRC IP из нашей локальной сети, которое надо подменить IP на оговоренный для нас  с контрагентом (10.129.170.130).

IP на другой стороне VPN - 192.168.99.1 (оно знает только о 10.129.170.130).

Проверка скорости внутри локальной сети и увеличение сетевой производительности для windows 7-10

В последнее время участились жалобы на медленную передачу файлов по протоколу SMB в windows. Канал связи этим протоколом (SMB в один поток) и раньше не мог утилизироваться больше 20-30 % доступной скорости, а сейчас стал не более 5-10%. Ни подбор MTU, заведомо проходящий без фрагментации, ни повышение приоритета, ничего не помогает. Поэтому было решено прикрутить сервис альтернативной проверки скорости, не использующий прокол SMB и Проводник. Для это был найден  не очень загруженный Линукс с apache и установлен из github.com один из доступных HTML5 speedtest-еров.
процесс установки:

https://github.com/adolfintel/speedtest


============

смена MTU:


1) получаем список интерфейсов:

netsh interface ipv4 show subinterfaces

2) изменяем MTU:

netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent



так как это не помогает, то надо тюнить размер окна:



один из путей

netsh interface tcp set global autotuninglevel=disabled

netsh interface tcp set global rss=disabled

netsh interface tcp set global chimney=disabled

netsh interface tcp set global netdma=disabled

и изменить настройки адаптера:

--

полнее здесь: https://www.softjoys.pro/interesting/53

мне не помогло, но может поможет в другой ситуации



этот метод мне частично помог, особенно 1-й пункт (скорость увеличилась в 2 раза, с 5-10% до 10-20% от способности канала):

netsh interface tcp set heuristics wsh=disabled

netsh int tcp set global rss=enabled

netsh interface tcp set global autotuning=experimental

netsh interface tcp set global congestionprovider=ctcp
В заключении, как мне кажется, скорость теперь только функция от задержки,
и при задержках в 100 мс, добиться максимальной скорости по SMB практически невозможно. подробно тут:
https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

для проверки скорости скачивания через WEB можно опубликовать в WEB каталог с файлами, для этого надо добавить в конфигурационный файл apache (он может находиться в разным местах и названиях) секцию и убедиться, что модуль mod_autoindex  включен:



<Directory /usr/local/apache2/htdocs/listme>

  Options +Indexes
</Directory>
для правильного отображением названий файлов на русском языке необходимо добавить в файл .htaccess следующий код:
IndexOptions +Charset=UTF-8

--

Эмуляция port-mapping в cisco

Часто бывает необходимо, при пробросе  извне NAT вовнутрь сети, сменить не только destination, но и source (wan) IP  адреса, чтобы не заморачиваться с наличием маршрута по умолчанию на локальном устройстве куда идет перенаправление (в этом случае достаточно иметь локальную доступность (маршрутизацию) между пограничным роутером и  целевым внутренним  пунктом назначения). В Cisco появилась опция на интерфейсах ip nat enable (в дополнении к ip nat inside,outside), которая позволяет NAT-транслировать поток 2 раза, как по входу, так и по выходу одновременно. Т.е. входящие из WAN пакеты приходят на стандартный ip nat inside source..  (стандартная конструкция на интерфейсах: ip nat outside, inside), при этом подменивается только адрес назначения на локальный, но исх. адрес (wan ip) остается прежним. Затем мы можем включить ещё одну трансляцию, которая, для уже ранее преобразованного  destinaton IP, подменяет и source IP на применяемые во внутреннем интерфейсе. Этого нельзя было достигнуть раньше, т.к. надо было иметь роли inside, outside на обоих интерфейсах одновременно. Сейчас применив команду ip nat enable мы объясняем роутеру, что нам именно это и нужно. Конфиг выглядит примерно так:

interface Vlan1
description WAN
ip address 10.100.105.224 255.255.255.0
 ip nat outside
 ip nat enable
!
interface Vlan3
 description LAN
 ip address 192.168.224.1 255.255.255.0
 ip nat inside
 ip nat enable
!
ip route 10.144.0.0 255.255.0.0 192.168.224.8
!- узлы в сети 10.144.0.0/16 знают только 192.168.224.0/24, ни ничего не знает о 10.100.105.224
!- и других IP  (10.0.1.0/24) за WAN интерфейсом
ip route 10.0.1.0 255.255.255.0 10.100.105.1
!-- нат для приема из WAN соединений на 222 порт и пересылке его во внутрь на 10.144.0.157
!-- 22 порт
ip nat inside source static tcp 10.144.0.157 22 10.100.105.224 222 extendable
!--- подменяем исх. IP с 10.0.1.ХХХ на 192.168.224.1 (Vlan3)
ip nat source list 101 interface Vlan3 overload
!-- указываем что подменяем только для 10.144.0.157  порт 22
access-list 101 permit tcp 10.0.1.0 0.0.0.255 host 10.144.0.157 eq 22

Сети 10.0.1.0/24 и 10.144.0.0/16  не имеют никакой связности, и маршрутной информации друг о друге, маршруты по умолчанию указывают на другие роутеры и т.д. Но в итоге, с узлов сети 10.0.1.0/24 можно подключиться, через примапленный порт 222  (10.100.105.224 ) и уже с другого IP (192.168.224.1) инициировать подключение к 10.144.0.157 22.