Dotaz: Nastavení gw na routeru a problém s dlouhými odezvami

[otula]

Mám problém, ze kterého už mi začíná hrabat, ale věřím, že je to jen nějaká drobnost. Stručně: šílené odezvy na serveru/NAT routeru poté, co nastavím gateway vnější sítě.

Do neveřejného serveru, na kterém mi běží různé služby, počínaje DNS přes Apache až po Jabber, jsem připojil druhou síťovou kartu (eth1), jejímž prostřednictvím jsem ho připojil k další neveřejné síti, jejíž služby (například update Avastu) chci využívat. Přičemž můj server a naše síť jsou pro tento vnější svět neviditelné.

Základní nastavení:

cat /etc/rc.conf

...
lo="lo 127.0.0.1"
eth0="eth0 192.168.0.1 netmask 255.255.255.192 broadcast 192.168.0.63 hw ether 00:11:11:A0:58:88"
eth1="eth1 1.2.3.244 netmask 255.255.255.128 broadcast 1.2.3.255"
INTERFACES=(lo eth0 eth1)

gateway="default gw 192.168.0.1"
ROUTES=(!gateway)
...

Na problém, který mám, sice nemá iptables vliv, ale pro úplnost ho také uvedu

# Generated by iptables-save v1.4.0 on Thu Feb  4 12:09:19 2010
*nat
:PREROUTING ACCEPT [144:11495]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o eth1 -j MASQUERADE 
COMMIT
# Completed on Thu Feb  4 12:09:19 2010
# Generated by iptables-save v1.4.0 on Thu Feb  4 12:09:19 2010
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [664:75778]
-A INPUT -i ! eth1 -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -i eth1 -p tcp -j REJECT --reject-with tcp-reset 
-A INPUT -i eth1 -p udp -j REJECT --reject-with icmp-port-unreachable 
-A FORWARD -d 192.168.0.0/26 -i eth0 -j DROP 
-A FORWARD -s 192.168.0.0/26 -i eth0 -j ACCEPT 
-A FORWARD -d 192.168.0.0/26 -i eth1 -j ACCEPT 
COMMIT
# Completed on Thu Feb  4 12:09:19 2010

Doposud vše skvěle funguje. Na gateway vnější sítě se dostanu ze serveru i z počítače ve vnitřní síti, všechno běhá pěkně svižně. Poslední věc, která zbývá, je dostat se za gateway vnější sítě. Ta má adresu řekněme 1.2.3.133:

# ip route add default via 1.2.3.133 dev eth1

Po tomto příkazu se dostanu za gateway. Na první pohled vše funguje úplně parádně, na pohled druhý mám nepříjemný problém. A to přímo a jen na svém serveru. Webové stránky, které mi běží na uvedeném serveru začnou mít mnohasekundové odezvy (ale ne všechny, nýbrž jen některé, ale nepodařilo se mi najít, co přesně v nich zdržuje). Stejně tak má obrovskou odezvu například také příkaz netstat. A například příkaz route se zachová takto:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.192 U     0      0        0 eth0
1.2.3.128       *               255.255.255.128 U     0      0        0 eth1

...nyní následuje obrovká pauza...
...po které se dokončí výpis:
default         1.2.3.133       0.0.0.0         UG    0      0        0 eth1

Dokážete mi říct, čím je to způsobeno a jak to vyřešit?

---

---

Odpovědi

[NN]

Posli sem ifconfig, pripadne ethtool te karty, treba ma problem s ovladacem..

NN

[otula]

# ifconfig

eth0      Link encap:Ethernet  HWaddr 00:11:11:A0:58:88  
          inet addr:192.168.0.1  Bcast:192.168.0.63  Mask:255.255.255.192
          inet6 addr: fe80::211:11ff:fea0:5888/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:297552 errors:0 dropped:0 overruns:0 frame:0
          TX packets:371655 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:32110289 (30.6 Mb)  TX bytes:268565611 (256.1 Mb)

eth1      Link encap:Ethernet  HWaddr 00:50:FC:1B:62:1C  
          inet addr:1.2.3.244  Bcast:1.2.3.255  Mask:255.255.255.128
          inet6 addr: fe80::250:fcff:fe1b:621c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:177975 errors:0 dropped:0 overruns:0 frame:0
          TX packets:93936 errors:0 dropped:0 overruns:0 carrier:0
          collisions:30307 txqueuelen:1000 
          RX bytes:221999754 (211.7 Mb)  TX bytes:8633181 (8.2 Mb)
          Interrupt:22 Base address:0xbc00 

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:16436  Metric:1
          RX packets:3001 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3001 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:239305 (233.6 Kb)  TX bytes:239305 (233.6 Kb)

