Как сообразить nat для конкретного сайта и порта?

Что значит

сообразить nat для конкретного сайта и порта?

быть может вопрос должен звучать - как перенаправить пакеты приходящие на внешний интерфейс шлюза на указанный адрес и порт другого сервера?

Нужно определить доступ к конкретному сайту и порту(в частности 2280). Думал подобное делается через nat.

Вероятно, у вас корпоративный шлюз, и вы не хотите, чтобы люди через него в интернете страдали фигней, но кому-то одному что-то одно все-таки надо в интернете делать.

Выход тут скорее такой:

1. nat наружу надо делать всем.

2. Наружу по умолчанию никого никуда не пускать.

3. Написать исключение для одного конкретного айпишника из локальной сети, которому таки можно ходить в то место интернета, в которое нужно.

Третий пункт можно также реализовать средствами прокси-сервера, если позволяет тип трафика (для идентификации ползователя, которому нужно открыть доступ, использовать айпишник, либо авторизацию на прокси - так надежнее).

Если же требуется открыть доступ к конкретному ресурсу не для одного пользователя, а для всех, то можно просто обойтись настройками tcp-ip-фильтрации (iptables).

Это с помощью правил для таблицы nat и делается, но для этого надо несколько условий:

1. написать правильно правило для таблицы nat.

2. написать правило для транзитных пакетов в таблице filter (forward)

3. разрешить передачу данных по уже установленным соединениям

4. указать серверу на который перенаправляете пакеты gateway, которым будет являться ваш шлюз

NAT нужно делать для всех, а ограничивать всё в цепочке FORWARD. Разрешить что нужно, а политику поставить в DROP. При этом нужно смотреть, и разрешать всё, что действительно нужно, а не только один порт. Если, допустим, на компьютере в локальной сети прописаны google-DNS или сервера провайдера, то нужно и 53 порт udp разрешить.

Если же вам нужно просто ограничить доступ к сайтам по url, порезать скорость или делать редирект с определенных сайтов на другие, то используйте для этих целей прокси - squid

Редирект портов можно осуществлять и без помощи iptables с помощью утилиты rinetd

Если же вам нужно просто ограничить доступ к сайтам по url, порезать скорость или делать редирект с определенных сайтов на другие, то используйте для этих целей прокси - squid

Стоит squid+sams. sams вставляет свои acl и т.п имеет свой редирект, «конфликтует» с настройками squid. Без sams настраивал доступы, все работало как нужно. Здесь не мое решение.

Примерно ясно, поправте если не так 1. Разрешаю ощение между подсети

iptables -A FORWARD -i eth0 -o eth1 -s 192.168.0.0/24 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -d 192.168.0.0/24 -j ACCEPT

iptables -A FORWARD -p tcp -o eth0 -d 212.45.16.145/32 --dport 2280 -j ACCEPT

iptables -P FORWARD DROP

iptables -A POSTROUTING -o eth0 -j MASQUERADE

И вопрос, важна ли иерархия? т.е. сначала разрешения потом запрещения, сначала forward потом INPUT?

ну во-первых настроите прероутинг входящих пакетов на внешний интерфейс, это запись в таблице нат, именно она и будет преобразовывать адрес и порт в поступающих пакетах:

-A PREROUTING -i eth0 -p tcp -m tcp --dport 1258 -j DNAT --to-destination 192.168.0.1:1258

затем добавьте правила для поддерживания установленных соединений:

-A FORWARD -d 192.168.0.0/24 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT

-A FORWARD -d 192.168.0.0/24 -p udp -m state --state RELATED,ESTABLISHED -jACCEPT

212.45.16.145

адрес должен быть из вашей локальной подсети 192.168.0.0/24

>212.45.16.145

адрес должен быть из вашей локальной подсети 192.168.0.0/24

Почему локальной подсети? Это же ip внешнего сайта к которому должен быть доступ.

А еще если на шлюзе есть squid то при правиле iptables -P FORWARD DROP, на свид надо делать редирект?

iptables -A PREROUTING -s 192.168.0.0/24 -i eth1 -p tcp -m multiport --dports 80,443 -j REDIRECT --to-ports 3128

Пробую как советуте, не получается:\

Такой маршрут работает, доступ ко всему с 1 ip

iptables -A FORWARD -s 192.168.3.54/32 -o eth0 -j ACCEPT

Вот скрипт

#/bin/bash

#iptables

# eth1 - локальная сеть, eth0 - инет

#Очищаем текущие правила
iptables -F
iptables -t nat -F
iptables -t filter -F
iptables -t mangle -F

echo O4istka

