iptabeles : как узнать заранее какой sport порт будет для сервера ?

[Karl500]

это оно всегда: sport будет равен dport для сервиса ?

Нет конечно, зависит от сервиса.

[_art_]

это оно всегда: sport будет равен dport для сервиса ?

Нет конечно, зависит от сервиса.

Допустим, апач сервер. Локально слушает 81 порт. Но из вне запросы идут от стандартоного 80-го.
Какой в этом случае будет spot и dport ?

Или sshd: настроен на прослушку только 2277 порта. В этом случае какой будет sport и dport ?

[fisher74]

Ну что ж у Вас никак чакры не раскроются...
Вот смотрите. На пальцах.
Есть отделение почты России, в котором есть окошко (будем считать, что оно одно). Так и определим: отделение - это адрес сервиса, окошко - это порт этого сервиса (http = 80).
Клиент подходит к этому окошку и начинает туда говорить: "Здравствуйте, можно у Вас спросить?" Эта фраза, ни что иное, как пакет сообщения (ну типа устанавливается соединение). Этот пакет вылетает из головы этого клиента, который является частью тела source port (sport) (и номер его какой угодно, но обычно что-то между 1024 и 65535), и летит в окошко, которое будет являться destination port (dport = 80).
Клиенты (адреса) могут быть разными и головы (порты) у них могут быть разными, то есть номера их портов динамические. А вот окошко одно, и номер порта у него статический = 80.

Дальше из окошка отвечают: "Да, конечно". А вот тут ситуация меняется. Теперь пакет сообщения летит из того же окошка. То есть номер порта тот же(80), а вот функция у него уже сменилась и он значится, как sport.  А голова клиента становится dport... но всё та же, что перед этим говорила, то есть номер порта тот же (из 1024-65535).
Вот так вот dport становится sport-ом и обратно.

А теперь ситуация, когда это происходит с осложнениями. Клиент (через такой же динамический порт с номером 1024-65535) перетёр с оператором (по протоколу ftp, тут уже порт сервиса будет равным 21), что он хочет получить посылку  и после всех подготовок эту посылку нужно передать. И посылка будет передаваться руками (порты замечу совсем другие) через (по протоколу ftp-data)... а, допустим, просто через верх перебросят. Теперь уже клиент раскрывает свои клешни (уже совсем другой dport) и ловит посылку посланную с рук оператора (другой sport) через заграждение.
Вот как-то так.
Может не много кривовато, но как смог.

[AnrDaemon]

Но из вне запросы идут от стандартоного 80-го.

C какого перепугу? Начнём с того, что 80-й порт клиентским программам вообще недоступен.

[_art_]

Ну что ж у Вас никак чакры не раскроются...
Вот смотрите. На пальцах.
Есть отделение почты России, в котором есть окошко (будем считать, что оно одно). Так и определим: отделение - это адрес сервиса, окошко - это порт этого сервиса (http = 80).
Клиент подходит к этому окошку и начинает туда говорить: "Здравствуйте, можно у Вас спросить?" Эта фраза, ни что иное, как пакет сообщения (ну типа устанавливается соединение). Этот пакет вылетает из головы этого клиента, который является частью тела source port (sport) (и номер его какой угодно, но обычно что-то между 1024 и 65535), и летит в окошко, которое будет являться destination port (dport = 80).
Клиенты (адреса) могут быть разными и головы (порты) у них могут быть разными, то есть номера их портов динамические. А вот окошко одно, и номер порта у него статический = 80.

Дальше из окошка отвечают: "Да, конечно". А вот тут ситуация меняется. Теперь пакет сообщения летит из того же окошка. То есть номер порта тот же(80), а вот функция у него уже сменилась и он значится, как sport.  А голова клиента становится dport... но всё та же, что перед этим говорила, то есть номер порта тот же (из 1024-65535).
Вот так вот dport становится sport-ом и обратно.

А теперь ситуация, когда это происходит с осложнениями. Клиент (через такой же динамический порт с номером 1024-65535) перетёр с оператором (по протоколу ftp, тут уже порт сервиса будет равным 21), что он хочет получить посылку  и после всех подготовок эту посылку нужно передать. И посылка будет передаваться руками (порты замечу совсем другие) через (по протоколу ftp-data)... а, допустим, просто через верх перебросят. Теперь уже клиент раскрывает свои клешни (уже совсем другой dport) и ловит посылку посланную с рук оператора (другой sport) через заграждение.
Вот как-то так.
Может не много кривовато, но как смог.

Спасибо.

То есть:
С позиции сервера (для сервера)
             dport - это все те порты, которые открыты и смотрят в мир ( все открытые сервисы ) к которым обращается клиенты
             sport - это все те порты, с которых получаем пакеты от клиентов

