На сервере / брандмауэре SSH (192.168.2.3), за которым находится локальная сеть, скажем 192.168.2.1/30, будут ли попытки подключения, сделанные внутренними компьютерами сети 192.168.2.1/30, интерпретироваться брандмауэром как входящие или исходящие соединения?
Если они читаются как входящие или исходящие, должен ли я указывать блок адресов назначения или источника (192.168.2.1/30)? Или когда именно нужны параметры -d или -s?
Я понимаю следующее: если я хочу, чтобы эти внутренние машины устанавливали какие-либо новые соединения с внешним миром, правило звучит так.
iptables -A OUTPUT -s 192.168.2.8/30 -m state --state NEW -j ACCEPT
и если бы SSH-сервер хотел создать новые ssh-соединения с внешним миром, правилом было бы это
iptables -A OUTPUT -p tcp --sport 22 -m state --state NEW -j ACCEPT
В этом случае мне следует не указывать IP-адрес ssh-сервера или включать его в правило?
Большое спасибо.
INPUT и OUTPUT определены исключительно относительно системы, на которой iptables это работает. Другими словами, iptables не заботится о том, какие системы есть на каком-либо из его интерфейсов; неважно, подключается ли интерфейс к вашей доверенной LAN, или DMZ, или резервуар, полный акул с ноутбуками.
INPUT всегда относится к трафику входящий интерфейс извне с целью локального завершения. OUTPUT относится к трафику, который исходит из местного и собирается покинуть через интерфейс. FORWARD относится к трафику, который проходит через один интерфейс и выходит прямо через другой.
Первое, что вы цитируете выше, является посредником для трафика от 192.168.2.0/30 LAN на одном интерфейсе, с внешним миром на другом, так что оба должны быть в FORWARD цепь. Второй передает трафик от брандмауэра к миру, так что все в порядке.
Хотя могу я попутно добавить, что это не большая часть локальной сети, и вам, вероятно, следует проверить эту сетевую маску, потому что брандмауэр имеет недопустимый адрес в контексте локальной сети (это широковещательный адрес, который не должен назначаться одному хосту). ). Видеть наш знаменитый канонический вопрос о подсетях ipv4 для дальнейшего обсуждения.