Routování dvou subnetů

[Green_Raul]

Vážně díky všem za rozvinutí diskuze... Já do toho koukal už moc dlouho a přestávál jsem v tom cokoliv vidět.

Zřejmě po celou tu dobu funguje vše kromě testu, kterým jsem to já blbec celou tu dobu testoval (tedy ping www.seznam.cz -I eth0 - který vrací destination host unreachable)... To je ta lenost zvednou se ze židle a jít k nějaké klientské stanici... Omlouvám se vám.

Každopádně nastavení je nyní takovéto:

[root@srvr etc]$ service network restart
Deaktivuji rozhraní eth0:                                  [  OK  ]
Deaktivuji rozhraní eth1:                                  [  OK  ]
Deaktivuji rozhraní loopback:                              [  OK  ]
Aktivuji rozhraní loopback:                                [  OK  ]
Aktivuji rozhraní eth0:                                    [  OK  ]
Aktivuji rozhraní eth1:                                    [  OK  ]
[root@srvr etc]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 2c:27:d7:15:57:ee brd ff:ff:ff:ff:ff:ff
    inet 192.168.90.2/24 brd 192.168.90.255 scope global eth1
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1c:c4:7b:78:aa brd ff:ff:ff:ff:ff:ff
    inet 192.168.93.2/24 brd 192.168.93.255 scope global eth0
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534]
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 52:54:00:c7:cf:9d brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
    link/ether 52:54:00:c7:cf:9d brd ff:ff:ff:ff:ff:ff
[root@srvr etc]$ ip r
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1
10.8.0.0/24 via 10.8.0.2 dev tun0
192.168.93.0/24 dev eth0  proto kernel  scope link  src 192.168.93.2
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1
192.168.90.0/24 dev eth1  proto kernel  scope link  src 192.168.90.2
169.254.0.0/16 dev eth1  scope link  metric 1002
169.254.0.0/16 dev eth0  scope link  metric 1003
default via 192.168.90.1 dev eth1
[root@srvr etc]$ iptables --list-rules
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
[root@srvr etc]$ iptables --list-rules -t nat
-P PREROUTING ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
-A POSTROUTING -o eth1 -j MASQUERADE

[Reklama]

[Mirek Prýmek]

Takže závěr je takový, že ten ping takhle fakt nefunguje by design?

[Green_Raul]

Ano závěr je opravdu takový, že jsi měl pravdu a navedl mě k tomu to zkusit nastavit, tak jak jsem to nastavil hned napoprvé... A poté to dojít zkusit přímo ze stanice na LAN subnetu... Vše fungovalo... Nastavení iptables pro forwarding OpenVPN a jiných služeb hostovaných na LANu a poté DHCPD, DNS, Squid, qlproxy atd. už šlo jako po másle a nezabralo mi snad ani tolik času jako ten routing.  Co dodat.

[Mirek Prýmek]

Zajímavý. Teď ještě vědět přesně, proč to tak je. Chtělo by to nějakýho gurua, kterej by nám to objasnil

Mohl bys zkusit tohle?
# echo 0 >/proc/sys/net/ipv4/conf/eth0/rp_filter
# echo 0 >/proc/sys/net/ipv4/conf/eth1/rp_filter
a potom zas ten ping?

[j]

Mezi nama ... NATovat privatni rozsah je hodne blbej napad .... co kdyby ti aspon ten tvuj "isp" dal rekneme 4 Ccka?

[Reklama]