Dotaz: Routovani nekdo zkuseny poradte

[abc]

Rad bych si poradit od zkusenejsich v routovani, zajimalo by me proc tohle nejde?

route -n
Směrovací tabulka v jádru pro IP
Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.16.0.1      10.0.0.142      255.255.255.255 UGH   0      0        0 eth0

ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_req=1 ttl=64 time=0.710 ms

ok je dostupny

sudo ip route add 172.16.1.1/32 via 172.16.0.1
RTNETLINK answers: No such process

proc?

vim ze se mu nelibi, ze nemam tu 172.kovou adresu na interfejsu (kde mam jen tu 10tkovou) a rve error, spis by me zajimalo proc to neni mozny, kdyz ten server pinguju?

Prece kdybych ted spojil sebe a ten 172.16.0.1 vpnkou, dal jim rekneme 192.168 adresy, a protoze se mi objevi 192.kova adresa na insterfejsu, tak logicky uz ten hop budu moci provest.

ip route add 172.16.1.1/32 via 192.168.whatever

tohle mi prijde uplne na pikacu...

Jde vubec nejak udelat takovy "next next hop". Asi to by to melo jit ne?, kdyz tohle vlastne dela napr. rip, ospf v ciscu? nebo jsem uplne vedle?

Odpovědi

[Skokan, Pavel]

mno, pro Vás je to snad stále brána 10.0.0.142 ...

[NN]

Nemuzes staticky routovat pres adresu(via 172.16.0.1), ktera nanalezi do primo pripojenych sit daneho zarizeni. Ping odpovida jenom proto, ze mas adresu serveru staticky naroutovanou. Spravne je to tedy takto:

sudo ip route add 172.16.1.1/32 via eth0(nebo 10.0.0.142)

Tim rikas, ze adresa 172.16.1.1 je dostupna za rozhranim eth0(za branou 10.0.0.142). RIP, a OSFP jsou dynamicke routovaci protokoly, ktere zanaseni cest resi automaticky.

[abc]

Mozna jsem dotaz polozil blbe, radsi pridam obrazek tim (172.16.0.1) a (172.16.1.1) jsem asi zmatl.

Zajimalo by me, jestli jde proskocit z PC1 do PC3 pres stroj PC2 (ktery nema NAT), tim ze na PC1,2,3 nastavim staticke routovani

      PC1         |     PC2(neni zde NAT)     |         PC3
                  |eth0                 (eth1)|
ja(10.0.0.139) -> |10.0.0.141       172.16.0.1| -> (172.16.1.1)
       /24        |  /24                 /24  |        /24

[Michal Kubeček]

Je-li to takhle, tak jste se jako gateway neměl snažit použít 172.16.0.1, ale tu adresu PC2, kterou vidíte, tedy 10.0.0.141. Pak pakety z PC1 na 172.16.1.1 opravdu dorazí do cíle (pokud není na PC2 zakázaný forwarding nebo je nezahodí nějaký filtr po cestě).

Jenže, jak je v podobných případech časté, problém nebude v cestě tam, ale v cestě zpátky. Se správně nastavenou gatewayí se sice váš paket dostane až na PC3, ale PC3 nejspíš nebude vědět, kudy poslat odpověď, protože adresa 10.0.0.139 mu nic neříká (a nejspíš ani tomu, kdo je mezi PC2 a PC3). Pokud vyřešíte i opačný směr, tak to fungovat bude a žádný NAT k tomu potřeba není.

[lertimir]

Vždy a všechno se routuje tak, že:

1. Na zařízení mám rozhraní.
2. Ty mají nějakou adresu a patří do nějaké sítě (síť/maska). Na těch sítích jsou routery které propojují dále.
3. A routovací tabulka je vždy pro nějakou (síť/masku) poslat do nějakého rozhraní a bud napřímo (brána 0.0.0.0) nebo na router, který pošle dále.

Když nahodím VPN tak se neobjeví 192.dova adresa na tom původním rozhraní, ale VPN vytvoří nové virtuální rozhraní s předělenou adresou sítě a maskou a případně routerem/routery, které to budou posílat dále. A pro toto nové rozhraní se vytvoří příslušná routovací pravidla. Tabulka je vždy jen lokální, žádný next next hop není.

RIP a OSPF si posílají informace na jejichž základě tyto lokální tabulky generují, RIP má distace vector a OSPF ma link state protokoly, ale tyto informace nejsou v lokální routovací tabulce.

[Vantomas]

Toto udělat nejde. Umí to routovací protokoly, říkají tomu rekurzivní výpočet trasy, kdy si to daemon může dovolit díky znalosti všech route v síti, ale lokálně to daemon do jádra vždy umístí jako route 172.16.1.1/32 via 10.0.0.142 a teprve až tento další skok to odroutuje na správné místo.

Routování zkrátka funguje pouze lokálně v rámci jedné L3 sítě. Stejně jako komunikace na ethernetu funguje pouze v rámci jedné L2 sítě. Jako nejde poslat něco přímo na nějakou MAC adresu v jiné L2 síti, stejně tak nejde poslat nic přímo v jiné L3 síti.

[Adam]

Vím, co myslíš, ale jak psali i ostatní, nejde to tak jednoduše. Routa se dá vyrobit jen na adresy, které jsou v lokálním subnetu. Čili, pokud tam jsou všude statické routy, tak by se muselo přidat na každý bod cesty routování, až do chvíle, kdy je cílová adresa dostupná z lokálního subnetu.

V tom nákresu bude chybět jeden router, který ze subnetu 172.16.0.0/24 zpřístupňuje 172.16.1.0/24.

V PC1 musí být routa 172.16.1.1/32 na 10.0.0.141.

V PC2 už asi bude routa 172.16.1.0/24 na 172.16.0.xy, který v nákresu chybí (může jít třeba i o bránu).

V PC3 musí být routa 10.0.0.139/32 na 172.16.1.xy (možná ta brána).

V routeru XY (možná brána) bude muset být routa 10.0.0.139/32 na 172.16.0.1