С позиции клиента (для клиента)
             dport - порт, на который отвечает сервер клиенту
             sport - порт, с которого отвечает сервер

Тогда снова тот пример с ssh:
получается, что для сервера, sport может быть любой в диапазоне 1024-65535 ? То есть теоретически даже никак и не узнать, с какого порта пришел ответ, чтобы, к примеру, отфильтровать таким образом output ?

[fisher74]

(Нажмите, чтобы показать/скрыть)

датваюжматьто

sport и dport рассматриваются только с позиции направления движения пакета: sport - от кого летит, dport - кому летит пакет. И фиолетово кто из них сервис, а кто клиент.
Сервис всегда слушает и отвечает по одному и тому же назначенному номеру порта (стандартные http = 80, 8080; https 443,...).
Клиент гадит с любого пользовательского порта(1024-65535), обычно выбранного локально системой клиента динамически.

(Нажмите, чтобы показать/скрыть)

ЗЫ как я уже говорил, сервис для некоторых действий, может запросить у клиента новое соединение, но это уже другая история.

[_art_]

Суть понял.

> Сервер будет отвечать с того же порта, на который получил запрос на соединение. На этом знании и строятся правила.

Просто мысли возникли по описанию правил:
То есть при фильтрации INPUT, dport всегда будет равен sport, который в свою очередь будет равен номеру прослушивающего порта ?
Мы ведь пишем правила на стороне сервера ( с позиции сервера ).
Потому и непонятка возникала с этими sport и dport.

[fisher74]

сделаю вот такую поправочку

То есть при фильтрации INPUT, dport всегда будет равен sport в цепочке OUPTUT

так будет правильно
Сначала порт слушает (dport в цепочке INPUT), а только потом начинает вещать (sport в цепочке OUTPUT)

[_art_]

dport всегда будет равен sport в цепочке OUPTUT - ОК

При создании правила в INPUT, я могу укзаать еще sport ? Или только dport ?


А при создании правила в OUTPUT, я могу укзаать еще dport ? Или только sport ?

[fisher74]

dport всегда будет равен sport в цепочке OUPTUT - ОК

Опять двадцать пять. Зачем урезаете предложение? В этом виде, выражение неверно.

При создании правила в INPUT, я могу укзаать еще sport ?

Можете. Только подумайте что именно туда писать.

Или только dport ?

Вам решать.

А при создании правила в OUTPUT

тоже самое, что и в предыдущем случае...

Извините, я устал с бороться с Вашими тараканами.

[alexxnight]

Пример с почтой хороший:
ip сервера - адрес почтового отделения (номер дома, улица, город, страна)
port сервера - окошечко с теткой внутри

ip клиента - его домашний адрес (номер дома, улица, город, страна)
port клиента - номер его квартиры

В каком случае port сервера (dport) будет равен port клиента (sport)?
по аналогии с постой
В каком случае номер окошечка на почте (dport) будет равен номеру квартиры клиента (sport)?

[AnrDaemon]

Да не будет он ничему равен, не надо нести ахинею…
netfilter это не язык программирования. За пределами текущей цепочки у вас нет ничего, просто потому что этого нет.

[alexxnight]

Конечно вопрос, который я написал, бредовый.
Этот пример и нужен был для того, чтобы показать, что некорректно искать условие равенства sport и dport
О чем, собственно, было много сказано выше...

[_art_]

dport всегда будет равен sport в цепочке OUPTUT - ОК

Опять двадцать пять. Зачем урезаете предложение? В этом виде, выражение неверно.

При создании правила в INPUT, я могу укзаать еще sport ?

Можете. Только подумайте что именно туда писать.

Или только dport ?

Вам решать.

А при создании правила в OUTPUT

тоже самое, что и в предыдущем случае...

Извините, я устал с бороться с Вашими тараканами.

Уважаемый fisher74 , спасибо за ответы.

При создании правила в INPUT, я могу укзаать еще sport ?

Можете. Только подумайте что именно туда писать.

Туда писать номер порта, откуда пришел пакет ? То есть номер открытого порта со стороны клиентского приложения, котрое этот пакет послал, так ?

Это не тараканы, хочу понять суть.

Ну а главное, так это вот это: sport и dport рассматриваются только с позиции направления движения пакета: sport - от кого летит, dport - кому летит пакет. И фиолетово кто из них сервис, а кто клиент.

[alexxnight]

Когда вы открываете например браузер (клиентское приложение) и набираете в поисковой строке, там например:
"Клиент серверная архитектура", то вы как клиент делаете запрос с любого своего порта из диапазона 1024-65535, на https порт 443 сервера гугла.
Гугл, чтоб вы получили таки ответ на запрос, должен пропустить ваш запрос с вашего порта sport (1024-65535) на свой dport (443).