Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO

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

|-------|

|-КОНЕЦ-|

|-------|

|-----------------------------------------|

| Схема движения пакетов |

|-----------------------------------------|

ИНТЕРНЕТ

/\

||

\/

---------------------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

Общеизвестно, что скорость передачи данных возрастает с увеличением размера пакета. Это вполне естесственно, ведь для каждого пакета в потоке принимается решение о выборе маршрута. К примеру, файл, размером в 1 мегабайт, будет передан быстрее, если он будет разбит на 700 пакетов (при максимальном размере пакета), а не на 4000.

Однако, не все сегменты Интернет могут передавать пакеты, с максимальной полезной нагрузкой в 1460 байт. Поэтому необходимо найти такой размер, который будет максимально возможным для заданного маршрута.

Процесс поиска такого размера называется 'Path MTU Discovery' (Поиск Максимального Размера Пакета для выбранного Пути), где MTU означает 'Maximum Transfer Unit' (Максимальный Размер Блока передачи данных).

Когда на маршрутизатор поступает пакет, который не может быть передан по выбранному маршруту целиком (без фрагментации) И у него установлен флаг "Don't Fragment" (Не фрагментировать), то в ответ отправляется ICMP-сообщение о том, что пакет был сброшен из-за невозможности "протолкнуть" его по выбранному маршруту. Компьютер, выполнивший посылку, начинает последовательно уменьшать размер пакетов до тех пор, пока они не смогут быть переданы по выбранному маршруту.

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

В результате таких действий процесс поиска оптимального размера пакета работает все хуже и хуже, а на некоторых маршрутизаторах вообще не работает, что в свою очередь порождает сеансы TCP/IP с весьма странным поведением, которые "умирают" спустя некоторое время.

Хотя у меня нет никаких доказательств, но я знаю по крайней мере два сайта, с которыми наблюдается подобная проблема и перед обоими стоит Alteon Acedirectors — возможно кто-то имеет более богатый опыт и сможет подсказать как и почему это происходит.

Если вы столкнетесь с подобной проблемой, то можно посоветовать отключить 'Path MTU Discovery' и установить MTU вручную. Koos van den Hout пишет:

У меня возникла следующая проблема: для арендованного мною канала, работающего через ppp, на скорости 33.6К, я установил величину MTU/MRU, равную 296. Это дает мне достаточно приемлемое время отклика.

Со моей стороны установлен роутер (с маскарадингом), работающий под управлением Linux.

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