Рейтинг:0

Server

Мультишлюз работает с HAProxy и VPN?

user1352470

07.07.2023, 04:07

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

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

Будет ли приведенная ниже диаграмма делать то, что я ищу? Общая идея, приведенная ниже, заключается в настройке HAProxy, настройке шлюза по умолчанию для всех устройств так, чтобы он указывал на HAProxy, и чтобы HAProxy обрабатывал подключения к маршрутизаторам. К сожалению, я новичок во всей этой прокси и не уверен, что HAProxy сделает то, что я ищу.

Предлагаемая установка:

К вашему сведению, ниже показано, что у нас есть в настоящее время: шлюзы всех устройств указывают на шлюз маршрутизатора 1. Проблема заключается в том, что когда удаленные пользователи VPN через WAN-XYZ подключаются к шлюзу маршрутизатора 2, они не могут получить доступ к внутреннему веб-серверу. . Насколько я понимаю, эта проблема связана с тем, что шлюз по умолчанию на внутреннем веб-сервере установлен на шлюз маршрутизатора 1.

Текущая настройка:

Дополнительные примечания Маршрутизатор 2 будет маршрутизатором pfSense.

0 + 0

пфсенсе

Tom Yan

07.07.2023, 05:34

Не знаком с haproxy/балансировкой нагрузки, но моя первая мысль о вашем сценарии заключается в том, что вам нужно что-то вроде установки метки conntrack на основе исходного адреса L2 и установки fwmark (которая будет соответствовать правилу ip) для соответствующего отвечающие трафики, и они должны быть настроены непосредственно на хост-сервере. На самом деле я никогда не развертывал такую настройку «разделенной маршрутизации», но я думаю, что это возможно с nftables в Linux (поэтому я не знаю, есть ли у вашего веб-сервера Windows или BSD).

Ответить

Zac67

07.07.2023, 06:37

Не уверен насчет маршрутизатора pfSense, но с приличным маршрутизатором вы должны переместить маршрутизаторы интернет-провайдера из своей «плоской» сети и поместить маршрутизатор между ними и вашей локальной сетью. Достойный маршрутизатор должен иметь возможность возвращать трафик обратно провайдеру, откуда он исходит (для входящих соединений), и обеспечивать некоторую форму балансировки нагрузки (для исходящих соединений). Маршрутизация на основе политик на основе протокола или исходного IP-адреса также может работать хорошо. Все это должно работать без прокси (что может быть серьезной проблемой).

Ответить

Tom Yan

07.07.2023, 11:06

Кстати, если вы не можете заставить маршрутизаторы вашего интернет-провайдера выполнять *исходный* NAT для трафика из *Интернета*, я не думаю, что прокси имеет смысл / имеет значение, поскольку в конечном итоге ему нужно будет «разделить маршрут» *ответов* на основе исходный *MAC* адрес *оригинального* трафика. Прокси-сервер может пересылать ответы на соответствующие маршрутизаторы только в том случае, если *IP-адрес назначения* ответов может *указывать* маршрутизатор, на который они должны идти, что, в свою очередь, возможно только в том случае, если маршрутизаторы интернет-провайдера могут быть настроены для выполнения такого необычного источника. НАТ. (Кроме того, это не масштабируемо/нереалистично маскироваться под Интернет.)

Ответить

Рейтинг:0

Server

Tom Yan

07.07.2023, 09:48

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

Хост виртуальной машины действует как веб-сервер, а две виртуальные машины действуют как маршрутизаторы, одна из виртуальных машин действует как веб-клиент из «Интернета»:

Конфигурации на хосте ВМ (веб-сервер):

$ ip show dev bridge1
4: bridge1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    ссылка/эфир 3a:f6:7b:90:aa:bd brd ff:ff:ff:ff:ff:ff
    инет 192.168.254.3/24 охват глобальный мост1
       valid_lft навсегда
    inet6 fe80::38f6:7bff:fe90:aabd/64 ссылка на область видимости 
       valid_lft навсегда

$ ip show dev bridge2
5: bridge2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    ссылка/эфир 1a:6f:58:86:72:55 brd ff:ff:ff:ff:ff:ff
    ссылка на область inet6 fe80::186f:58ff:fe86:7255/64 
       valid_lft навсегда

(мост1 используется для моделирования локальной сети, и мост2 используется для имитации «Интернета», поэтому последнему не назначается адрес IPv4.)

$ IP-правило
0: из всех локальных поисковых систем
32765: из всех fwmark 0xb iif lo lookup 11
32766: из всех основных поисковых запросов
32767: из всех поисковых запросов по умолчанию

$ ip r показать таблицу main dev bridge1
10.10.10.0/24 через 192.168.254.1 
192.168.254.0/24 прото-ссылка на область ядра src 192.168.254.3 

$ ip r показать таблицу 11
10.10.10.0/24 через мост 192.168.254.2 dev1

