Failover и Port forward есть несколько вопросов.
-
Да, у каждого вана свой Дефаулт Гейтвей
-
Можно tcpdump с обоих интерфейсов для пинга на OPT интерфейс? Хочу посмотреть, как приходит по одному, уходит по другому.
-
Может из-за этого?
…
Outbound traffic to the InternetAll services running locally on pfSense will strictly obey the system's routing table. This means they go out the primary WAN unless you have static routes defined that match the traffic. This only applies to services which initiate connections to the Internet, such as the DNS forwarder, and several packages such as squid.
…По крайней мере у меня тоже так. Есть хост в DMZ-LAN с белым IP выданным провайдером подключенным к OPT-WAN. Соответственно, и ходят снаружи на этот хост все через OPT. Но! Если я извне сделаю до него traceroute, то он покажет, что маршрут прошел через WAN т.к. на предпоследнем хопе pfsense генерит ответ destination unreachable от себя, и идет этот ответ через WAN. С провайдером выясняли в свое время почему все так ходит.
-
прошу прощения. но я ошибся.. прсото в тспдампе и на одном и на другом инт-йсе вместо соответсвующего ип адреса всегда писалось имя хоста самого пфсенса, что меня запутало при беглом анализе. При более внимательном изучении выяснилось, что на какой ип пришел пакет icmp запроса, с такого интерфейса и ипа уходит ответ. Это верно как для самого пфсенса так и для портов прокинутых на внутренние машины. В том числе когда с двух внешних ип адресов прокидывается один и тот же порт на одну внутреннюю машину.
-
При более внимательном изучении выяснилось, что на какой ип пришел пакет icmp запроса, с такого интерфейса и ипа уходит ответ.
Понятно, значит для пинга заводится state. А с traceroute все сложнее, там же просто UDP пакет прилетает на порт > 30000. Вот и пойми что кто-то маршрут трассирует… Еще раз сейчас проверил, все так как я писал. Так что имейте ввиду.
-
При более внимательном изучении выяснилось, что на какой ип пришел пакет icmp запроса, с такого интерфейса и ипа уходит ответ.
Понятно, значит для пинга заводится state. А с traceroute все сложнее, там же просто UDP пакет прилетает на порт > 30000. Вот и пойми что кто-то маршрут трассирует… Еще раз сейчас проверил, все так как я писал. Так что имейте ввиду.
Вообще говоря, pfSense'у должно быть фиолетово (до некоторой степени) - хоть UDP, хоть ICMP.
-
Вообще говоря, pfSense'у должно быть фиолетово (до некоторой степени) - хоть UDP, хоть ICMP.
Думаю, не в моем случае. Единственное объяснение, которое я вижу, заключается в том, что:
на OPT-WAN с удаленного хоста от traceroute приходит UDP пакет с TTL=1 и назначением = хост в DMZ, (пусть заводится state: udp remote host:port -> DMZ host:port), но TTL обнуляется и пакет отбрасывается, после чего pfsense отправляет ICMP type=3 удаленному хосту.
Так вот, по какой-то причине (может потому, что state убивается вместе с пакетом, или потому, что pfsense игнорирует этот state, считая, что он описывает общение удаленного хоста с хостом в DMZ и к самому pfsense не относится) этот ICMP улетает не с OPT-WAN, а по дефолтному маршруту, т.е. с WAN. И в выводе traceroute мы видим WAN, хотя не видим провайдерского шлюза WAN (напротив видим шлюз OPT-WAN).
Вот парень мучался пару лет назад: http://forum.pfsense.org/index.php/topic,9171.0.html
в точности мой сетап, все так и осталось загадкой… -
Вообще говоря, pfSense'у должно быть фиолетово (до некоторой степени) - хоть UDP, хоть ICMP.
Думаю, не в моем случае. Единственное объяснение, которое я вижу, заключается в том, что:
на OPT-WAN с удаленного хоста от traceroute приходит UDP пакет с TTL=1 и назначением = хост в DMZ, (пусть заводится state: udp remote host:port -> DMZ host:port), но TTL обнуляется и пакет отбрасывается, после чего pfsense отправляет ICMP type=3 удаленному хосту.
Так вот, по какой-то причине (может потому, что state убивается вместе с пакетом, или потому, что pfsense игнорирует этот state, считая, что он описывает общение удаленного хоста с хостом в DMZ и к самому pfsense не относится) этот ICMP улетает не с OPT-WAN, а по дефолтному маршруту, т.е. с WAN. И в выводе traceroute мы видим WAN, хотя не видим провайдерского шлюза WAN (напротив видим шлюз OPT-WAN).
Вот парень мучался пару лет назад: http://forum.pfsense.org/index.php/topic,9171.0.html
в точности мой сетап, все так и осталось загадкой…Да, похоже на правду. Суть похоже в том, что ICMP-reply, который отсылается никаким образом не связан с
пусть заводится state: udp remote host:port -> DMZ host:port
и посему шлётся согласно таблицы маршрутов. Попробуй на pfSense создай static route на твой удалённый хост через OPT-WAN, должно правильно показать маршрут.
-
Да, конечно, с маршрутом все показывает правильно. Как ты понимаешь, это не выход из положения. Просто будем иметь ввиду, что есть у pfsense такая фича))
-
Да, конечно, с маршрутом все показывает правильно. Как ты понимаешь, это не выход из положения. Просто будем иметь ввиду, что есть у pfsense такая фича))
Согласен, но по крайней мере - есть логичное объяснение -)))