ifconfig -- automatikus route nélkül

Hálózatok általános

Kedves mindnyájan, aki tudja, árulja el, minő opciója van az ifconfignak arra, hogy *ne* hajtson végre automatikusan "route add -net ..." parancsot, amikor felhúzok egy Ethernet interface-t. Sőt, a még igazibb az lenne, ha azt is elárulná, hogy az /etc/network/interfaces/.. scriptekben mit kell tenni ugyanehhez...

Köszönettel "NevemTeve"

PS: Tudom, hogy ez szokatlan igény, de teljesen valós probléma, nem csak akadémikus kiváncsiság.

  • 4830 megtekintés

( vl v | 2012. 12. 20., cs – 16:49 )

ifconfig eth0 192.168.1.1 netmask 255.255.255.255 up
menőbben
ip addr 192.168.1.1/24 dev eth0

Az viszont nem működik, hogy a gép a saját ip címére menő forgalmakat másik (bármelyik kimenő) interfészen kiküldje a gépből, az ilyen forgalom mindenképpen gépen belül marad (és a lo interfészen keresztül talál "magára").

Illetve lehet még variálni a "Policy based routing" opcióival (ip rule), hogy a standard kimenő route-ok előtt bizonyos forgalmakat másfelé küldjön a gép.

Szóval a kulcs a netmask=255.255.255.255 megadása? Máris nézem!

Szerk: ez lett 

# ifconfig eth0:0 8.8.8.8 netmask 255.255.255.255 up
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         101.12.15.183   0.0.0.0         UG        0 0          0 eth0
101.12.15.128   0.0.0.0         255.255.255.128 U         0 0          0 eth0

Vagyis, úgy tűnik, pont az, amit akartam: nincs benne az új interface. Köszönöm szépen!

Bizonyára igazad van, amikor ezt így megkérdezed, csak a kérdés számomra ebben a formájában még nem jól értelmezhető... (forrás: Hankiss Elemér paródia)

Off: a régi szép időkben a derék rendszergazda maga írt egy '/etc/init.d/networking' nevű scriptet, amiben olyan és annyi modprobe/ifconfig/route/ipx_interface_add/ipfwadm/dhcp-client meg a többi volt, amennyi csak kellett -- ma már ez meg van könnyítve, az egyik script felolvas egy másik scriptet, ami egy harmadikból veszi a konfigurációt -- nem csoda, hogy ezt egy magamfajta öregember nem látja át.

Szerk: na, rájöttem, mire gondoltál: nem, egyszerűen csak beírtam valamit a teszteléshez...

a 255.255.255.255 (32 bit netmask) azt jelenti, hogy ez az egy ip van a "hálózatban", tehát nem kell route szabály a többi ip eléréséhez; ha a netmask rövidebb 32 bitnél, akkor azzal azt mondod a rendszernek, hogy x db (2, 4, 8, ...) ip cím van a tieddel együtt, és valahogy el kell érni a többi, a tieddel azonos hálózatban levő ip-t, ehhez kell a route szabály

lényegében a 32 bites netmaskkal csinálsz egy "bennszülött", mindenki más számára elérhetetlen hálózatot

Szerintem ugyan az az interfész, igen! El kellene már felejteni az ifconfig - route párost és végre az ip parancsot kellene megtanulni jól használni. Igen csak félrevezető lehet, ha az ifconfig nem mutatja meg, hogy mi is a valóság az IP címek körül! Jól be lehet kavarodni. Az alias interfész ideje lejárt, el kellene felejteni!
c

Tegyük hozzá, hogy a BSD-kben az ifconfig parancs némileg többet tud és konzisztensebben mint linuxon az ip és ami még kell hozzá, hogy mindent lehessen konfigolni:

BSD ifconfig(+route a teljesség kedvéért)=

ip
ifenslave
brctl
vconfig (ez már van újabb ip-ben)
tunctl (ez is)
iwconfig
iwlist
iw

A vlan és tun/tap kezelés már az újabb ip változatokban benne van továbbá mintha látnék kezdeményezéseket a brctl és az ifenslave migrálására, na de 10 év alatt ezt már igazán megtehették volna. Ja és a mai napig nincs normális RSTP a bridge kódban, de ez most csak kibukott. :)