(Здесь 192.168.254.1 предполагается, что он является «основным» шлюзом по умолчанию. если ло — это уточнение, которое приводит к тому, что правило применяется только к трафику, который исходит от самого хоста, другими словами, это, вероятно, не нужно, если только хост веб-сервера также не действует как своего рода маршрутизатор.)

$ sudo nft list набор правил
IP-адрес таблицы mangle {
    цепочка ввода {
        type filter hook input priority mangle; политика принять;
        ether saddr 52:54:00:bb:bb:bb ip saddr != 192.168.254.2 ct mark set 0x0000000b
    }

    выход цепи {
        тип route hook выходной приоритет mangle; политика принять;
        ct mark 0x0000000b метаметка установить ct mark
    }
}

(По всей видимости тип должно быть маршрут в вывод крючка цепь для этого, чтобы работать. Кроме того, трафик, исходящий от маршрутизаторов, в отличие от трафика, исходящего из «Интернета», можно дифференцировать по исходным IP-адресам, поэтому IP-адрес != 192.168.254.2 указывается для обозначения факта; на самом деле это, вероятно, ненужное уточнение.)

Вот tcpdump захват на хосте ВМ/веб-сервере двух завиток выполнить на виртуальной машине веб-клиента:

$ sudo tcpdump -eni bridge1 TCP-порт 80
tcpdump: подробный вывод подавлен, используйте -v[v]... для полного декодирования протокола
прослушивание на мосту 1, тип канала EN10MB (Ethernet), длина моментального снимка 262144 байта
16:54:43.602105 52:54:00:aa:aa:aa > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), длина 74: 10.10.10.3.33132 > 192.168.254.3.80: Флаги [S], seq 2320058647, win 64240, параметры [mss 1460,sackOK,TS val 3412464375 ecr 0,nop,wscale 7], длина 0
16:54:43.602185 3a:f6:7b:90:aa:bd > 52:54:00:aa:aa:aa, ethertype IPv4 (0x0800), длина 74: 192.168.254.3.80 > 10.10.10.3.33132: Флаги [S.], seq 3987984937, ack 2320058648, win 65160, options [mss 1460,sackOK,TS val 3768307023 ecr 3412464375,nop,wscale 7], длина 0
16:54:43.603460 52:54:00:aa:aa:aa > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), длина 66: 10.10.10.3.33132 > 192.168.254.3.80: Флаги [.], ack 1, win 502, options [nop,nop,TS val 3412464377 ecr 3768307023], длина 0
16:54:43.604003 52:54:00:aa:aa:aa > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), длина 140: 10.10.10.3.33132 > 192.168.254.3.80: Флаги [P.], seq 1:75, ack 1, win 502, параметры [nop,nop,TS val 3412464377 ecr 3768307023], длина 74: HTTP: GET / HTTP/1.1
16:54:43.604054 3a:f6:7b:90:aa:bd > 52:54:00:aa:aa:aa, ethertype IPv4 (0x0800), длина 66: 192.168.254.3.80 > 10.10.10.3.33132: Флаги [.], ack 75, win 509, options [nop,nop,TS val 3768307025 ecr 3412464377], длина 0
16:54:43.604238 3a:f6:7b:90:aa:bd > 52:54:00:aa:aa:aa, ethertype IPv4 (0x0800), длина 329: 192.168.254.3.80 > 10.10.10.3.33132: Флаги [P.], seq 1:264, ack 75, win 509, options [nop,nop,TS val 3768307025 ecr 3412464377], длина 263: HTTP: HTTP/1.1 200 OK
16:54:43.604636 52:54:00:aa:aa:aa > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), длина 66: 10.10.10.3.33132 > 192.168.254.3.80: Флаги [.], ack 264, win 501, options [nop,nop,TS val 3412464378 ecr 3768307025], длина 0
16:54:43.605112 52:54:00:aa:aa:aa > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), длина 66: 10.10.10.3.33132 > 192.168.254.3.80: Флаги [F.], seq 75, ack 264, win 501, options [nop,nop,TS val 3412464379 ecr 3768307025], длина 0
16:54:43.605133 3a:f6:7b:90:aa:bd > 52:54:00:aa:aa:aa, ethertype IPv4 (0x0800), длина 66: 192.168.254.3.80 > 10.10.10.3.33132: Флаги [F.], seq 264, ack 76, win 509, options [nop,nop,TS val 3768307026 ecr 3412464379], длина 0
16:54:43.605270 52:54:00:aa:aa:aa > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), длина 66: 10.10.10.3.33132 > 192.168.254.3.80: Флаги [.], ack 265, win 501, options [nop,nop,TS val 3412464379 ecr 3768307026], длина 0