#Установим политики по умолчанию для трафика, не соответствующего ни одному из правил
#Запрет транзакций
iptables -P FORWARD DROP

echo Zpreti

#Правила 
#Разрешаем пакеты между  сетями
#Поддержка устоновленых соединений для наше сети
iptables -A FORWARD -d 192.168.0.0/16 -p tcp -m conntrack --ctstate RELATED,ESTABLISHED,DNAT -j ACCEPT
iptables -A FORWARD -d 192.168.0.0/16 -p udp -m conntrack --ctstate RELATED,ESTABLISHED,DNAT -j ACCEPT
#Разрешаем транзакции для конкретных усеров, сатов
#iptables -A FORWARD -s 192.168.3.54/32 -o eth0 -j ACCEPT

iptables -A FORWARD -p tcp -o eth0 -d 212.45.16.145/32 --dport 2280 -j ACCEPT

echo Pravila

#NATим всех
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

#Перенаправляем
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2280 -j DNAT --to-destination 192.168.3.54:2280

echo ipt zapisan

Блин уже весь мозг сломал:\ , пробовал по разному. Самый лучший результат: Разрешаю формардинг для ip, работает все для этого ip.

iptables -A FORWARD -s 192.168.3.54/32 -o eth0 -j ACCEPT

iptables -A FORWARD -p tcp --dport 2280 -s 192.168.3.54/32 -o eth0 -d albatrossvmc.marsat.ru  -j ACCEPT

через 5 минут работать перестает

Смотреть логи апача на стороне сайта, смотреть счетчики iptables на машине с фильтром - попадают ли пакеты в нужные правила.

-d albatrossvmc.marsat.ru

Все-таки урлы лучше сквидом фильтровать..

Все-таки урлы лучше сквидом фильтровать..

Я в курсе... Это костыль, от безысходности:\

На стороне сайта не посмотреть, не наше. Смотрел по tcpdump на шлюзе, пк посылает пакеты на dns, похоже не получает ответы. Открыть форвардинг по 53 порту?

смотреть счетчики iptables на машине с фильтром

Каким образом? log?

Открыть форвардинг по 53 порту?

У вас свой днс в конторе, или он посылает вовне? Если свой - то форвардинг непричем (если он только не в другой сети), если внешний - конечно, нужно открыть порт.

Ваще уж что-что, а днс обычно открыт для всех. Что, конечно, позволяет устанавливать туннели и гонять через них произвольный трафик, но это уже другой вопрос..

Каким образом? log?

watch -n 1 iptables -vnL

рядом с каждым правилом - счетчики заматченных пакетов.

Спасибо за советы, дело было в DNS, сделал форвардинг для 53 порта, все работает как нужно.

Тсталось понять, откуда брались 5 минут. ttl кеша какого-нибудь?

никогданикогданикогда не делайте -P <any_policy> DROP, лучше последним правилом в эту цепочку -j DROP

Да ладно, у нормальных посонов ipmi есть с удаленной консолью :)

А ещё если так сделать, и какое-нибудь правило закосячит (например, вместо ip там fqdn кто-нибудь напишет), то до -j drop дело не дойдет или дойдет не сразу - имеем дыру.

С другой стороны, действительно, есть риск отстрелить ногу.

В общем, насчет никогданикогданикогда я бы поспорил - думать надо в каждом случае :)

Да ладно, у нормальных посонов ipmi есть с удаленной консолью :)

Не у всех...

А ещё если так сделать, и какое-нибудь правило закосячит (например, вместо ip там fqdn кто-нибудь напишет), то до -j drop дело не дойдет или дойдет не сразу - имеем дыру.

Вот отсюда поподробнее... Последнее правило DROP дает аналогичный эффект политике DROP, со всеми вытекающими. В это правило попадет каждый пакет, который не попал в другие правила. Единственная возможность накосячить тут появляется только в пользовательской цепочке, где не будет дефолтного правила

Вот отсюда поподробнее

имеется в виду, что если iptables наткнется на правило в цепочке и будет пытаться его применить, резольвнув fqdn, но по какой-то причине fqdn резольвиться не будет, то процесс растянется, и на это время (пока не дойдет до DROP) возникнет дырка.

Я так понимаю он синхронно резолвит имя, а если так - тогда он тупо должен на это время класть на трафик и ждать ответа... Если же резолв асинхронный - то стоит очередь попавших в это правило, а все что до него не дошло уходит куда надо. Ну и писать fqdn в правилах пакетного фильтра в системе, где нет кеша dns, то еще извращение...

Мне рассказывали про такую как раз ситуацию, но из описания я не могу вспомнить, какая из двух версий имела место. Надо, чтоли, эксперимент поставить..