Adjál két ip címet az eth0-nak:

ip addr add A dev eth0 label eth0:0
ip addr add B dev eth0 label eth0:1

aztán nézd meg ezt ifconfig-gal, és lám látod.

Az utolsó mondatod meg színtiszta trollkodás, mert amit ki kell írni, az még a totál olvashatatlan rövidítésekkel együtt is hosszabb. (Persze azt elismerem, hogy a parancs neve az valóban rövidebb.)

ifconfig eth0 A
ip a a A dev eth0

De én is tudom, hogy Linuxon állítólag a jövő az ip parancs, de azt is lássuk be, hogy fenti helyzetben kb. tök mindegy. (És ne feledjük, hogy egyelőre még vannak a világon olyanok, akik korábban láttak valamilyen Unixot, és csak később Linuxot, így a kistestvér agybaj szokásait nehezebben szokják meg :-)

Mondjuk a lényegre az ip parancs label részére (a'la virtuális interfész, meg nem látszik az ifconfig-ban) valahogy néha csend a válasz, de mindegy, ugorgyunk.

Szerintem ez egy abszolút életszerű példa következik.

ifconfig eth0 192.168.1.1
vs
ip addr add 192.168.1.1 dev eth0

Sajnos, mint azt az élet mutatja (és a dokumentáció is leírja), az első tökéletesen működik így is és az eth0 megkapja a C-osztályú (nem belekötni az elnevezésbe) /24-es netmaskot. Ellenben a második hibásan egy 255.255.255.255-ös netmaskkal honorálja.

Menjünk tovább, egy másik abszolút életszerű példa következik.

ifconfig eth0 192.168.1.1/24
vs
ip addr add 192.168.1.1/24 dev eth0

Sajnos a manuallal ellentétben az ifconfig így is elfogadja, és jó végeredménye is lesz a dolognak, de szerencsére az ip parancsnak is. Természetesen a dolog akkor is megy, ha nem "szabványos" netmask beállítására van szükség.

Összefoglalva: a 3-féle írásmódból 2-szer az ifconfig a rövidebb, egyszer az ip. Kicsit nyögvenyelős győzelemnek tűnik.

De ragozhatjuk ezt még. Van nekem egy eth1-em is, ami valamiért down-ban van.

ifconfig eth1 5.6.7.8/13 up

eredménye az élő, UP állapotú interfész (a megfelelő IP-címmel). Ellenben a manual azt írja, hogy ha címet kap az interfész, akkor implicit módon up -ba kerül, így a parancs végéről az up elhagyható - következésképpen a parancs rövidebb:

ifconfig eth1 5.6.7.8/13

De azonban pláne sőt ugyanez az ip parancsról már nem mondható el. Fenti interfasz konfigolásához a "modern":

ip address add 5.6.7.8/13 dev eth1

parancs sajnos nem elegendő - ugyanis down-ban marad. Ahhoz ugyanis kell még egy:

ip link set eth1 up

parancs is. (Épelméjű esetben egyébként előbb, de a végeredményen ez nem változtat.)

Összefoglalom: azt lehet (és javasolt) mondani, hogy az ifconfig és route parancsok a deprecated, obsolete (elavult, ósdi) kategóriába tartoznak, és ezért nem javasolt őket használni. Ellenben azt mondani, hogy azért használjuk helyettük az ip parancsot, mert az

a) rövidebb - no ez nem igaz;
b) az azzal felvett interfész címek nem látszanak az ifconfig parancs kimenetetében - no ez megint csak nem igaz, csak nem tudja az illető használni.

Úgyhogy talán maradjunk annyiban, hogy (talán) vannak dolgok, amit nem lehet ifconfig és route segítségével megcsinálni (pl. mintha a policy routing ide tartozna), illetve esetleg még jobb ezzel indokolni: IT'S CRAPPY, IT'S FUCKING INCONVENIENT, BUT THIS IS THE LINUX WAY.

