Portál AbcLinuxu, 1. května 2025 15:27
V firmě máme dvě lokality, v každé z nich je pár privátních sítí, které nejdou navzájem routovat přes internet. Ale protože potřebujeme spojení mezi lokalitami neomezeně, používáme IPsec tunel, a sice OpenSwan. Běží to přímo na linuxových hraničních routerech. V konfiguraci IPsecu je napsáno, že co jde do privátní sítě na druhé straně, ať to zabalí a pošle tunelem. Na jednu síť jsme zapomněli, v konfiguraci IPsecu není, a přesto má konektivitu. Akorát že traceroute ukazuje o dva hopy víc než by měl a jako mezistanice samé hvězdičky.
Přesněji je to takto: požadavek na spojení přijde do hraničního routeru z nějaké VLANy. Projde pravidly iptables, kde není přesměrován ani zahozen, nýbrž akceptován. Teď by měl odejít defaltní routou do internetu a tam se ztratit, protože cílová adresa je 10.x.x.x . Avšak neodejde, jak jsem zjistil tcpdumpem na externím rozhraní routeru. Spojení s privátní adresou v druhé lokalitě se uskuteční jako by se nechumelilo. Nemám pro to jiné vysvětlení, než že se jádro stydí poslat paket směřující do privátního rozsahu do defaltní routy. Místo toho se paket pořád jenom v jádře nějak mrcasí, což ho stojí dvě TTL jednotky, a potom ho dostane IPsec démon a normálně pošle. Celé se to tedy zachová, jako kdyby paket navazující spojení přišel z jiné VLANy než ze které ve skutečnosti přišel. Funguje TCP a ping, nic jiného jsem nezkoušel. Sakra to jsou ty systému vážně tak inteligentní?
Tiskni
Sdílej:
Jen bych upozornil, že výpis směrovací tabulky není to, co ukazuje příkaz route, ale to, co ukazuje 'ip route show' nebo ještě lépe 'ip route show table all' a 'ip rule show'.
Jinak konfigurace FreeS/WAN byla vždycky trochu mystická a po přechodu na ipsec-tools (setkey a racoon) jsem zjistil, že je všechno najednou mnohem průhlednější, když se nemlží vlastními matoucími pojmy a používají se ty standardní. Celkově v používání OpenSWAN na dnešních jádrech nevidím moc smysl.
Jen bych upozornil, že výpis směrovací tabulky není to, co ukazuje příkaz routeTakže mě někdo mystifikuje?
man route route - show / manipulate the IP routing table
route --help Usage: route [-nNvee] [-FC] [<AF>] List kernel routing tables
route je v Linuxu obsolete od jádra 2.2 (vyšlo v lednu 1999). Takže vám sice v dobré víře ukáže, co si myslí, že je směrovací tabulka, ale ani zdaleka nemůžete spoléhat na to, že vám ukáže všechno, co potřebujete vědět.
1. Já to třeba v ifconfig(8) mám (a ne, nenapsal jsem si to tam sám). Jinak třeba tady a na spoustě dalších míst. Stačí nezavírat oči.
2. To už jsem udělal mnohokrát, ale pokud si úmyslně zadefinujete "běžné" situace jako ty, kdy ifconfig a route jakž takž stačí, pak to samozřejmě už z principu nepůjde. Pro zajímavost si zkuste porovnat i na zcela "běžném" systému výstup 'route -n' a 'ip route show table all'. Myslíte si, že to, co ukazuje druhý příkaz navíc, je nějaká fikce? Nebo si snad myslíte, že tyto položky nemají vliv na směrování paketů?
ifconfig a route naprosto postačuje. Navíc má o mnoho příjemnější syntaxi.
ifc<TAB>eth0 IP/maska upvs
ip addr add IP/maska dev eth0
18.8.2011 14:59
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
ifconfig eth0:n IP/maska
ifconfig eth0:n IP/maska
ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:13:d3:d2:bb:ef brd ff:ff:ff:ff:ff:ff
inet 192.168.26.1/32 scope global eth0
inet 192.168.2.175/24 brd 192.168.2.255 scope global eth0
inet 192.168.0.175/24 brd 192.168.0.255 scope global eth0
inet 172.16.34.175/16 brd 172.16.255.255 scope global eth0
inet6 fe80::213:d3ff:fed2:bbef/64 scope link
valid_lft forever preferred_lft forever
A co mi ukaze ifconfig?
ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:13:d3:d2:bb:ef
inet addr:192.168.26.1 Bcast:0.0.0.0 Mask:255.255.255.255
inet6 addr: fe80::213:d3ff:fed2:bbef/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:254104359 errors:0 dropped:5146 overruns:0 frame:0
TX packets:130721632 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3197090190 (2.9 GiB) TX bytes:3644918187 (3.3 GiB)
Interrupt:17
No a kde je ten zbytek adres? Navic, primarni by mela byt 172.16.34.175 (DHCP) - kde je? To se pak nediv, ze ti pak chodi nejaky packety neznamo odkud a neznamo kam, kdyz vidis jenom pulku nastaveni (resp. mozna jenom 10%).
To je alias, ne dve adresy.
On to právě není alias, jen se to tak tváří. IP aliasing jako takový fungoval naposledy v řadě 2.0 (IIRC pouze v řädě 2.0). Problém (jeden z problémů) je právě v tom, že se ifconfig dodnes tváří, jako by tam skutečně existovalo virtuální rozhraní, což dávno není pravda. Navíc další adresy vidí a zobrazuje jen v případě, že mají přiřazený label (což demonstruje váš příklad).
Jestli jsem to dobře pochopil, výrazem příjemnější rozumíte kratší. V tom případě se můžete vykašlat na srozumitelnost a psát 'ip a a addr/prefixlen dev eth0' (IIRC spíš musíte, protože ip IIRC zápis s maskou ani nepodporuje).
Z filosofického hlediska má navíc ip jednu zcela zásadní výhodu: odpovídá tomu, co skutečně děláte - přidáváte na rozhraní adresu. Syntaxe ifconfig pořád vychází z toho, co už přes dvanáct let neplatí: že má rozhraní jednu adresu, která se nastavuje. Příznačné je, že pro IPv6 tentýž příkaz najednou realitu bere na vědomí a používá add a remove.
Příznačné je, že pro IPv6 tentýž příkaz najednou realitu bere na vědomí a používá add a remove.Neni to primarne proto, ze u IPv4 se vseobecne pocitalo s tim, ze rozhrani ma jen jednu adresu (a vic adres je tedy rozsireni nekterych implementaci), tak u IPv6 se standardne pocita s vice adresama? Treba u toho IPv4 mnoho navazujicich standardu ma s vice adresama problem (treba OSPFv2).
1. U IPv6 je skutečně pro plnou funkcionalitu nutné mít možnost přiřadit rozhraní více adres. Ale co se IPv4 týká, nejsem si vědom toho, že by standard nějak přikazoval nebo aspoň doporučoval mít jen jednu.
2. Skutečně je to problém OSPF jako takového? Není to spíš problém konkrétních implementací?
U OSPFv2 standard predpoklada 'jedna linka - jeden prefix'.Tedy s vyjimkou ptp (a ptmp) linek, ktere prefix mit nemusi.
Z filosofického hlediska má navíc ip jednu zcela zásadní výhodu: odpovídá tomu, co skutečně děláte - přidáváte na rozhraní adresu. Syntaxe ifconfig pořád vychází z toho, co už přes dvanáct let neplatí: že má rozhraní jednu adresu, která se nastavuje.Mě jedna adresa na rozhraní zatím skoro vždy stačila (OK, IPv6 je výjimka).
'ip route show table all'No, to je trochu zavadejici, nebot to vypise i obsah tabulky 'local', ktera ma specifickou funkci a rozhodne se nejedna o beznou routovaci tabulku. Pokud clovek srovna 'route -n' a 'ip route show', tak to na beznych konfiguracich vypise vicemene to same.
tabulky 'local', ktera ma specifickou funkci a rozhodne se nejedna o beznou routovaci tabulku
S takovou formulací bych určitě nesouhlasil. Tabulka local (255) je normální tabulka, která se zpracovává úplně stejně jako všechny ostatní. Zvláštní jsou na ní jen dvě věci: za prvé je defaultní tabulkou pro přidávání položek typu local a broadcast (a možná i některých dalších), ale stejně tak je main (254) defaultní pro typ unicast a některé další. Za druhé: automaticky vytvářené pravidlo s prioritou 0 zajišťuje, že se tato tabulka prohledává pro všechny pakety jako první. Jinak ale tato tabulka funguje stejně jako všechny ostatní.
Pokud clovek srovna 'route -n' a 'ip route show', tak to na beznych konfiguracich vypise vicemene to same.
Ne úplně, první příkaz vám IIRC neukáže třeba MTU, metriku nebo preferovanou zdrojovou adresu. Ale především vám ani jeden neukáže dostatek informací na to, abyste mohl určit, jak se bude konkrétní paket směrovat.
S takovou formulací bych určitě nesouhlasil. Tabulka local (255) je normální tabulka, která se zpracovává úplně stejně jako všechny ostatní.Hlavni rozdil bych videl v tom, ze tabulka 'local' je asi dost linuxove specifikum - pokud si predstavim jakysi genericky koncept IPv4 routovani a pak jeho jednotlive implementace, pak tabulka 'local' (resp. ty polozky typu 'local' a 'broadcast') resi to, co v ostatnich implementacich (ci v tom generickem modelu) je reseno mimo routovaci tabulku jinymi strukturami. Ze v Linuxove implementaci to chytre sloucili do stejnych struktur je sice pekne, ale tezko to potom porovnavat.
17.8.2011 22:55
xxx | skóre: 42
| blog: Na Kafíčko
Imho je tam skutecne neposle. 10.0.0.0/8 neni globalne smerovatelna, takze na takovem rozhrani nema co delat. NAT/Maskarada funguje proto, ze se paketu na vstupu veme, zmenej se mu adresy, a pak uz je korektni paket vlozen, tusim primo do vystupni fronty pozadovaneho rozhrani. (Coz by znamenalo, ze se o jeho smeru vubec nerozhoduje routovaci tabulka. Ale nejsem si zcela jist, je to uz delsi dobu co sem to studoval.)
NAT/Maskarada funguje proto, ze se paketu na vstupu veme, zmenej se mu adresy, a pak uz je korektni paket vlozen, tusim primo do vystupni fronty pozadovaneho rozhrani.
To určitě ne, jak by se pak poznalo, které rozhraní to má být (a kdo má být další hop)? Překlad zdrojové adresy (tj. i maškaráda) se provádí až na konci, kdy už je o směrování rozhodnuto. Překlad zdrojové adresy naopak probíhá - aspoň u průchozích paketů - ještě před směrováním, ale paket je pak směrován podle standardních pravidel a tabulek. Trochu složitější je to jen při přepisu cílové adresy (případně značky) u lokálně generovaných paketů, ale i tam v zásadě platí, že bez ohledu na NAT o směrování rozhodují standardní mechanismy.
Na druhou stranu, pokud se používá IPsec (a zvláště v tunelovacím modu), je potřeba dávat pozor ještě na to, kdy se na paket aplikuje SP, která také může zamíchat kartami.
17.8.2011 23:26
xxx | skóre: 42
| blog: Na Kafíčko
Mate pravdu, staci zadat do Googlu iptables a mrknout se co to naslo za obrazky.
Překlad zdrojové adresy naopak probíhá - aspoň u průchozích paketů - ještě před směrováním
Tady samozřejmě mělo být cílové, omlouvám se za nepozornost.
Bohužel není možné, abych zveřejnil topologii firemní sítě. Jak vidím, všeobecný názor je, že jádro neví nic o veřejných a privátních rozsazích. My teď opravíme konfiguraci, aby všechny routy byly definované. Tím ty záhady přestanou být vidět a budeme moci na ně zapomenout.
Prošlo to tam na úrovni Ethernetu VLANou, která vede radiospojem mimo routování a málokdo ze správy sítě o tom věděl. Na jedné straně je mi líto, že máme v síti nepořádek. Na druhé straně jsem rád, že jádro linuxu se nestydí a ten plyšovej talisman zatím ještě není tak úplně nezbytný.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.