[otula]

Hmm, doinstaloval jsem ethtool a výsledek je zajímavý:

# ethtool eth0

Settings for eth0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: umbg
	Wake-on: g
	Current message level: 0x00000007 (7)
	Link detected: yes

# ethtool eth1

Settings for eth1:
No data available

[tom]

Nejedna se o klasicky problem zahadnych prodlev - DNS ? Pokud ma default route, ktery drive nemel, tak se misto rychleho zjisteni "no route" snazi cekat na odpoved od DNS serveru, kterou nedostava. Je rozdil mezi prubehem vypisu "route" a "route -n" ? Jak vypada /etc/resolv.conf ?

Tomas

[otula]

route -n naběhne okamžitě:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.192 U     0      0        0 eth0
1.2.3.128       0.0.0.0         255.255.255.128 U     0      0        0 eth1
0.0.0.0         1.2.3.133       0.0.0.0         UG    0      0        0 eth1

v /etc/resolv.conf mám jen svůj server, a to takhle:

nameserver 127.0.0.1

Přidání nameserveru externí sítě jsem zkoušel, ale nemělo na to žádný vliv

[tom]

V tom pripade bude mit ty problemy s resolvovanim lokalni nameserver. Pridani dalsiho NS do resolv.conf nestaci, stejne pouzije ten na 127.0.0.1 a az nasledne ten pridany. Prodleva tam tedy bude stejne. Jak je ten nameserver nakonfigurovany?

Tomas

[otula]

Myslím, že na ten skutečný problém kápnul o něco níže Filip - předpokládám, že chybu dělám v tom, jak zadávám příkaz pro routování. Jen nevím, jak ho zadat správně.

[pasmen]

1. Zkus, jestli ti bude dlouho trvat i route -n (ukazovalo by to na problém s resolverem).

2. Třeba v dmesg nic vidět není? Nějaký problém na úrovní jádra.

3. Zkus pustit tcpdump a kouknout, kde to visí.

[otula]

Tak to vypadá na bod 1) - route -n naběhne okamžitě. Co mohu mít kde blbě?

[pasmen]

Někde se ti timeoutuje DNS dotaz. Pusť si tcpdump a koukni, kam to leze.

[otula]

Sice chápu, že jako dlouholetý linuxák bych to měl asi umět, ale skutečnost je jiná - nikdy jsem tcpdump nepoužíval. A pokud si ho spustím, chrlí na mne záplava informací rychlostí snad 10 řádků za sekundu, a nevím, ajk z toho něco vyčíst

[pasmen]

Třeba takhle
tcpdump -n -i ethX udp port 53

Pošli výstup např. po příkazu route (bez -n), nebo když ti to dlouho natahuje webovou stránku. Koukneme, kam se to snaží dostat, a pak se pohneme dál.

[otula]

A jo, takže použití bylo správné, jen to chtělo odfiltrovat balast :) Díky za to, každopádně už jsem to vyřešil - viz níže. Asi by stálo za to si to ještě nastavit zpět a zkoušet, ale utekla mi s touto srandou hromada času, ale práce mrška neutekla, tak se na ni musím vrhnout

Rozhodně ale díky tomu vidím, že Google Desktop, šikovná to věc na vyhledávání dokumentů, se neustále snaží napojit kamsi domů, takže bych mu měl zkusit nějak domluvit, aby se na to vykašlal ;)

[pasmen]

Jo tcpdump se hodí celkem často, takže základní syntax je nutnost znát

[otula]

[otula]

Ta dlouhá pauza může být způsobena tím, že se route pokouší přeložit IP adresu 1.2.3.133 na jméno.

Pro výpis routovací tabulky byste měl raději používat ip route show, bůhví, co route vlastně ukazuje.