ip addr add 192.168.1.1/24 dev eth0
ip addr add 192.168.1.2/32 dev eth0
ip addr add 192.168.1.3/32 dev eth0
ip addr add 192.168.1.4/32 dev eth0
ip addr add 192.168.1.5/32 dev eth0

Ha azt szeretnéd, hogy a géped válaszoljon az ARP csomagokra a .2-.5 címek iránt érdeklődő gépeknek ezen a networkön, akkor nem rakhatod a loopbackre a címeket (illetve rakhatod, de akkor mindenféle elbaszott feature-ökre lesz szükséged, amik azt eredményezik, hogy a géped akkor is válaszol egy ip címre az adott interfészen, ha azon az interfészen nincs is a gépnek olyan ip címe, aminek más mellékhatásai is lehetnek).

leteszteltem:

A gép: 172.16.1.1/32
B gép: 172.16.1.2/24

b # ping 172.16.1.1
a # tcpdump

07:38:44.452587 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 46
07:38:44.452617 ARP, Reply 172.16.1.1 is-at 00:03:0d:58:12:49, length 28
07:38:45.448236 IP 172.16.1.2 > 172.16.1.1: ICMP echo request, id 2217, seq 403, length 64
07:38:45.448265 IP 172.16.1.1 > 172.16.1.2: ICMP echo reply, id 2217, seq 403, length 64

B gép: nem kerül be A az arp táblába, és nem kap választ a ping-re

ahogy korábban írtam, A "benszülött" lett

A gép: 172.16.1.11/24 (172.16.1.1/32 továbbra is él)

B gép: bekerül 172.16.1.1 az arp táblába, és kap választ a 172.16.1.1 pingelésére, mivel A-nak a 172.16.1.11/24 miatt van megfelelő route sora

( NevemTeve | 2012. 12. 21., p – 18:44 )

Off: Háttér az eredeti kérdéshez: az 'A' gépnek a rendes ethernet kártyáján (eth0, ip=x.y.z.111) kívül vagy egy másik kártyája is ('eth1'), ami a 'B' géppel való dedikált kapcsolatra szolgál. A gond ott van, hogy a helyi policy miatt (amit nem én hoztam, és nem én fogok megváltoztatni), az 'eth1'-re az x.y.z.112-t kell ráhúzni (a 'B' gépre meg az x.y.z.113-t), de ettől még a két kártya _nem_ ugyanarra a szegmensre nyílik.

Természetesen örülök, ha elmondod; nekem önmagamtól csak két (eléggé triviális) meglátásom támadt (de egyik sem segít a konkrét helyzetben):
1. ne menjen két ethernet kártya ugyanabba a szegmensbe
2. ha viszont nem ugyanabba a szegmensbe mennek, akkor az IP-címek se úgy álljanak, mintha ez lenne a helyzet

( NevemTeve | 2012. 12. 22., szo – 00:26 )

Mondjuk ha ez a saját kis kísérleti projektem lenne (mint ahogy nem az), esetleg ezt is kipróbálnám (legfrissebb késő esti ötlet):

ifconfig eth0 x.y.z.111 netmask 255.255.255.0 up
ifconfig eth1 x.y.z.111 netmask 255.255.255.255 up
route add x.y.z.113 dev eth1
route add -net x.y.z.0 netmask 255.255.255.0 dev eth0 # illetve ez automatikus

vagyis megspóroltunk egy IP címet.

+1 jogos, engem is

nem kell ennyire művészi: http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186…

de esetleg walami hasonló sokat sokat dobna: http://www.gentoo-wiki.info/Bridging 

         Host A ------+-------------------+----- Host B
                      |                   |
                      |                   |       Interface 0
                 +--------+          +--------+
                 |  Br 1  |          |  Br 2  |
                 +--------+          +--------+
                      |                   |       Interface 1
                      |                   |
         Host C ------+-------------------+----- Host D

Nem nagyon szeretnék részletekbe menni -- nyilván világos, hogy nem az otthoni magánhálózatomról van szó... (Egyébként is, egyszerű programozó létemre csak úgy kerültem a történetbe, hogy szóba került, hogy a routing-problémák miatt esetleg az én kis programom bevezetése is csúszik... ezt nem nagyon akartam.)