16:54:47.528893 52:54:00:bb:bb:bb > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), длина 74: 10.10.10.3.49270 > 192.168.254.3.80: Флаги [S], seq 1866708541, win 64240, параметры [mss 1460,sackOK,TS val 1196345946 ecr 0,nop,wscale 7], длина 0
16:54:47.528977 3a:f6:7b:90:aa:bd > 52:54:00:bb:bb:bb, ethertype IPv4 (0x0800), длина 74: 192.168.254.3.80 > 10.10.10.3.49270: Флаги [S.], seq 1756841838, ack 1866708542, win 65160, options [mss 1460,sackOK,TS val 3768310949 ecr 1196345946,nop,wscale 7], длина 0
16:54:47.530210 52:54:00:bb:bb:bb > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), длина 66: 10.10.10.3.49270 > 192.168.254.3.80: Флаги [.], ack 1, win 502, options [nop,nop,TS val 1196345947 ecr 3768310949], длина 0
16:54:47.530535 52:54:00:bb:bb:bb > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), длина 140: 10.10.10.3.49270 > 192.168.254.3.80: Флаги [P.], seq 1:75, ack 1, win 502, опции [nop,nop,TS val 1196345948 ecr 3768310949], длина 74: HTTP: GET / HTTP/1.1
16:54:47.530588 3a:f6:7b:90:aa:bd > 52:54:00:bb:bb:bb, ethertype IPv4 (0x0800), длина 66: 192.168.254.3.80 > 10.10.10.3.49270: Флаги [.], ack 75, win 509, options [nop,nop,TS val 3768310951 ecr 1196345948], длина 0
16:54:47.530744 3a:f6:7b:90:aa:bd > 52:54:00:bb:bb:bb, ethertype IPv4 (0x0800), длина 329: 192.168.254.3.80 > 10.10.10.3.49270: Флаги [P.], seq 1:264, ack 75, win 509, options [nop,nop,TS val 3768310951 ecr 1196345948], длина 263: HTTP: HTTP/1.1 200 OK
16:54:47.531434 52:54:00:bb:bb:bb > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), длина 66: 10.10.10.3.49270 > 192.168.254.3.80: Флаги [.], ack 264, win 501, options [nop,nop,TS val 1196345949 ecr 3768310951], длина 0
16:54:47.532994 52:54:00:bb:bb:bb > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), длина 66: 10.10.10.3.49270 > 192.168.254.3.80: Флаги [F.], seq 75, ack 264, win 501, options [nop,nop,TS val 1196345951 ecr 3768310951], длина 0
16:54:47.533092 3a:f6:7b:90:aa:bd > 52:54:00:bb:bb:bb, ethertype IPv4 (0x0800), длина 66: 192.168.254.3.80 > 10.10.10.3.49270: Флаги [F.], seq 264, ack 76, win 509, options [nop,nop,TS val 3768310954 ecr 1196345951], длина 0
16:54:47.533925 52:54:00:bb:bb:bb > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), длина 66: 10.10.10.3.49270 > 192.168.254.3.80: Флаги [.], ack 265, win 501, options [nop,nop,TS val 1196345951 ecr 3768310954], длина 0
^ С
20 пакетов захвачено
20 пакетов, полученных фильтром
0 пакетов отброшено ядром

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

Обоснование набора правил nftable

ct отметка параметр в хук вход chain приведет к тому, что метка будет установлена для всех потоков одного и того же «соединения». (Я не/не могу углубляться в это, но если вы хотите узнать об этом больше, изучите «conntrack».) Поэтому в вывод крючка цепочке вы можете «выбрать» соответствующие ответы с помощью ct отметка соответствие, и выполнить мета отметка установить ct отметку на них, что означает установить метаметка на ответы того же значения, что и ct отметка (т.е. 0xb, что является произвольным значением, кстати). (Вместо этого вы также можете установить другое значение.)

метаметка соответствует fwmark в правиле ip и, следовательно, лишняя таблица маршрутизации (11 в примере, что также является произвольным значением) будет искаться трафик с метаметка что равно fwmark в правиле, перед (из-за более низкого значения приоритета) таблица маршрутов главный просматривается.

Так как в таблице маршрутов 11 есть маршрут для 10.10.10.0/24 с другим nexthop (т.е. с помощью) из таблицы маршрутизации главный, выбранные ответы будут отправлены на «правильный» маршрутизатор. (Дальнейший поиск не выполняется, если есть маршрут, который «покрывает» адрес назначения.)

Хотя 10.10.10.0/24 используется вместо По умолчанию он же 0.0.0.0/0 и «маршрутизаторы» подключены к одному и тому же мосту рядом с хостом веб-клиента для имитации реального Интернета, это не должно мешать работе тренировки в реальной ситуации.

0 + 0

Tom Yan

07.07.2023, 10:38

Подобное упражнение, вероятно, может быть развернуто с промежуточным хостом маршрутизатора, и в этом случае правила настройки ct и meta mark должны использоваться с цепочкой «перехвата предварительной маршрутизации», я думаю. Но тогда может потребоваться использование промежуточного маршрутизатора в качестве следующего перехода/шлюза для подсети LAN на обоих маршрутизаторах интернет-провайдера, что может оказаться сложной или невозможной задачей. (Ну, или, может быть, вы можете сделать многоуровневый DNAT / переадресацию портов, но это тоже может быть неприятно и проблематично ... если вообще возможно)

Ответить

Admin