Z popisu mi není jasné, o co se vlastně snažíte. Nejprve si nastavíte výchozí bránu na 192.168.0.1, a pak to z příkazové řádky měníte na 1.2.3.133. Proč tu výchozí bránu nenastavíte takhle rovnou? No a problém bude pravděpodobně v tom, že některé služby (nejspíš DNS resolver) nejsou přes tu druhou síť dostupné. A je to opravdu tak, že chcete změnit svého ISP na tu druhou síť? Váš popis jsem nejprve pochopil tak, že chcete stávající konektivitu zachovat a jenom se propojit s druhou sítí (ale ne využívat druhou síť jako vaši konektivitu), pak byste samozřejmě musel ponechat výchozí bránu na eth0 a pro eth1 jen nastavit routování.

[otula]

ip route show funguje v pohodě. Příkaz route jsem uvedl právě proto, že se chová divně.

Ohledně toho nastavení brány. Původně jsem použil to nastavení přímo v rc.conf, tedy

gateway="default gw 1.2.3.33"
ROUTES=(gateway)

a chovalo se to (samozřejmě) úplně stejně. Jsem takový samouk, který se vše učí ve chvíli, kdy to potřebuje - no a nyní jsem se právě snažil o to nastavení routování, ale patrně tedy úplně blbě, i když jsem se opravdu snažil prostudovat kde co :)

Mohu poprosit o to, jak správně nastavit jen routování pro eth1? Co jsem poznacházel, tak to chtělo vždy adresu sítě za gatewayí, kterou ale neznám. A nebo to mám úplně popletené a hledám špatně.

[Filip Jirsák]

Co vlastně chcete nastavit? Aby počítač měl přístup do sítí 192.168.0.1/26 a 1.2.3.244/25, a přes síť 192.168.0.1/26 aby se dostal do internetu? Pak by mělo stačit nastavit jen

lo="lo 127.0.0.1"
eth0="eth0 192.168.0.1 netmask 255.255.255.192 broadcast 192.168.0.63"
eth1="eth1 1.2.3.244 netmask 255.255.255.128 broadcast 1.2.3.255"
INTERFACES=(lo eth0 eth1)
gateway="default gw 192.168.0.1"

V posledním řádku (nastavení brány) asi bude jiná IP adresa, měla by tam být adresa brány, přes kterou se dostanete na internet (v té síti 192.168.0.1/26).

[otula]

Takhle jsem to nastaveno měl původně a chovalo se to přesně stejně.

Popíšu situaci stručně:

Mám vlastní síť 192.168.0.0/26. V této síti mám server/router na adrese 192.168.0.1 připojený prostřednictvím eth0. Běží na něm služby pro mou síť, které vnější síti nechci poskytovat.

Potřebuji se dostat z počítačů v mé síti do druhé sítě, kterou mám připojenu k serveru/routeru prostřednictvím eth1. Na této síťové kartě mám přidělenou adresu 1.2.3.244 a masku 255.255.255.128. Jediné místo, na které vidím, je nejbližší gateway na adrese 1.2.3.133. Ze sítí za touto branou nechci využívat nic jiného, než abych - když to řeknu zjednodušeně - se propingnul na jakoukoliv přístupnou IP adresu v této síti.

Patrně by stačilo místo default gw nastavit jen gw pro nějakou síť, jenže já netuším, co by mělo být zde:

ip route add ??.??.??.??/?? via 1.2.3.133 dev eth1

A nebo se to nastavuje úplně jinak?

[Filip Jirsák]

Místo těch otazníků musíte dát definici sítě či sítí, které jsou dostupné přes tu bránu 1.2.3.133. To by vám měl sdělit správce té brány.

Jiný případ by byl, pokud by za tou bránou 1.2.3.133 byly některé sítě stejné, jako jsou dostupné nyní přes vaši současnou bránu (typicky to nastane tehdy, pokud máte skrze dvě různé sítě přístup do internetu). Pak je potřeba použít pravidla (ip rule) pro určení toho, kdy se má která síť použít. Ale pokud ve vašem případě je za tou bránou 1.2.3.133 schovaná síť/sítě, které jsou pro vás jinak nedostupné, nebo se kterými se má vždy komunikovat přes tuto bránu, je to jednoduché nastavení routování, pravidla k tomu nepotřebujete.

[otula]

Takže jo. Vyřešil jsem to. Funguje to nyní perfektně, i když si nejsem jistý, jestli je to řešení obecně správně. Identifikací chyby bylo tohle:

A je to opravdu tak, že chcete změnit svého ISP na tu druhou síť?

Tak jsem zkoušel, až jsem se dozkoušel k funkčnímu a bezproblémovému závěru:

# ip route add 1.0.0.0/8 via 1.2.3.133 dev eth1

Díky!