Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Internet a sítě => Téma založeno: tre-ska 04 Listopadu 2014, 15:33:55
-
Dobry den, mam server ubuntu 14.04 server. Siet mam nastavenu takto:
Ide o primarnu siet a podsiet (vlan)
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 18.15.3.143
netmask 255.255.255.192
network 18.15.3.128
broadcast 18.15.3.191
gateway 18.15.3.129
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 8.8.8.8
dns-search fns.uniba.sk
# VLAN40 for DHCP server
auto eth0.40
iface eth0.40 inet static
address 18.15.5.150
netmask 255.255.255.0
#gateway 18.15.5.1
vlan-raw-device eth0
Na serveri bezia primarne dve sluzby. web-server a dhcp server. DHCP server funguje cez subnet vlan40 (18.15.5.0).
A este web server, ktory bezi na ip 18.15.3.143. Vsetko funguje dobre, ale ak sa chcem pripojit na web-server zo subnetu 18.15.5.0 (vlan40), takstranku neotvori, okrem tohto subnetu sa dokaze pripojit na ten server cely svet. Akonahle ten interface eth0.40 vypnem tak sa uz dokaze subnet (18.15.5.0) pripojit.
tcpdump vypisuje toto:
15:31:55.005346 IP 18.15.5.160.59979 > domena.sk.https: Flags [S], seq 802408223, win 14600, options [mss 1460,sackOK,TS val 6133771 ecr 0,nop,wscale 6], length 0
15:31:55.209997 IP 18.15.5.160.59981 > domena.sk.https: Flags [S], seq 4125392294, win 14600, options [mss 1460,sackOK,TS val 6133791 ecr 0,nop,wscale 6], length 0
15:31:58.018442 IP 18.15.5.160.59979 > domena.sk.https: Flags [S], seq 802408223, win 14600, options [mss 1460,sackOK,TS val 6134072 ecr 0,nop,wscale 6], length 0
Ping funguje takto:
cely svet =>18.15.3.143 (pinguje)
subnet 18.15.5.0 => 18.15.3.143 (NEpinguje)
subnet 18.15.5.0 => 18.15.5.1 (pinguje)
-
Zapnutý forward mezi těmi rozhraními je?
-
myslite toto?
echo 1 > /proc/sys/net/ipv4/ip_forward
alebo v iptables?
-
Myslel jsem přesně takto.
Ale co se iptables týče, nebylo by od věci mrknout, zda tam není v default chain pro forward drop.
-
A co ty masky? U tohodle
address 18.15.5.150
netmask 255.255.255.0máš rozsah 18.15.5.1 - 18.15.5.254
když dáš
address 18.15.5.150
netmask 255.255.248.0tak bude rozsah 18.15.0.1 - 18.15.7.254 (255.255.252.0 by bylo málo, jen 18.15.4.1 - 18.15.7.254).
-
IP su len ilustracne, tie mam dobre nastavene
-
Myslel jsem přesně takto.
Ale co se iptables týče, nebylo by od věci mrknout, zda tam není v default chain pro forward drop.
tu je cast Iptables:
ACCEPT tcp -- anywhere anywhere tcp dpt:http state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:https state NEW
ACCEPT all -- localhost anywhere state NEW
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
-
Chain FORWARD (policy DROP)
-
IP su len ilustracne, tie mam dobre nastavene
Si děláš srandu?
-
IP su len ilustracne, tie mam dobre nastavene
Si děláš srandu?
I kdyby to bylo nastavené jak psal, pak to není nastavením IP.
Snaží se dostat ze subnetu 18.15.5.0/24 do subnetu 18.15.3.128/26 čiliže MUSÍ projít přes GW subnetu 18.15.5.0/24 čiliže 18.15.5.1, což mu funguje. Jen má DROP na forwardu.
-
tak som skusil pridat do iptables toto:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 158.195.95.0/24 localnet/26
ACCEPT all -- localnet/26 158.195.95.0/24
-
Jinak řečeno chain FORWARD má ACCEPT jako default, ty další řádky jsou tam k ničemu.
Jede to?
-
praveze nejde, tie dalsie riadky som pridal pre istotu. skusal som dak komplet vsade v iptables accept a nejde.
-
Zajímavé, jaké je nastavení klienta?
Předpokládám má jako GW 18.15.5.1?
Jak dopadne tracepath na tu IP?
Teď jsem se lépe podíval na tu konfiguraci ... asi by bylo fajn popsat, jak přesně to má fungovat.
Proč je tam VLANa?
-
eth0 Subnet (18.15.3.128/26) IP 18.15.3.143 je web server a ma byt pristupny odvsadial
eth0.40 Subnet (18.15.5.0/24) IP 18.15.5.150 to je subnet pre DHCP server a jeho IP je 18.15.5.150.
Problem je ze zo subnetu 18.15.5.0 sa neviem pripojit na IP 18.15.3.143 (web server).
akonahle vypnem interface eth0.40, tak ten subnet 18.15.5.0/24 sa vie dostat na ten webserver. cize tieto dva subnety sa navzajom vidia.
tracepath 18.15.5.160
1?: [LOCALHOST] pmtu 1500
1: 18.15.5.160 9.698ms reached
1: 18.15.5.160 5.334ms reached
Resume: pmtu 1500 hops 1 back 1
-
Pořád nevím, proč je tam ta VLANa?
-
Pořád nevím, proč je tam ta VLANa?
jj .. sleduju tuhle vec a ta vlan mi tam pripada skoro mozna i navic .. nechapu jeji ucel ... a nejsem si vubec jist, ze jde forwadovat na stejnem ethx aka ethx <-> ethx.y
-
DHCP server prideluje IP, pre zariadenia zaradene do vlan40.
-
nemuzes nam prosim ukazat (idealne bez zmen toho vystupu):
ip a
ip r
iptables-save
sysctl -a | grep forw
netstat -tulnp | grep http
??
-
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 90:1b:0e:26:bc:9e brd ff:ff:ff:ff:ff:ff
inet 158.195.93.143/26 brd 158.195.93.191 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::921b:eff:fe26:bc9e/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 90:1b:0e:24:39:a9 brd ff:ff:ff:ff:ff:ff
4: eth0.40@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 90:1b:0e:26:bc:9e brd ff:ff:ff:ff:ff:ff
inet 158.195.95.150/24 brd 158.195.95.255 scope global eth0.40
valid_lft forever preferred_lft forever
inet6 fe80::921b:eff:fe26:bc9e/64 scope link
valid_lft forever preferred_lft forever
ip r
default via 158.195.93.129 dev eth0
158.195.93.128/26 dev eth0 proto kernel scope link src 158.195.93.143
158.195.95.0/24 dev eth0.40 proto kernel scope link src 158.195.95.150
iptables-save
# Generated by iptables-save v1.4.21 on Wed Nov 5 13:23:55 2014
*mangle
:PREROUTING ACCEPT [4702:821793]
:INPUT ACCEPT [4409:789561]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4487:1368155]
:POSTROUTING ACCEPT [4487:1368155]
COMMIT
# Completed on Wed Nov 5 13:23:55 2014
# Generated by iptables-save v1.4.21 on Wed Nov 5 13:23:55 2014
*nat
:PREROUTING ACCEPT [752:64399]
:INPUT ACCEPT [402:21580]
:OUTPUT ACCEPT [407:28901]
:POSTROUTING ACCEPT [407:28901]
COMMIT
# Completed on Wed Nov 5 13:23:55 2014
# Generated by iptables-save v1.4.21 on Wed Nov 5 13:23:55 2014
*filter
:INPUT DROP [53:9967]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [4159:1277248]
:SSHDROP - [0:0]
-A INPUT -s 158.195.93.207/32 -i eth0 -p icmp -m icmp --icmp-type 8 -m state --state NEW -j ACCEPT
-A INPUT -s 158.195.93.200/32 -i eth0 -p icmp -m icmp --icmp-type 8 -m state --state NEW -j ACCEPT
-A INPUT -s 158.195.226.28/32 -i eth0 -p icmp -m icmp --icmp-type 8 -m state --state NEW -j ACCEPT
-A INPUT -s 158.195.93.207/32 -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -s 158.195.93.200/32 -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -s 158.195.226.28/32 -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -s 158.195.93.207/32 -i eth0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -s 127.0.0.1/32 -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 158.195.93.143/32 -d 158.195.95.160/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 158.195.93.143/32 -d 158.195.95.160/32 -p tcp -m tcp --dport 443 -j ACCEPT
-A SSHDROP -j LOG --log-prefix "SSH-pokus-DROP: "
-A SSHDROP -j DROP
COMMIT
sysctl -a | grep forw
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.eth0/40.forwarding = 1
net.ipv4.conf.eth0/40.mc_forwarding = 0
net.ipv4.conf.eth1.forwarding = 1
net.ipv4.conf.eth1.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 0
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.default.forwarding = 0
net.ipv6.conf.default.mc_forwarding = 0
net.ipv6.conf.eth0.forwarding = 0
net.ipv6.conf.eth0.mc_forwarding = 0
net.ipv6.conf.eth0/40.forwarding = 0
net.ipv6.conf.eth0/40.mc_forwarding = 0
net.ipv6.conf.eth1.forwarding = 0
net.ipv6.conf.eth1.mc_forwarding = 0
net.ipv6.conf.lo.forwarding = 0
net.ipv6.conf.lo.mc_forwarding = 0
netstat -tulnp | grep http nevypisal nic
-
DHCP server prideluje IP, pre zariadenia zaradene do vlan40.
Takže jinak řečeno na portu máš jednak nějaký subnet, který NEní součástí VLAN a zároveň ještě VLANu (s ID 40).
Pak nechápu, proč když VLANu zrušíš, subnety jedou. Ledaže by ona zařízení na subnetu s DHCP neležela na VLAN s ID 40, ale normálně na stejném PVID jako ten subnet s IP 158.195.93.143 ...
-
vypis z portu kde je server pripojeny: cisco# show interfaces trunk
Port Mode Encapsulation Status Native vlan
Fa0/30 on 802.1q trunking 41
Port Vlans allowed on trunk
Fa0/30 40-41
vlan41 - subnet 158.195.93.128/26
vlan40 - subnet 158.195.95.0/24
oba subnety su schopne komunikovat, cize port je definovany spravne
-
Pak nechápu, proč tam cpeš VLANu?
Vždyť to zajišťuje už ten switch na úplně jiné vrstvě?
Normálně hoď obě IP (čiliže oba subnety) na jeden iface a nic neřeš?
Nebo se pletu?
-
to som skusal a DHCP server neprideli IP pre vlan40
-
nevidim tam nic jako nakonfigurovanou tu maskaradu nebo nejakej nat .. proste to v tom iptables-save nejni .. mozna jsem slepej, ale melo byu tam byt neco jako
# iptables-save
# Generated by iptables-save v1.4.19.1 on Wed Nov 5 13:47:05 2014
*nat
:PREROUTING ACCEPT [30089:4509121]
:INPUT ACCEPT [6:1008]
:OUTPUT ACCEPT [96468:6043515]
:POSTROUTING ACCEPT [96468:6043515]
-A PREROUTING -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.255.10:3389
-A POSTROUTING -s 192.168.255.0/24 -j MASQUERADE
COMMIT
# Completed on Wed Nov 5 13:47:05 2014
# Generated by iptables-save v1.4.19.1 on Wed Nov 5 13:47:05 2014
*raw
:PREROUTING ACCEPT [2308596:2412214292]
:OUTPUT ACCEPT [2118323:290646948]
COMMIT
# Completed on Wed Nov 5 13:47:05 2014
# Generated by iptables-save v1.4.19.1 on Wed Nov 5 13:47:05 2014
*filter
:INPUT DROP [3767:238898]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [2118323:290646948]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0,wlan0 -p tcp -m tcp --dport 445 -j DROP
-A INPUT -i eth0,wlan0 -p tcp -m tcp --dport 139 -j DROP
-A INPUT -p tcp -m tcp --dport 3389 -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 445 -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 139 -j ACCEPT
-A FORWARD -s 192.168.255.0/24 -j ACCEPT
-A FORWARD -d 192.168.255.0/24 -j ACCEPT
COMMIT
# Completed on Wed Nov 5 13:47:05 2014
ps ^^ tohle je jen z me vorkstejsny, ale pohled co tam ve forwardu a postroutingu .. nicmene petr ma asi pravdu s tou vlanou taky ..
-
to som skusal a DHCP server neprideli IP pre vlan40
A co říká log? Pokud zařízení dostane IP napevno, komunikuje?
-
ps. tohle je osklive:
A INPUT -s 127.0.0.1/32 -i lo -m state --state NEW -j ACCEPT
proste mej default policy na DROP a prvni tri pravidla (teda dve pokud mas nejake specialni pozadavky na ping takovahle)
:INPUT DROP [3767:238898]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-
zrusil som vlan40 a subnet 158.195.95.0/24 som priradil k eth0:1 a nepomohlo. stale sa subnet 158.195.95.0/24 nevie pripojit k webserveru 158.195.93.143
ifconfig
eth0 Link encap:Ethernet HWaddr 90:1b:0e:26:bc:9e
inet addr:158.195.93.143 Bcast:158.195.93.191 Mask:255.255.255.192
inet6 addr: fe80::921b:eff:fe26:bc9e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:557338 errors:0 dropped:0 overruns:0 frame:0
TX packets:539549 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:122691208 (122.6 MB) TX bytes:339522326 (339.5 MB)
Interrupt:20 Memory:f7f00000-f7f20000
eth0:1 Link encap:Ethernet HWaddr 90:1b:0e:26:bc:9e
inet addr:158.195.95.150 Bcast:158.195.95.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:20 Memory:f7f00000-f7f20000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:44054 errors:0 dropped:0 overruns:0 frame:0
TX packets:44054 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4548118 (4.5 MB) TX bytes:4548118 (4.5 MB)
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 90:1b:0e:26:bc:9e brd ff:ff:ff:ff:ff:ff
inet 158.195.93.143/26 brd 158.195.93.191 scope global eth0
valid_lft forever preferred_lft forever
inet 158.195.95.150/24 brd 158.195.95.255 scope global eth0:1
valid_lft forever preferred_lft forever
inet6 fe80::921b:eff:fe26:bc9e/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 90:1b:0e:24:39:a9 brd ff:ff:ff:ff:ff:ff
4: eth0.40@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default
link/ether 90:1b:0e:26:bc:9e brd ff:ff:ff:ff:ff:ff
inet 158.195.95.150/24 brd 158.195.95.255 scope global eth0.40
valid_lft forever preferred_lft forever
tcpdump -nepi eth0 src 158.195.95.160
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:57:01.513383 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.32940 > 158.195.93.143.443: Flags [S], seq 4035842758, win 14600, options [mss 1460,sackOK,TS val 10934624 ecr 0,nop,wscale 6], length 0
13:57:04.530138 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.32940 > 158.195.93.143.443: Flags [S], seq 4035842758, win 14600, options [mss 1460,sackOK,TS val 10934925 ecr 0,nop,wscale 6], length 0
13:57:10.533111 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.32940 > 158.195.93.143.443: Flags [S], seq 4035842758, win 14600, options [mss 1460,sackOK,TS val 10935526 ecr 0,nop,wscale 6], length 0
-
skusil som dat vsetko ACCEPT a stale nic.
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
-
Promiň, ale v tom výpisu vidím IP jak na eth0:1 tak na eth0.40@eth0
-
ale dyk to pisu uz po 10te .. nemas v tech iptables zadnej NAT ani Makaradu ..
-
Tak ještě jednou a lépe :)
Už začínám tušit.
Ten subnet 158.195.95.0/24 je zvenku routovaný skrz 158.195.93.143? Je tedy celý "tvůj"? Jakou má bránu? Kde leží ta brána?
PS: @NTZ ono nepůjde o maškarádu, ale routing, teď jen, kudy :)
-
subnet 158.195.95.0/24 je routovany cez GW 158.195.95.1
IP 158.195.93.143 ma branu GW 158.195.93.1
ako som uz pisal ak vypnem eth0.40 tak subnet 158.195.95.0/24 sa vie dostat na ten webserver 158.195.93.143
-
Ta GW 158.195.95.1 leží kde? To je jiný stroj?
Proč tedy zapínat eth0.40?
-
hej ta GW 158.195.95.1 lezi mimo. No eth0.40 bezi DHCP server ktory obsluhuje vlan40
-
no a problem nastane v tom, ked budem chcet pridat DHCP pre dalsie subnety (vlan-y), cize si odrezem postupne pristup k tomu webserveru pre kazdy dalsi subnet...
-
To je dokolečka :)
Chápu, že tam běží DHCP server.
Trochu snad už i chápu, jak je síť postavená.
Ten server s IP 158.195.93.143 leží úplně mimo subnet 158.195.95.0/24, ta VLANa tam má tedy sloužit k tomu, aby tenhle subnet viděl DHCP server (který chceš mít na stroji s IP 158.195.93.143), který bude přidělovat IP přes tu VLANu, trochu nechápu, proč to nedělá GW, ale budiž.
V každém případě - problém je s tím, že když budeš mít na stroji IP z toho subnetu a požádáš o data z IP 158.195.93.143, bude se server snažit vrátit data nejkratší cestou, tedy přímo do subnetu přes VLANu, což klient nerozdejchá, protože přijdou úplně odjinud, než by je čekal.
Teď budu hodně vařit z vody, protože nemám čas na pokusy a ověřování, ale:
ip addr add 158.195.95.254/32 dev eth0.40
ip route add 158.195.95.0/24 dev eth0.40 src 158.195.95.254 table vlaning
ip route add default via 158.195.95.1 dev eth0.40 table vlaning
ip rule add from 158.195.95.0/24 table vlaning
ip rule add to 158.195.95.0/24 table vlaning
PS: Nebylo by jednodušší umístit ten DHCP přímo do té sítě? Stačí maličkatá krabička.
Taky by mne zajímalo, zda ten Tvůj DHCP server nepřiděluje blbě GW? To jen tak pro jistotu ...
-
V každém případě - problém je s tím, že když budeš mít na stroji IP z toho subnetu a požádáš o data z IP 158.195.93.143, bude se server snažit vrátit data nejkratší cestou, tedy přímo do subnetu přes VLANu, což klient nerozdejchá, protože přijdou úplně odjinud, než by je čekal.
presne v tomto vidim aj ja problem.
co ste mysleli tym table vlaning, tomu nejako nerozumiem
-
vlaning je jen název table, může tam být cokoliv
-
tak zial ani toto nepomohlo
-
Protože jsem jouda a uvažoval cestu.
Odeber ty přidané věci, nech nahozenou tu VLAN (tedy by měl jet ping ze zařízení v síti na 158.195.95.254 a zkus natvrdo jen toto:
ip route add 158.195.95.0/24 via 158.195.93.129
-
RTNETLINK answers: File exists
Destination Gateway Genmask Flags Metric Ref Use Iface
default 158.195.93.129 0.0.0.0 UG 0 0 0 eth0
localnet * 255.255.255.192 U 0 0 0 eth0
158.195.95.0 * 255.255.255.0 U 0 0 0 eth0.40
-
vyriesene:
ip route add 158.195.95.0/24 via 158.195.93.129 table 100
ip rule add priority 1000 from 158.195.93.143 table 100
-
Super, sorry, nějak jsem se nedostal k odpovědi :)