МультиЛАН и маршрутизация
-
VLAN, с которого http (s) необходимо пустить через UG WEB Filter^
WAN, в одной подсети с UG Web Filter:
Правило "разрешить любой траффик" не работало как надо на этом WANе, пакеты от UG Web Filter не возвращаются обратно в LAN1.
Я уже подумал было, что нужно WAN_UGFIL прописать как дефолтовый, в настройках завернуть его через проксю, а на другой WAN правилами направлять трафик из VLANов, которые будут ходить мимо прокси.
Может вы что посоветуете?
-
@rubezhanin
Wan_UGFIL - виртуальный или физический интерфейс ? -
WAN'ы оба виртуальные, на одной карточке.
-
@rubezhanin
Попробуйте сделать NAT OUTBOUND на WAN_UGFL для сети Lan1 net -
@rubezhanin
И еще - каша какая-то с правилами на WAN_UGFIL
Например , как может быть источником пакета на входе интерфейса адрес из сети LAN1 net ?
И последнее правило я тоже не понимаюПравила , которые задаются на интерфейсах (не плавающие) , они работают на вход
-
Эти правила я прибью. Разрешу весь трафик. Не обращайте внимания на это.
Вот с аутбоунд немного не соображу ... Покурю доку.
-
@rubezhanin
Ничего сложного
Просто вы поменяете адрес исходящего пакета источника с LAN1 NET адреса на WAN_UGFIL адрес
Запустите tcpdump или на pf или UserGate Web Filter (он же на базе Linux-а ? ) и посмотрите , что происходит с пакетом . -
@Konstanti said in МультиЛАН и маршрутизация:
@rubezhanin
Попробуйте сделать NAT OUTBOUND на WAN_UGFL для сети Lan1 netА можно пример? Чет совсем не соображу ((
-
@rubezhanin
Здесь Вам надо самому заполнить то , что нужно
И интерфейс и источник и назначение ( возможно , порты)
tcpdump запускали ?
-
да. только не пойму почему все пакеты нулевой длины ... О_о
192.168.1.253.52614 > 192.168.3.1.8090: Flags [S], cksum 0x52e2 (correct), seq 2760500276, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 192.168.1.253.52615 > 192.168.3.1.8090: Flags [S], cksum 0xa6f4 (correct), seq 867303673, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 192.168.1.253.52614 > 192.168.3.1.8090: Flags [S], cksum 0x66f1 (correct), seq 2760500276, win 8192, options [mss 1460,nop,nop,sackOK], length 0 192.168.1.253.52615 > 192.168.3.1.8090: Flags [S], cksum 0xbb03 (correct), seq 867303673, win 8192, options [mss 1460,nop,nop,sackOK], length 0 192.168.1.253.52616 > 192.168.3.1.8090: Flags [S], cksum 0xd02d (correct), seq 2768856679, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 192.168.1.253.52617 > 192.168.3.1.8090: Flags [S], cksum 0x1760 (correct), seq 3152283737, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 -
@rubezhanin Идея с NAT через IP address WAN_UGFIL интерфейса позволит проверить, знает ли UserGate маршрут к сети LAN1.
То есть в скриншоте, приложенный @Konstanti нужно установить интерфейс WAN_UGFIL, source address LAN1 сеть, destination - IP address UserGate прокси, можно порты назначения еще указать. -
@rubezhanin said in МультиЛАН и маршрутизация:
да. только не пойму почему все пакеты нулевой длины ... О_о
Так вы внутрь пакетов загляните wireshark'ом.
Хм, может имеет смысл в System>Advanced>Networking отключить "Hardware Checksum Offloading" и ребутнуться.
-
@rubezhanin Попробуйте отключить
System/Advanced/Networking
-
@rubezhanin Они нулевой длины
потому что у Вас от хоста 192.168.3.1 нет ответа на пакет SYN
т е нет установки соединения
тройное рукопожатие не выполняется
-
This post is deleted! -
This post is deleted! -
@Konstanti said in МультиЛАН и маршрутизация:
@rubezhanin
Попробуйте сделать NAT OUTBOUND на WAN_UGFL для сети Lan1 netЗачем там НАТ?
Завернуть можно правилами Port Forwarding на ЛАН.
Т.е все .что идет из ЛАН во вне к HTTPS завертывается на адрес и порт UG.
После создания правила порт форвард проследить, чтобы правило, созданное им на ЛАН было повыше.
У меня так все DNS и NTP от клиентов на LAN addr пф завернуты.
Всё. -
Все-таки я этот прокси не победил пока и подзабил. Пустил траффик в обход. Будет время - докручу.
Пока расходимсо ...
