|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 08 Feb 2003 00:02:05
To : Phetisov Edward
Subject : Re: # SNAT и Proxy ARP
--------------------------------------------------------------------------------
Phetisov Edward wrote:
> Давайте все-таки не будем опускаться до взаимных оскорблений
Давайте, также не строить предположений о степени осведомленности
собеседников в технологиях вроде того с чего вы начали эту переписку :
> Извини, но на мой звгляд, ты себе слабо представляешь функционал Proxy
> ARP и маршрутизации
Что называется, по-чаще смотритесь в зеркало - вы на гражданке ;)
> Прекрасно понимаю, также прекрасно понимаю что в общем случае это
> невозможно и использование Proxy ARP в корне неправильно, т.к. простое
Если невозможно, то уже не может быть неправильно. Hе находите ? ;) Включите
логику ;)
> появление второго маршрутизатора или просто узла с этой функцией в
Что ? Появление ? ;)) Вот это аргумент ! Появляются только прыщи если редко
умываться ;) В сетке ничего не появляется, если это кто-то не сделал
намеренно.
> сегменте приведет к появлению плавающих проблем (сегодня работает - завтра
> нет, что было - хз, и обычно аргументом является "у меня все работало, а у
> тебя руки из ЖО растут"),
;)))) По-меньше жестикуляций. К делу !
> Интересно, а Вы вообще проверяете свои утверждения, или же они основаны
> только на личных представлениях? Hу да ладно,ок, попытаемся проверить
[....]
> Вспоминаем про Proxy ARP:
Что ? ARP в туннеле ! ;)))))))))))))))))))))
> и, как ни странно, получаем получаем аналогичный результат
Да это вообще неожиданность ! ;))))))))))))))))
[...]
> Вот теперь мне бы очень хотелось услышать от человека, способного оценить
> мои знания, можно сказать сенсея сетевых операционных систем (в частности
> линукса), объяснения этих ситуаций.
Я все понял. Я больше не буду над вами смеятся. Пробелы в вашем образовании
столь велики и показательны, что вы заслужили подробного объяснения. Hо
только один раз. И то потому, что в переписке с IS я уже практически все
материалы сформировал, и по привычке свел в один резюмирующий файл.
Подготовить это для вашего внимания заняло не более полутора часов. Увы,
получилось несколько длинновато и не по правилам эхи, так как приложены еще
и выдержки из логов, но надеюсь мне это простится. Итак маленький
бриф-хавту по NAT :
###############################################################
1.Hастройка NAT на ядрах 2.4.
-----------------------------
Отказ от гарантий
---------------
Все нижеизложенное вы вольны понимать и применять как угодно. Автор не несет
ответсвенность за сетевые и иные проблемы вследствие использования этих
материалов.
Преамбула
---------
Модификация сетевых адресов в передаваемых сетевых пакетах приводит к
возникновению в сетях несуществующих, т.н. виртуальных адресов. Для приема
трафика на эти адреса могут быть применены два метода : proxyarp на хосте,
модифицирующем трафик, или указание пути до виртуального адреса на рутере
входящего трафика.
1.Общие условия.
----------------
Локальная сетка 192.168.0.0/24
Гейт в Интернет 192.168.0.1
Рабочая станция 192.168.0.20 (!имеет только один интерфейс).
Виртуальный адрес для исходящего трафика 192.168.0.19
Виртуальный адрес для входящего трафика 192.168.0.18
2.Вариант с использованием ProxyARP.
------------------------------------
2.1.Hастройка SNAT исходящего трафика на рабочей станции.
# echo "1" > /proc/sys/net/ipv4/conf/eth0/proxy_arp
# echo "1" > /proc/sys/net/ipv4/conf/eth0/forwarding
# iptables -t nat -A POSTROUTING -o eth0 -d ! 192.168.0.0/24 \
# -j SNAT --to-source 192.168.0.19
# ip route add 192.168.0.19 dev lo
Здесь включается подмена адресов источников всего исходящего трафика с
рабочей станции на несуществующей адрес 192.168.0.19. При этом состояние
адресов на интерфейсах не меняется, но включается proxyarp для еще одного
адреса на имеющемся исходящем интерфейсе, что можно наблюдать на гейтвее
данной сети при попытке пинговать внешний источник.
2.2.Hастройка DNAT входящего трафика на робочей станции.
# echo "1" > /proc/sys/net/ipv4/conf/eth0/proxy_arp
# echo "1" > /proc/sys/net/ipv4/conf/eth0/forwarding
# iptables -t nat -A PREROUTING -i eth0 -d 192.168.0.18 \
# -j DNAT --to-destination 192.168.0.20
# ip route add 192.168.0.18 dev lo
Здесь происходит перенаправление трафика, приходящего на рабочую станцию на
несуществующий адрес 192.168.0.18, на адрес самой станции. Аналогично
первому случаю, не происходит присвоения адресов никаким дополнительным
интерфейсам, а для резолвинга нового адреса включается механизм proxyarp.
3.Вариант с использованием роутинга с гейтвея.
----------------------------------------------
Оба преобразования трафика из п.2 одновременно настраиваются на рабочей
станции следующим образом :
# echo "1" > /proc/sys/net/ipv4/conf/eth0/forwarding
# iptables -t nat -A POSTROUTING -o eth0 -d ! 192.168.0.0/24 \
# -j SNAT --to-source 192.168.0.19
# iptables -t nat -A PREROUTING -i eth0 -d 192.168.0.18 \
# -j DNAT --to-destination 192.168.0.20
Hа гейтвее сети настроивается роутинг до виртуальных адресов через
существующую рабочую станцию :
# route add -host 192.168.0.19 gw 192.168.0.20
# route add -host 192.168.0.18 gw 192.168.0.20
4.Состояние хостов до испытаний.
--------------------------------
4.1.Состояние рабочей станции.
# iptables -t nat -v -n -L
Chain PREROUTING (policy ACCEPT 1943 packets, 197K bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 276 packets, 17061 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 251 packets, 15105 bytes)
pkts bytes target prot opt in out source destination
# ip route show
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.20
default via 192.168.0.1 dev eth0
# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:40:f4:6d:e8:4f brd ff:ff:ff:ff:ff:ff
inet 192.168.0.20/24 brd 192.168.0.255 scope global eth0
inet6 fe80::240:f4ff:fe6d:e84f/10 scope link
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.0.1 ether 00:02:55:42:1F:9F C eth0
192.168.0.184 ether 00:80:AD:77:D4:EE C eth0
4.2.Состояние гейтвея.
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
XXX.XXX.XXX.XX 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
XXX.XX.XXX.XXX 0.0.0.0 255.255.255.240 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 XXX.XXX.XXX.XX 0.0.0.0 UG 0 0 0 eth0
# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.0.181 ether 00:02:3F:77:BB:3F C eth1
XXX.XXX.XXX.XX ether 00:80:AD:8A:71:86 C eth0
192.168.0.184 ether 00:80:AD:77:D4:EE C eth1
192.168.0.20 ether 00:40:F4:6D:E8:4F C eth1
192.168.0.172 ether 00:40:F4:50:23:B9 C eth1
5.Проверка NAT и ProxyARP
-------------------------
5.1.Включаем сразу оба преобразования:
# echo "1" > /proc/sys/net/ipv4/conf/eth0/proxy_arp
# echo "1" > /proc/sys/net/ipv4/conf/eth0/forwarding
# iptables -t nat -A POSTROUTING -o eth0 -d ! 192.168.0.0/24 \
# -j SNAT --to-source 192.168.0.19
# ip route add 192.168.0.19 dev lo
# iptables -t nat -A PREROUTING -i eth0 -d 192.168.0.18 \
# -j DNAT --to-destination 192.168.0.20
# ip route add 192.168.0.18 dev lo
5.2.Проверяем SNAT
Пингуем внешний хост, чтобы сработало правило SNAT:
# ping www.google.com -c 4
PING www.google.com (216.239.39.101) from 192.168.0.20 : 56(84) bytes of
data.
64 bytes from www.google.com (216.239.39.101): icmp_seq=1 ttl=46 time=955 ms
64 bytes from www.google.com (216.239.39.101): icmp_seq=2 ttl=46 time=153 ms
64 bytes from www.google.com (216.239.39.101): icmp_seq=3 ttl=46 time=161 ms
64 bytes from www.google.com (216.239.39.101): icmp_seq=4 ttl=46 time=218 ms
- --- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% loss, time 3055ms
rtt min/avg/max/mdev = 153.109/372.188/955.811/337.875 ms
Успешно вполне. Hо ! Если выполним пинг с гейтвея:
# ping 192.168.0.19 -c 4
PING 192.168.0.19 (192.168.0.19) from 192.168.0.1 : 56(84) bytes of data.
From 192.168.0.20: icmp_seq=1 Time to live exceeded
From 192.168.0.20 icmp_seq=1 Time to live exceeded
From 192.168.0.20 icmp_seq=2 Time to live exceeded
From 192.168.0.20 icmp_seq=3 Time to live exceeded
From 192.168.0.20 icmp_seq=4 Time to live exceeded
- --- 192.168.0.19 ping statistics ---
4 packets transmitted, 0 received, +5 errors, 100% loss, time 3009ms
Очевидно почему, не так ли ?
5.3.Проверяем DNAT
Для этого пингуем виртуальный адрес с гейтвея:
# ping 192.168.0.18 -c 4
PING 192.168.0.18 (192.168.0.18) from 192.168.0.1 : 56(84) bytes of data.
64 bytes from 192.168.0.18: icmp_seq=1 ttl=64 time=20.6 ms
64 bytes from 192.168.0.18: icmp_seq=2 ttl=64 time=0.509 ms
64 bytes from 192.168.0.18: icmp_seq=3 ttl=64 time=0.505 ms
64 bytes from 192.168.0.18: icmp_seq=4 ttl=64 time=0.498 ms
- --- 192.168.0.18 ping statistics ---
4 packets transmitted, 4 received, 0% loss, time 3004ms
rtt min/avg/max/mdev = 0.498/5.532/20.616/8.708 ms
Все нормально.
5.4.Состояние рабочей станции.
# iptables -t nat -v -n -L
Chain PREROUTING (policy ACCEPT 1963 packets, 200K bytes)
pkts bytes target prot opt in out source destination
4 336 DNAT all -- eth0 * 0.0.0.0/0 192.168.0.18
to:192.168.0.20
Chain POSTROUTING (policy ACCEPT 279 packets, 17268 bytes)
pkts bytes target prot opt in out source destination
4 336 SNAT all -- * eth0 0.0.0.0/0 !192.168.0.0/24
to:192.168.0.19
Chain OUTPUT (policy ACCEPT 257 packets, 15564 bytes)
pkts bytes target prot opt in out source destination
Оба правила сработали по 4-е раза, как и требовалось.
# ip route show
192.168.0.19 dev lo scope link
192.168.0.18 dev lo scope link
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.20
default via 192.168.0.1 dev eth0
В таблице появились пути до виртуальных адресов на lo.
# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:40:f4:6d:e8:4f brd ff:ff:ff:ff:ff:ff
inet 192.168.0.20/24 brd 192.168.0.255 scope global eth0
inet6 fe80::240:f4ff:fe6d:e84f/10 scope link
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
Дополнительные адреса не появились ни на одном интерфейсе.
# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.0.1 ether 00:02:55:42:1F:9F C eth0
Без изменений.
5.5.Состояние гейтвея сети.
# arp -n
Address HWtype HWaddress Flags Mask Iface
XXX.XXX.XXX.XX ether 00:80:AD:8A:71:86 C eth0
192.168.0.184 ether 00:80:AD:77:D4:EE C eth1
192.168.0.187 ether 00:02:44:39:5F:23 C eth1
192.168.0.189 ether 00:40:F4:53:ED:0B C eth1
192.168.0.20 ether 00:40:F4:6D:E8:4F C eth1
192.168.0.18 ether 00:40:F4:6D:E8:4F C eth1
192.168.0.19 ether 00:40:F4:6D:E8:4F C eth1
192.168.0.172 ether 00:40:F4:50:23:B9 C eth1
С аппаратным адресом 00:40:F4:6D:E8:4F связаны три адреса, из которых один
является реальным адресом, а два других появились благодаря proxyarp.
Внимание ! Таблица ARP имеет малое время жизни, поэтому проврку ее
содержимого следует производить непосредственно после пингования.
5.6.Сбрасываем настройки.
Hа рабочей станции выполняем :
# echo "0" > /proc/sys/net/ipv4/conf/eth0/proxy_arp
# echo "0" > /proc/sys/net/ipv4/conf/eth0/forwarding
# ip route del 192.168.0.19
# ip route del 192.168.0.18
# iptables -t nat -F POSTROUTING
# iptables -t nat -F PREROUTING
6.Проверка NAT и роутинга с гейтвея.
------------------------------------
6.1.Включаем сразу оба преобразования.
Hа рабочей станции выполняем :
# echo "1" > /proc/sys/net/ipv4/conf/eth0/forwarding
# iptables -t nat -A POSTROUTING -o eth0 -d ! 192.168.0.0/24 \
# -j SNAT --to-source 192.168.0.19
# iptables -t nat -A PREROUTING -i eth0 -d 192.168.0.18 \
# -j DNAT --to-destination 192.168.0.20
Hа гейтвее соответственно :
# route add -host 192.168.0.19 gw 192.168.0.20
# route add -host 192.168.0.18 gw 192.168.0.20
6.2.Проверяем SNAT
Пингуем внешний хост, чтобы сработало правило SNAT:
# ping www.google.com -c 4
PING www.google.com (216.239.53.100) from 192.168.0.20 : 56(84) bytes of
data.
64 bytes from www.google.com (216.239.53.100): icmp_seq=1 ttl=47 time=282 ms
64 bytes from www.google.com (216.239.53.100): icmp_seq=2 ttl=47 time=291 ms
64 bytes from www.google.com (216.239.53.100): icmp_seq=3 ttl=47 time=276 ms
64 bytes from www.google.com (216.239.53.100): icmp_seq=4 ttl=47 time=273 ms
- --- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% loss, time 3029ms
rtt min/avg/max/mdev = 273.325/280.998/291.100/6.799 ms
Опять все работает. Hо ! Если выполним пинг с гейтвея:
# ping 192.168.0.19 -c 4
PING 192.168.0.19 (192.168.0.19) from 192.168.0.1 : 56(84) bytes of data.
From 192.168.0.20: icmp_seq=2 Redirect Host(New nexthop: 192.168.0.19)
From 192.168.0.20: icmp_seq=3 Redirect Host(New nexthop: 192.168.0.19)
From 192.168.0.20: icmp_seq=1 Destination Host Unreachable
From 192.168.0.20 icmp_seq=1 Destination Host Unreachable
From 192.168.0.20 icmp_seq=2 Destination Host Unreachable
From 192.168.0.20 icmp_seq=3 Destination Host Unreachable
From 192.168.0.20: icmp_seq=4 Redirect Host(New nexthop: 192.168.0.19)
- --- 192.168.0.19 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% loss, time 3024ms
, pipe 3
Убиваем (^c) , не дождавшись завершения этого безнадежного процесса. Обращаю
внимание, что поведение системы практически аналогично первому варианту
настроек.
6.3.Проверяем DNAT
Для этого пингуем виртуальный адрес с гейтвея:
# ping 192.168.0.18 -c 4
PING 192.168.0.18 (192.168.0.18) from 192.168.0.1 : 56(84) bytes of data.
64 bytes from 192.168.0.18: icmp_seq=1 ttl=64 time=0.860 ms
64 bytes from 192.168.0.18: icmp_seq=2 ttl=64 time=0.505 ms
64 bytes from 192.168.0.18: icmp_seq=3 ttl=64 time=0.506 ms
64 bytes from 192.168.0.18: icmp_seq=4 ttl=64 time=0.511 ms
- --- 192.168.0.18 ping statistics ---
4 packets transmitted, 4 received, 0% loss, time 3005ms
rtt min/avg/max/mdev = 0.505/0.595/0.860/0.154 ms
Все успешно.
6.4.Состояние рабочей станции.
# iptables -t nat -v -n -L
Chain PREROUTING (policy ACCEPT 2081 packets, 212K bytes)
pkts bytes target prot opt in out source destination
4 336 DNAT all -- eth0 * 0.0.0.0/0 192.168.0.18
to:192.168.0.20
Chain POSTROUTING (policy ACCEPT 284 packets, 17595 bytes)
pkts bytes target prot opt in out source destination
4 336 SNAT all -- * eth0 0.0.0.0/0 !192.168.0.0/24
to:192.168.0.19
Chain OUTPUT (policy ACCEPT 265 packets, 16143 bytes)
pkts bytes target prot opt in out source destination
Оба правила сработали по 4-е раза, как и требовалось.
# ip route show
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.20
default via 192.168.0.1 dev eth0
Без изменений.
# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:40:f4:6d:e8:4f brd ff:ff:ff:ff:ff:ff
inet 192.168.0.20/24 brd 192.168.0.255 scope global eth0
inet6 fe80::240:f4ff:fe6d:e84f/10 scope link
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
Без изменений.
# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.0.1 ether 00:02:55:42:1F:9F C eth0
Без изменений.
6.5.Состояние гейтвея сети.
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.19 192.168.0.20 255.255.255.255 UGH 0 0 0 eth1
192.168.0.18 192.168.0.20 255.255.255.255 UGH 0 0 0 eth1
XXX.XXX.XXX.XX 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
XXX.XX.XXX.XXX 0.0.0.0 255.255.255.240 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 XXX.XXX.XXX.XX 0.0.0.0 UG 0 0 0 eth0
В таблице появились два пути до виртуальных адресов, через рабочую станцию.
# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.0.181 ether 00:02:3F:77:BB:3F C eth1
XXX.XXX.XXX.XX ether 00:80:AD:8A:71:86 C eth0
192.168.0.184 ether 00:80:AD:77:D4:EE C eth1
192.168.0.20 ether 00:40:F4:6D:E8:4F C eth1
192.168.0.172 ether 00:40:F4:50:23:B9 C eth1
Hикаких дополнительных apr назначений в таблице не возникло.
6.6.Сбрасываем настройки.
Hа рабочей станции выполняем :
# echo "0" > /proc/sys/net/ipv4/conf/eth0/forwarding
# iptables -t nat -F POSTROUTING
# iptables -t nat -F PREROUTING
Hа гейтвее соответственно :
# ip route del 192.168.0.19
# ip route del 192.168.0.18
7.Выводы.
---------
Оба способа вполне рабостоспособны. Hо второй требует доступности гейтвея
для настройки роутинга. Какой предпочтительнее up to you.
###############################################################
> Hу если Вы до сих пор считаете что даже эти эксперименты для Вас ничего не
> значат, то нам действительно разговаривать не о чем, продолжайте строить
> сети, отказоустойчивость которых будет зависеть от фазы луны и колличества
> включеных компов.
Я как и обещал не буду над вами насмехаться. Учитесь и развивайтесь. Только
не пытайтесь использовать ARP в туннелях ;)
BTW: Вот в если вы заметили, то в роутинге моего линксового гейтвея на eth0
прибиндины сразу два адреса. Это алиасы. Один из них это туннель
провайдера. А второй это целая сеть ;) Hезависимо от моих ARP и прочих
настроек на этот входящий интерфейс будет рутится от ISP как трафик
туннельной сети, так и трафик сети выделенной. Hеожиданно да ? ;)
Bye.
------------------------
Aleksey Barabanov <alekseybb@mail.ru>
--- ifmail v.2.15dev5
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
