Исправление
crypt,
(текущая версия)
:
я уже в виртуальной машине iptables поднял, а трафик на хабр закрыт через DNS. когда я проверял, пакеты по всем направлениям падали в одну копилку и я должен был их подхватывать, продумывая порядок правил. при этом используются совершенно бессмысленные recv/xmit/via директивы, потому что пакет может быть recv/xmit с разных сторон интерфейса и всеравно попадет в ту же кучу, что и транзитный пакет. при натировании, бриджовании, виртуальных интерфейсах направление и порядок прохождения пакетов определить становится совершенно невозможно. Linux файрвол удачно сепарирует пакеты. в нем фактически на входе стоит глобальный recv/xmit/via фильтр, который определяет дальнейшую цепочку прохождения пакета и пакет via (forward в Linux терминологии) никогда не будет спутан с recv (input) или xmit (output).
вовсе не обязательно файрвол, который работает на уровне ядра, должен быть полностью переписан. совершенно логично иметь какой-нибудь ядерный hook для передачи пакета файрволу, вот и все. я думаю, что так pf попал в солярис. это адаптированный по мелочи код из OpenBSD, он «опенбездешный». а если ты мне говоришь, что во FreeBSD кто-то что-то основательно переписал в 2014 году, то это означает совсем другое. это заметное расхождение кодовой базы, в том числе и по поведению в смысле синтаксиса команд (то, что на мой взгляд плохо в первую очередь). по моим понятиям, код pf должен бы регулярно синхронизироваться с OBSD.
Исправление
crypt,
:
я уже в виртуальной машине iptables поднял, а трафик на хабр закрыт через DNS. когда я проверял, пакеты по всем направлениям падали в одну копилку и я должен был их подхватывать, продумывая порядок правил. при этом используются совершенно бессмысленные recv/xmit/via директивы, потому что пакет может быть recv/xmit с разных сторон интерфейса и всеравно попадет в ту же кучу, что и транзитный пакет. при натировании, бриджовании, виртуальных интерфейсах направление и порядок прохождения пакетов определить становится совершенно невозможно. Linux файрвол удачно сепарирует пакеты. в нем фактически на входе стоит глобальный recv/xmit/via фильтр, который определяет дальнейшую цепочку прохождения пакета и пакет via (forward в Linux терминологии) никогда не будет спутан с recv (input) или xmit (output).
вовсе не обязательно файрвол, который работает на уровне ядра, должен быть полностью переписан. совершенно логично иметь какой-нибудь ядерный hook для передачи пакета файрволу, вот и все. я думаю, что так pf попал в солярис. это адаптированный по мелочи код из OpenBSD, он «опенбездешный». а если ты мне говоришь, что во FreeBSD кто-то что-то основательно переписал в 2014 году, то это означает совсем другое. это заметное расхождение кодовой базы, в том числе и по поведению в смысле синтаксиса команд (то, что на мой взгляд плохо в первую очередь).
Исправление
crypt,
:
я уже в виртуальной машине iptables поднял, а трафик на хабр закрыт через DNS. когда я проверял, пакеты по всем направлениям падали в одну копилку и я должен был их подхватывать, продумывая порядок правил. при этом используются совершенно бессмысленные recv/xmit/via директивы, потому что пакет может быть recv/xmit с разных сторон интерфейса. при натировании, бриджовании, виртуальных интерфейсах направление и порядок прохождения пакетов определить становится совершенно невозможно. Linux файрвол удачно сепарирует пакеты. в нем фактически на входе стоит глобальный recv/xmit/via фильтр, который определяет дальнейшую цепочку прохождения пакета и пакет via (forward в Linux терминологии) никогда не будет спутан с recv (input) или xmit (output).
вовсе не обязательно файрвол, который работает на уровне ядра, должен быть полностью переписан. совершенно логично иметь какой-нибудь ядерный hook для передачи пакета файрволу, вот и все. я думаю, что так pf попал в солярис. это адаптированный по мелочи код из OpenBSD, он «опенбездешный». а если ты мне говоришь, что во FreeBSD кто-то что-то основательно переписал в 2014 году, то это означает совсем другое. это заметное расхождение кодовой базы, в том числе и по поведению в смысле синтаксиса команд (то, что на мой взгляд плохо в первую очередь).
Исходная версия
crypt,
:
я уже в виртуальной машине iptables поднял, а трафик на хабр закрыт через DNS. когда я проверял, пакеты по всем направлениям падали в одну копилку и я должен был их подхватывать, продумывая порядок правил. при этом используются совершенно бессмысленные recv/xmit/via директивы, потому что пакет может быть recv/xmit с разных сторон интерфейса. при натировании, бриджовании, виртуальных интерфейсах направление и порядок прохождения пакетов определить становится совершенно невозможно. Linux файрвол удачно сепарирует пакеты. в нем фактически на входе стоит глобальный recv/xmit/via фильтр, который определяет дальнейшую цепочку прохождения пакета и пакет via никогда не будет спутан с recv или xmit.
вовсе не обязательно файрвол, который работает на уровне ядра, должен быть полностью переписан. совершенно логично иметь какой-нибудь ядерный hook для передачи пакета файрволу, вот и все. я думаю, что так pf попал в солярис. это адаптированный по мелочи код из OpenBSD, он «опенбездешный». а если ты мне говоришь, что во FreeBSD кто-то что-то основательно переписал в 2014 году, то это означает совсем другое. это заметное расхождение кодовой базы, в том числе и по поведению в смысле синтаксиса команд (то, что на мой взгляд плохо в первую очередь).