Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO
# iptables –A OUTPUT –t mangle –p tcp –dport telnet
-j TOS –set-tos Minimize-Delay
# iptables –A OUTPUT –t mangle –p tcp –dport ftp
-j TOS –set-tos Minimize-Delay
# iptables –A OUTPUT –t mangle –p tcp –dport ftp-data
-j TOS –set-tos Maximize-Throughput
15.5. Прозрачное проксирование с помощью netfilter, iproute2, ipchains и squid.
Этот раздел написал Рэм Нарул (Ram Narula), из "Internet for Education" (Таиланд).
Прозрачное проксирование — это обычное перенаправление серверу squid трафика, отправляемого на порт 80 (web).
Существует 3 общеизвестных способа такого перенаправления:
Шлюз.Вы можете настроить шлюз таким образом, что он будет перенапрвлять все пакеты, адресованные на порт 80, сереверу squid
НО
Это увеличит нагрузку на шлюз. Кроме того, некоторые коммерческие роутеры не поддерживают такую возможность.
Layer 4 switchСвичи выполняют такое перенаправление без особых проблем.
НО
Стоимость этого оборудования очень высока и может быть сопоставима с ценой связки "обычный роутер" + "Linux-сервер"
Использовать кэш-сервер в качестве шлюза.Вы можете отправить ВЕСЬ трафик через кэш-сервер.
НО
Это довольно рисковано, поскольку squid довольно значительно нагружает CPU, что может привести к снижению производительности сети. Кроме того, squid может "рухнуть" и тогда никто из сети не сможет выйти в Интернет.
Мы предлагаем 4-й вариант: Linux+NetFilter.Эта методика предполагает установку меток на пакеты, с портом назначения равным числу 80, и дальнейшая маршрутизация помеченных пакетов, с помощью iproute2, на squid.
|----------------|
| Реализация |
|----------------|
Используемые адреса
10.0.0.1 naret (NetFilter)
10.0.0.2 silom (Squid)
10.0.0.3 donmuang (Router, соединенный с Интернет)
10.0.0.4 kaosarn (некий сервер в сети)
10.0.0.5 RAS
10.0.0.0/24 main network
10.0.0.0/19 total network
|---------------|
|Структура сети |
|---------------|
Internet
|
donmuang
|
------------hub/switch----------
| | | |
naret silom kaosarn RAS etc.
Прежде всего — весь трафик должен идти через naret, для этого на всех компьютерах пропишем его в качестве шлюза по-умолчанию. Исключение составляет silom, для которого шлюз по-умолчанию — donmuang (в противном случае web-трафик зациклится).
(на всех компьютерах в моей сети был прописан шлюз по-умолчанию – 10.0.0.1, который ранее принадлежал donmuang , поэтому я изменил IP-адрес у donmuang на 10.0.0.3, а серверу naret присвоил адрес 10.0.0.1)
Silom — настройка squid и ipchainsНастройте прокси-сервер squid на silom. Убедитесь, что он поддерживает прозрачное проксирование. Обычно прокси-серверу, для приема запросов от пользователей, назначают порт 3128, поэтому весь трафик, отправляемый на порт 80 будет перенаправлен на порт 3128. С помощью ipchains это делают следующие правила:
silom# ipchains –N allow1
silom# ipchains –A allow1 –p TCP –s 10.0.0.0/19 –d 0/0 80 –j REDIRECT 3128
silom# ipchains –I input –j allow1
iptables:
silom# iptables –t nat –A PREROUTING –i eth0 –p tcp –dport 80 –j REDIRECT –to-port 3128
За информацией по настройке сервера squid, обращайтесь на http://squid.nlanr.net/.
Убедитесь, что на этом сервере разрешен форвардинг, и заданный по умолчанию шлюз для него — donmuang (НЕ naret !).
Naret — настройка iptables и iproute2; запрет ICMP-сообщений о перенаправлении (если необходимо)1. Пометить пакеты, с портом назначения 80, числовой меткой 2.
naret# iptables –A PREROUTING –i eth0 –t mangle –p tcp –dport 80
–j MARK –set-mark 2
2. Настроить маршрутизацию так, чтобы помеченные пакеты отправлялись на silom.
naret# echo 202 www.out >> /etc/iproute2/rt_tables
naret# ip rule add fwmark 2 table www.out
naret# ip route add default via 10.0.0.2 dev eth0 table www.out
naret# ip route flush cache
Если donmuang и naret находятся в одной подсети, то naret не должен выдавать ICMP-сообщения о перенаправлении. Запрет можно наложить так:
naret# echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects
На этом настройку можно считать завершенной. Проверим конфигурацию
Для naret:
naret# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK tcp -- anywhere anywhere tcp dpt:www MARK set 0x2
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
naret# ip rule ls
0: from all lookup local
32765: from all fwmark 2 lookup www.out
32766: from all lookup main
32767: from all lookup default
naret# ip route list table www.out
default via 203.114.224.8 dev eth0
naret# ip route
10.0.0.1 dev eth0 scope link
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 10.0.0.3 dev eth0
|-------|
|-КОНЕЦ-|
|-------|
15.5.1. Схема движения пакетов после настройки.
|-----------------------------------------|
| Схема движения пакетов |
|-----------------------------------------|
ИНТЕРНЕТ
/
||
/
---------------------donmuang------------------------
/ / ||
|| || ||
|| / ||
naret silom ||
*destination port 80 ================>(cache) ||
/ || ||
|| / /
\===================================kaosarn, RAS, и пр.
Обратите внимание, в данном случае сеть получилась асимметричной, т.е. добавился один лишний переход для исходящих пакетов.
Ниже приводится путь, проделываемый пакетами в/из Интернет для компьютера kaosarn.
Для web/http трафика:
kaosarn http request->naret->silom->donmuang->internet
http replies from Internet->donmuang->silom->kaosarn
Для прочего трафика:
kaosarn outgoing data->naret->donmuang->internet
incoming data from Internet->donmuang->kaosarn
15.6. Решение проблемы с Path MTU Discovery путем настройки MTU.
Общеизвестно, что скорость передачи данных возрастает с увеличением размера пакета. Это вполне естесственно, ведь для каждого пакета в потоке принимается решение о выборе маршрута. К примеру, файл, размером в 1 мегабайт, будет передан быстрее, если он будет разбит на 700 пакетов (при максимальном размере пакета), а не на 4000.
Однако, не все сегменты Интернет могут передавать пакеты, с максимальной полезной нагрузкой в 1460 байт. Поэтому необходимо найти такой размер, который будет максимально возможным для заданного маршрута.
Процесс поиска такого размера называется 'Path MTU Discovery' (Поиск Максимального Размера Пакета для выбранного Пути), где MTU означает 'Maximum Transfer Unit' (Максимальный Размер Блока передачи данных).
Когда на маршрутизатор поступает пакет, который не может быть передан по выбранному маршруту целиком (без фрагментации) И у него установлен флаг "Don't Fragment" (Не фрагментировать), то в ответ отправляется ICMP-сообщение о том, что пакет был сброшен из-за невозможности "протолкнуть" его по выбранному маршруту. Компьютер, выполнивший посылку, начинает последовательно уменьшать размер пакетов до тех пор, пока они не смогут быть переданы по выбранному маршруту.
Все бы ничего, если бы не появились злоумышленники, которые задались целью нарушить нормальную работу Сети. Это, в свою очередь, вынуждает администраторов ограничивать или вообще блокировать ICMP-трафик с целью повысить отказоустойчивость вверенного им фрагмента сети.
В результате таких действий процесс поиска оптимального размера пакета работает все хуже и хуже, а на некоторых маршрутизаторах вообще не работает, что в свою очередь порождает сеансы TCP/IP с весьма странным поведением, которые "умирают" спустя некоторое время.
Хотя у меня нет никаких доказательств, но я знаю по крайней мере два сайта, с которыми наблюдается подобная проблема и перед обоими стоит Alteon Acedirectors — возможно кто-то имеет более богатый опыт и сможет подсказать как и почему это происходит.
