IP-alapok

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen KornAndras (vitalap | szerkesztései) 2012. február 29., 13:23-kor történt szerkesztése után volt.

Itt most az IPv4-ről lesz szó. Az IPv6-tal nem foglalkozunk (talán megérdemelne egy külön tantárgyat).

Tartalomjegyzék

 [elrejtés] 

1 A protokollcsaládról

  • Az Internet Protocolra gondolhatunk úgy, mintha az OSI modell hálózati rétegében helyezkedne el, noha az IP és az ISO/OSI referenciamodell között nem feltétlenül egyszerű bijekciót létesíteni. Csomagkapcsolt hálózatot valósít meg, ami annyit jelent, hogy nem épít fel semmilyen kapcsolatot a forrás és a cél között, hanem minden egyes csomagot külön juttat célba (route-ol). Megoszlanak a vélemények arról is, hogy a TCP/IP protokollcsaládnak egészen pontosan melyik protokollok is a részei és melyek nem, de ilyen finomságokkal és filozófiai mélységekkel itt nem foglalkozunk.
  • Az IP-vel kapcsolatos főbb protokollok:
    • ARP (Address Resolution Protocol)
    • IP (Internet Protocol)
    • ICMP (Internet Control Message Protocol)
    • TCP (Transmission Control Protocol)
    • UDP (User/Unreliable Datagram Protocol)

1.1 IP (Internet Protocol)

  • hálózati rétegbeli
  • datagramm-alapú
  • néhány mező a fejlécből:
    • forráscím
    • célcím
    • TTL (Time To Live)
    • magasabb szintű protokoll azonosítója
    • egyéb (pl: DF, Don't Fragment, PMTU discoveryhez)
  • klasszikus támadások:
    • flood (bármilyen protokollal lehet, nem IP-specifikum),
    • spoofing (címhamisítás),
    • teardrop (egymást átfedő fragmentumok),
    • ping of death (64k-nál nagyobbnak tűnő csomag, nem csak ICMP lehet).

1.2 ICMP (Internet Control Message Protocol)

  • hiba- és státuszüzenetek, pl:
    • Echo Request (ping)
    • Echo Reply (ping válasz)
    • Destination Unreachable; altípusai pl:
      • Network Unreachable (nincs route az adott hálózat felé)
      • Host Unreachable (az adott gép nem elérhető, pl. nem válaszol ARP-re)
      • Protocol Unreachable (Az IP 1 bájton kódolja, milyen magasabb szintű protokollt szállít. Ilyen ICMP hibaüzenetet kapunk, ha a megszólított gép az adott magasabb szintű protokollt nem támogatja.)
      • Port Unreachable (Az adott UDP porton nincs szolgáltatás.)
      • Fragmentation Needed (l. lejjebb a PMTU discoverynél.)
      • Communication Administratively Prohibited
    • Time To Live Exceeded
    • és még jó pár, ritkábban látott másik
  • klasszikus támadások pl.:
    • flood,
    • smurf,
    • ...

1.3 TCP (Transmission Control Protocol)

  • összeköttetés-alapú
  • garantálja a csomagok helyes sorrendjét
  • újraküldi a csomagokat, ha kell
  • torlódásvezérelt
  • port fogalma ("lokális multiplexelés")
    • "nyitott" vs. "zárt" port
    • bind(), majd listen()
  • kapcsolatfelépítés (l. lejjebb is):
    • SYN
    • SYN+ACK
    • ACK
  • klasszikus támadások:
    • SYN flooding (l. lejjebb),
    • connection spoofing,
    • session hijacking,
    • "LAND" (azonos forrás- és célcím),
    • ...

1.4 UDP (User/Unreliable Datagram Protocol)

  • itt is van port
  • nincs nyugta
  • nincs torlódásvezérlés
  • a folyam csomagjai elveszhetnek, ill. megjöhetnek rossz sorrendben
  • cserébe "könnyűsúlyú" protokoll
    • nem kell hozzá állapotgép, nincs kapcsolatfelépítés => gyorsabb adatküldés
    • kisebb fejléc
  • Használja:
    • DNS
    • VoIP
    • streaming
    • VPN-ek
    • játékok
    • p2p (peer to peer)
    • stb.
  • klasszikus támadások:
    • fraggle (kb. mint a smurf, udp echo ellen),
    • ...

1.5 ARP (Address Resolution Protocol)

  • Az IP egy hálózati rétegbeli protokoll
  • A hálózati szint alatt még van egy adatkapcsolati és egy fizikai réteg
  • Az adatkapcsolatiban is kellhet címzés
  • Honnan tudjuk a másik fél adatkapcsolati címét?
  • Az IP alatt gyakran van Ethernet, vagy ahhoz hasonló broadcast médium
  • Ötlet: ha nem tudjuk a címet, kérdezzük meg! 
00:de:ad:be:ef:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 1.2.3.4 tell 1.2.3.1
00:f0:0d:d0:0d:00 > 00:de:ad:be:ef:00, ethertype ARP (0x0806), length 60: arp reply 1.2.3.4 is-at 00:f0:0d:d0:0d:00
  • Egy darabig megjegyezzük az ARP-táblánkban
  • Igen ám, de nem vagyunk mindenkivel egy fizikai hálózaton - a többiek MAC-címét honnan fogjuk megtudni?
  • Sehonnan, mert nem is kell => routing
  • ARP-alapú visszaélések:
    • ARP spoofing (hamis választ küldünk)
      • Ezen keresztül lehallgatás, man-in-the-middle, DoS
    • ARP flooding (pl. a Solaris egyes régi verziói lefagynak tőle)
  • ProxyARP pseudobridge:
    • A végpontok higgyék azt, hogy egy fizikai hálózaton vannak
    • A köztük levő routerek válaszolnak mindenki helyett az ARP-re

ProxyARP bekapcsolása linuxon: 

# echo 1 >/proc/sys/net/ipv4/conf/interfaceneve/proxy_arp

1.6 Path MTU Discovery

  • Az IP-csomagok maximális mérete 65535 bájt (1 bájt híján 64K) lehet.
  • Ez egy elméleti maximális csomagméret, amit az alkalmazott fizikai hálózat jellemzőiből adódó korlátok jelentősen csökkenthetnek; pl. az Ethernetet alkalmazva maximálisan 1500 bájtnyi hasznos terhet szállító IP-csomagokat tudunk átjuttatni a hálózaton, mert egy Ethernet-keretbe nem fér több adat. (Kivéve, ha jumbo frame-eket használunk, de itt most nem ez a lényeg.)
  • Mivel a különböző helyeken sokféle technológiákat alkalmazhatnak, ezért a nagy csomagokat fel kell darabolni, hogy egy adott hálózati útvonal minden szakaszán átférjenek.
  • Azt a jellemzőt, hogy egy adott fizikai interfészen legfeljebb mekkora IP-csomag küldhető ki, MTU-nak (Maximum Transmission Unit) nevezzük.
  • Az ennél nagyobb csomagokat a routerek automatikusan fragmentálják, ami több szempontból sem jó:
    • Ha egy töredék elvész, az egész csomagot újra kell küldeni.
    • Nagyobb az overhead (mind a hálózati, mind a processing-).
    • A butább tűzfalak minden töredezett IP-csomagot kiszűrnek, mert
      • korábban érvénytelen csomagtöredékekkel DoS-t lehetett megvalósítani és
      • mert csak az első töredék tartalmazza a magasabb szintű protokoll fejlécét, ami alapján a tűzfal szűrni tud.
    • Talán érdemes itt megemlíteni, hogy az IPv6-ban már a végpontok feladata a fragmentálás, a routerek semmiképpen nem foglalkoznak vele.

Annek a kiderítésére, hogy egy teljes útvonalon mi a legkisebb MTU, használható a Path MTU Discovery algoritmus. Az algoritmus úgy működik, hogy a célállomásnak először akkora csomagot próbál küldeni, amekkora a saját MTU-ja azon az interfészen, amelyen az adott cél felé a routing-táblája alapján a csomagokat ki kell küldenie; ezeken a csomagokon beállítja a DF (Don't Fragment) bitet. Ha útközben valamelyik routeren ez a csomag "nem fér át", akkor a router ICMP Fragmentation Needed hibaüzenetet küld a forrásnak, és a csomagot eldobja. Az okosabb routerek azt is megmondják, mekkora lenne az MTU a következő routerig, így a forrás megtudja, mekkora csomaggal próbálkozzon legközelebb. Ha az adott router nem okos, akkor a forrás pl. bináris kereséssel találhatja meg a PMTU-t.

1.7 Részletesebben a TCP-ről

Kicsit foglalkozzunk a TCP néhány olyan jellemzőjével, amire nem biztos, hogy mindenki emlékszik korábbi tanulmányaiból.

1.7.1 Nyugtázás

Egy adatcsomag egyben nyugta is lehet; ha be van billentve a fejlécében az ACK bit, akkor amellett, hogy esetleg szállít adatot is, nyugtázza a korábban megkapott adatokat is.

  • Hogy melyikeket, az a nyugtaszámból derül ki.
  • Minden elküldött bájtnak van egy sorszáma, amit a kapcsolat során nem nullától, hanem egy ISN-től (Initial Sequence Number) kezdenek számolni.
  • A nyugták ezeket a szekvenciaszámokat nyugtázzák.
  • Ha tehát az én oldalamon 42 volt az ISN, és kapok egy 100-as sorszámú nyugtát, akkor az azt jelenti, hogy a 42-99-es sorszámú bájtokat a túloldal sikeresen átvette, és most nekem a 100-as sorszámú bájttal kell majd folytatnom az adást.

1.7.2 Kapcsolatfelépítés

A TCP-kapcsolat felépítése úgy történik, hogy a kliens kitalál egy ISN-t, és egy ezt tartalmazó TCP SYN üzenetet küld a szervernek (olyan TCP-csomagot, amelyben a SYN bit be van állítva). A SYN csomag tehát az alábbi információkat tartalmazza biztosan:

  • forrás IP-címe (az IP-fejlécből);
  • cél IP-címe (szintén);
  • forrásport (a TCP-fejlécből);
  • célport (szintén);
  • kliensoldali ISN.

A szerver erre egy olyan csomaggal válaszol, amelyben a SYN és az ACK bitek vannak beállítva (ezért szokás ezt a csomagot SYNACK vagy SYN+ACK csomagnak hívni); ez a csomag tehát nyugtacsomag, az ACK-kal nyugtázzuk a kliensoldali ISN-t, a SYN mellé pedig mellékeljük azt az ISN-t, amit mi találtunk ki ehhez a kapcsolathoz.

A kapcsolat felépítését a kliens egy olyan ACK csomaggal zárja le, amelyben a szerver ISN-jét nyugtázza.

  • Az ISN-t azért nem nullától célszerű számolni, mert ha kiszámítható ISN-eket választunk, akkor azzal egy támadónak lehetősége nyílik az ún. blind connection spoofing támadásra. Lényege:
    • A gép megbízik B gépben (tehát pl. B-ről szabad kapcsolódni A-ra).
    • A támadó elérhetetlenné teszi B gépet.
    • A támadó B forráscímével SYN csomagot küld A-nak.
    • A B-nek válaszol, így a válaszcsomagot a támadó nem kapja meg, de mivel ismeri az ISN-t, úgy tehet, mintha megkapta volna a SYNACKot, és küldhet azt nyugtázó ACK-ot (még mindig B nevében).
    • Így A azt hiszi, B kapcsolódott hozzá, a támadó pedig B nevében tetszőleges adatokat/parancsokat küldhet A-nak; az egyetlen nehézség az, hogy nem látja a választ (ha erről más módon nem gondoskodik).
  • Védekezés:
    • Nehezen kitalálható ISN-nel;
    • reverse path filteringgel (l. később).
  • Hasonló támadás a blind connection reset:
    • ha a támadó tudja, hol tart a nyugtaszámláló egy kapcsolatban, küldhet olyan csomagot, ami lezárja a kapcsolatot valamelyik fél nevében (vagy akár mindkét fél nevében, kölcsönösen).
  • Általában is: ha egy támadó tudja, mi egy TCP-kapcsolatban a következő szekvenciaszám, és tudja hamisítani a forráscímét, akkor a hamis forráscím nevében csomagokat tud beszúrni a kapcsolatba; pl. egy telnet-kapcsolatba az "rm -rf /\n" tartalmú adatcsomagot.
    • Ezért is jó az SSH, nemcsak a lehallgatásbiztossága miatt.
1.7.2.1 SYN-támadás

A szervernek normális esetben a SYNACK csomag kiküldésével egyidőben memóriát kell allokálnia, amiben megjegyzi a kapcsolat paramétereit: a kliens címét, portszámokat, ISN-eket stb. Ha a kliens nem fejezi be a kapcsolat felépítését, akkor a szerver néhányszor újra elküldi a SYNACK csomagot (hátha az első elveszett), aztán időtúllépés miatt eldobja a kapcsolatot; addig viszont valamennyi memóriát lefoglalva tart. Ha egy támadó sok kapcsolatot kezd el, de egyiket se fejezi be, akkor az erre a célra fenntartott memóriaterület (a tcp backlog queue) megtelhet, és a szerver a legitim kapcsolatokkal sem tud foglalkozni; l. a Wikipédián is.

Ez ellen a támadás ellen védekezhetünk pl. a Syncookie algoritmus használatával. Az algoritmus lényege az, hogy minden megjegyzendő adatot vagy belekódolunk a szerveroldali ISN-be (amit majd visszakapunk a kliens ACK üzenetben), vagy figyelmen kívül hagyunk (mert nem kritikus a kapcsolat létrejötte szempontjából).

Arra vigyázni kell, hogy ne lehessen könnyen olyan szekvenciaszámot kitalálni, amely alapján a szerver felépít egy érvényes kapcsolatot, mert akkor egy támadó SYN-csomag küldése nélkül tudna kapcsolatot felépíteni a szerverrel, ami Rossz, értem?. (Főleg régebbi tűzfalak a SYN-csomag alapján azonosítják az új kapcsolatokat; ha SYN nélkül is lehetne kapcsolatot nyitni, akkor ezzel meg lehetne kerülni a tűzfalat.)

A Syncookie algoritmus hátrányai:

  • Korlátozza a kapcsolatok paramétereit (bővebben l. a Wikipédián);
  • ha a háromutas kézfogás utolsó csomagja (az ACK) nem ér célba, a szerver sosem küldi újra a SYNACK-ot (hiszen nem jegyezte meg, hogy van egy félig nyitott kapcsolata), így a kliens nem tudja meg, hogy az ACK csomagja elveszett. Ha az alkalmazásszintű protokoll olyan, hogy az első üzenetet a szervernek kellene küldenie (ilyen pl. az SMTP), akkor a kliens csak állni fog és várni (abban a boldog, ám téves hitben, hogy érvényes TCP-kapcsolata van a szerverrel), a szerver pedig minderről nem sejt semmit. Persze egy ésszerű idő után az alkalmazás valószínűleg nem vár tovább, de nem árt ezzel a hibalehetőséggel tisztában lennünk, ha TCP-alapú hálózati protokollt, vagy azt megvalósító alkalmazást készítünk.
  • Bejövő SYNfloodra kimenő SYNACK-flooddal válaszolunk;
    • ez pl. ADSL-nél nyilván nagyon nem jó...
  • lepattintható rólunk egy SYN-áradat, ha hamis forráscímmel küldik.

2 Statikus routing

  • Minden gépnek van egy routing-táblája, ilyesmi bejegyzésekkel:
IP netmask gateway interface megjegyzés
1.2.3.0 255.255.255.0 * eth0 ez egy fizikai helyi hálózat, az eth0-án lóg
2.3.4.5 255.255.255.255 1.2.3.2 eth0 a 2.3.4.5-ös gépet az 1.2.3.2 című routeren át érjük el, "amögött" van
3.4.5.128 255.255.255.128 1.2.3.42 eth0 a 3.4.5.128/25-ös hálózat a 1.2.3.42 című routeren át érhető el, "amögött" van
0.0.0.0 0.0.0.0 1.2.3.254 eth0 Minden más ("az egész Internet") az 1.2.3.254 című routeren át érhető el

Fontos szabály: Mindig a leghosszabb illeszkedő prefixű bejegyzés "nyer". Pl. ha van route-unk a 10.0.0.0/8 felé az eth1-en át és a 10.0.0.0/24 felé az eth0-án át, és a 10.0.0.1-et akarjuk megszólítani, az eth0-án próbálkozunk.

Ha egy adott konkrét A.B.C.D IP-címmel akarunk kommunikálni, a következők szerint járunk el:

  • Megnézzük, az IP-cím része-e valamelyik helyi hálózatnak a cím/maszk párok alapján ("helyi" az a hálózat, amihez nincs gateway a routing-táblában)
    • Ha igen, ARP queryt küldünk
      • A válaszban benne lesz a MAC-cím
      • MAC-szinten oda, IP-szinten A.B.C.D-nek címezzük a csomagot
      • Ha nincs ARP-válasz, "host unreachable"
    • Ha nem:
      • Megnézzük, az IP-cím illeszkedik-e valamelyik más routing-bejegyzésünk cím/maszk párosára
        • Ha igen, a csomagot MAC-szinten az adott gatewaynek, IP-szinten A.B.C.D-nek kell címeznünk
          • Vagyis: ARP who-has IP-of-gateway
        • Ha nem, akkor nem tudjuk, merre kell küldeni a csomagot, "network unreachable" ("no route to host")

2.1 Reverse path filtering

Egyszerű, de sok esetben hatásos védekezés a hamisított forráscímű (spoofolt) csomagok ellen:

  • Ha bejön egy csomag x feladóval az i interface-en:
    • Nézzük meg, hogy a routing-tábla szerint, ha x-nek akarnánk csomagot küldeni, az i interface-en küldenénk-e ki;
    • Ha igen, jó;
    • Ha nem, x "valójában" nem is "arra van", úgyhogy a csomag "biztos" hamis.
  • Aszimmetrikus routingnál nem működik.

Bekapcsolása linuxon: 

# echo 1 >/proc/sys/net/ipv4/conf/interfaceneve/rp_filter

2.2 A routing-tábla karbantartása

Linuxon:

  • route parancs:
    • route add -net 1.2.3.0/24 dev eth0
    • route add -host 2.3.4.5 gw 1.2.3.2
      • Az eth0 következik a gw címéből
    • route add -net 3.4.5.128/25 gw 1.2.3.42
    • route add default gw 1.2.3.254
    • route -n
  • ip parancs:
    • ip ro add 1.2.3.0/24 dev eth0
    • ip ro add 2.3.4.5/32 via 1.2.3.2
    • ip ro add 3.4.5.128/25 via 1.2.3.42
    • ip ro add default via 1.2.3.254
    • ip ro sh

2.3 Statikus route-ok automatikus felvétele

  • Debianon és Ubuntun:
/etc/network/interfaces-be:
iface eth0 inet static
address 1.2.3.1
netmask 255.255.255.0
broadcast 1.2.3.255
network 1.2.3.0
gateway 1.2.3.254
up ip ro add 2.3.4.5/32 via 1.2.3.2
up ip ro add 3.4.5.128/25 via 1.2.3.42
  • Red Hat Linuxon:
/etc/sysconfig/network-scripts/route-<interface-name>-be:
ADDRESSn=<network>
NETMASKn=<network/prefix mask>
GATEWAYn=<next-hop router/gateway IP address>
  • SuSE Linuxon:

?

  • FreeBSD-n:

?

  • Solarison:
Default routerek:
/etc/defaultrouter-be IP cím vagy hostname
Nem default routerek:
/etc/gateways-be:
host destination gateway gateway metric hops , vagy
net destination gateway gateway metric hops
Ha mindenáron hoszt nevet akarunk megadni, akkor csak olyat, ami benne van az /etc/inet/hosts-ban!
  • OpenBSD-n:

?

  • Gentoo Linuxon:
A Gentoo a az /etc/init.d/net.lo-ra mutató symlinkekkel operál az ethn interfész felhúzásakor; így ha pl. eth0 és eth1 interfészeket akarunk használni, akkor ln -s net.lo net.eth0 illetve ln -s net.lo net.eth1 a használandó parancsok. Ezek automatikus felhúzása boot után az rc-update add net.eth0 default ill. rc-update add net.eth1 default parancsokkal lehetséges.
Azt, hogy az egyes interfészeket hogyan szeretnénk alapesetben indítani, az /etc/conf.d/net fileban adhatjuk meg. A példa elég értelemszerű:
config_eth0=("192.168.2.210 netmask 255.255.255.0")
routes_eth0=("default gw 192.168.1.254")
itt soroljuk fel a többit is
Jó tudni, hogy az alapértelmezés DHCP. Azaz ha nem adunk meg semmit, de DHCP klienst futtatunk, akkor azzal próbálkozik a rendszer.

--TechyZoltan 2006. szeptember 12., 20:55 (CEST)

3 VLAN

Írta: Rostás Attila.

VLAN a Linux-on, Debian alatt

Mi is az a VLAN? A VLAN (Virtual Local Area Network) az IEEE 802.1Q szabványban definiált. VLAN segítségével a hálózatok fizikai kialakításától függetlenül definiálhatunk logikai (szoftveresen létrejövő) broadcast hálózatokat az egy ugyanazon VLAN hálózatban szereplő host-ok között. A VLAN megvalósítása az OSI modell 2. rétegében, a adatkapcsolati rétegben történik. Gyakorlatilag a hálózati csomagok kapnak még egy 4 bájtos (*) fejlécet amelyben definiálva van egy 12 bites VLAN Identifier (VID), mely 4096 külön logikai hálózatot tenne lehetővé egy ugyanazon hálózati interface-n, vagy kábelen. Ennél a gyakorlatban – implementációtól függően – valamelyest kevesebb érhető el. A 0. és a 4095. VLAN a szabvány szerint foglaltak. Az 1. VLAN pedig a mindenki számára látható forgalmat jelenti. (Átlátszó VLAN.) A VLAN hálózatokban két eszköz akkor van azonos logikai közegben, ha a VID-jük megyegyezik. Különböző VID-ű hálózatok között a kommunikációt az erre kijelölt eszköz (pl. egy router, vagy switch…) végezheti el a 3. – hálózati - rétegben. Egy switch egy portja tartozhat egy vagy több VLAN-hoz. Amennyiben egyhez tartozik, lehetőség van rá, hogy a switch elrejtse a porton keresztül kapcsolódó eszköz (leginkább egy számítógép hálózati interface-e) elől, hogy ő valójában egy VLAN-ban van. Amennyiben egy porthoz több VLAN van megengedve, vagy egy VLAN, de nem cél az elrejtése, akkor a portra csatlakozó eszköznek ismernie kell, hogy ő melyik VLAN-ban van és ennek megfelelő VID-et kell a kiküldött csomagjai elé tennie illetve a kapott csomagok tag-jében találnia. Biztonsági szempontból ajánlatos lehet MAC címhez, vagy valamilyen authentikációhoz kötni a VLAN-t, ebben az esetben az adott számítógép csak a neki szánt VID-(ek)en tud kommunikálni. A VLAN témakör részletes mindenre kiterjedő ismertetésére kitérni nincs lehetőség, a forrásjegyzékben szereplő irodalmakból azonban jól megismerhető.

3.1 Linux alatt

VLAN kernel támogatás: A 802.1Q szabvány a kernel 2.4.21-es verziója óta a kernel része, 8021q a modul neve. A VLAN támogatáshoz a hálózati kártya driverének is támogatnia kell az esetlegesen nagyobb, mint 1500 bájt-os MTU-t. (Tapasztalataim alapján a szabvány Debian 2.6.8 kernel e1000 és e100 moduljai tökéletesen működnek. Azért nem a 2.4-es kernel széria lett a kiválasztott, mert ott a VLAN-ok fölötti bridge építése iptables tűzfalas szűréssel nem lehetséges. ld. később )

3.2 VLAN utility-k és használatuk

A VLAN hálózatok létrehozása a vconfig programmal lehetséges a következő szintaxis szerint: 

vconfig add interface_name VID

És ekkor létrejön az interface_name.VID interface, amely már a VID hálózatban képes kommunikálni.

Pl. az eth0 interface feletti 150-es VLAN létrehozása a következőféleképpen lehetséges: 

vconfig add eth0 150

Ekkor a következő interface jelenik meg: 

eth0.150 Link encap:Ethernet  HWaddr 00:02:A5:CE:61:CC
         inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
         inet6 addr: fe30::212:a3ff:fdce:61cd/64 Scope:LinkUP
         BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:406783997 errors:0 dropped:0 overruns:0 frame:0
         TX packets:444927484 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
         RX bytes:2283210879 (2.1 GiB)  TX bytes:2212731126 (2.0 GiB)

Egy ilyen virtuális eszköz eltávolítása a 

vconfig rem interface_name.VID

-rel lehetséges.

Esetünkben: 

vconfig rem eth0.150

Debian alatt lehetséges a /etc/network/interfaces fájl használata a VLAN-ok definiálására. A fenti példa így nézhetne ki: 

        iface eth0.150 inet static
              address 192.168.1.1
              netmask 255.255.255.0

vagy 

        iface vlan150 inet static
	      vlan-raw-device eth0
	      address 192.168.1.1
	      netmask 255.255.255.0

vagy 

        iface eth0.0150 inet static
	      address 192.168.1.1
              netmask 255.255.255.0

vagy 

        iface vlan0150 inet static
	      vlan-raw-device eth0
	      address 192.168.1.1
	      netmask 255.255.255.0

A négyféle módszer mind ugyanazt az eredményt éri el; ekvivalensek.

Az iptables működik - a szokásos szintaxissal - a virtuális interface-ekre.

3.3 Bridge VLAN fölött Debian Linuxon

Kernel támogatás bridge-hez: Patch-ként a 2.4-es szériához is elérhető, de a 2.6-os kernel széria része a bridge képesség, a bridge modul által. Nagy különbség a két változat között, hogy a 2.4-ben nincs lehetőség a bridge-elt forgalom tűzfalazására, ugyanis a bridge-ben nem kerül kibontásra a 4 bájttal megnövelt (beágyazott) csomag, így az iptables nem ismeri fel. A 2.6.1-től kezdve azonban van lehetőség tűzfalazásra.

A /proc/sys/net/bridge/-ben levő kapcsolók állításával:

  • bridge-nf-call-arptables - pass (1) or don't pass (0) bridged ARP traffic to arptables' FORWARD chain.
  • bridge-nf-call-iptables - pass (1) or don't pass (0) bridged IPv4 traffic to iptables' chains.
  • bridge-nf-call-ip6tables - pass (1) or don't pass (0) bridged IPv6 traffic to ip6tables' chains.
  • bridge-nf-filter-vlan-tagged - pass (1) or don't pass (0) bridged vlan-tagged ARP/IP traffic to arptables/iptables

3.4 Bridge-ek létrehozása

Linuxon a brctl programmal lehet létrehozni bridge-eket az interface-ek között. 

brctl addbr brX

-el létre lehet hozni bridge-eket. Ezekhez ifconfiggal akár IP-cím és routing tábla is

létrehozható. 

brctl addif brX device

utasítással pedig interface-ket adhatunk a bridge-hez.

brctl paraméterezhetősége: 

addbr		<bridge>			add bridge
delbr		<bridge>			delete bridge
addif		<bridge> <device>		add interface to bridge
delif		 <bridge> <device>		delete interface from bridge
setageing	<bridge> <time>		        set ageing time
setbridgeprio	<bridge> <prio>		        set bridge priority
setfd		<bridge> <time>		        set bridge forward delay
sethello	<bridge> <time>		        set hello time
setmaxage	<bridge> <time>		        set max message age
setpathcost	<bridge> <port> <cost>	        set path cost
setportprio	<bridge> <port> <prio>	        set port priority
show						show a list of bridges
showmacs	<bridge>			show a list of mac addrs
showstp	<bridge>			        show bridge stp info
stp		<bridge> <state>		turn stp on/off

Debian alatt lehetséges a /etc/network/interfaces fájl használata a bridge-ek definiálására. 

auto br0
iface br0 inet static
      address 192.168.0.1
      netmask 255.255.255.0
      gateway 192.168.0.1
	bridge_ports eth0 eth1
      bridge_stp on

Amennyiben VLAN interface-k fölött szeretnénk bridge-et létrehozni, egyszerűen a következő szintaxis használható: 

auto br0
iface br0 inet static
      address 192.168.1.1
      netmask 255.255.255.0
      gateway 192.168.1.1
	bridge_ports eth0.150 eth1.150
      bridge_stp on

Nincs szükség külön VLAN interface definiálásra; elvégzi automatikusan a rendszer.

A létrehozott bridge-ek állapotának lekérdezése: 

brctl show

bridge name     bridge id               STP enabled     interfaces
br0             8000.0002a5ce61cc       yes             eth0.150
                                                        eth1.150
br1             8000.0002a5ce61cc       yes             eth0.154
                                                        eth1.154

A számítógép elérhető marad távolról, ugyanis a bridge örökli az egyik interface MAC address-ét és ehhez mint felül látszik IP cím is rendelhető.

Így Linuxszal létrehozhatunk switch-eket, routereket, átlátszó tűzfalakat VLAN, ill. nem VLAN fölött.

3.5 Felhasznált irodalom

4 Potenciális zh-kérdések

  • Hogyan működik a statikus routing? Rajzoljon folyamatábrát arra az esetre, ha adott a következő routing-tábla: [...] és az 1.2.3.4-es géppel szeretnénk kommunikálni!
  • Mire való a PMTU discovery és hogyan működik?
  • Hogyan működik a SYN támadás?
  • Hogyan működik a syncookie mechanizmus?
  • Hogyan működik a smurf támadás, és hogy lehet megakadályozni? (A tűzfalas órán mondtam el.)
  • Soroljon fel legalább négy mezőt az IP-fejlécből (ami nem azonos a TCP-fejléccel)!
  • Soroljon fel legalább öt ICMP-üzenettípust! Mikor keletkeznek ilyen üzenetek?
  • Mire való az ARP? Milyen üzenetei vannak? Milyen visszaélésekre ad lehetőséget? Ezek hogyan működnek, mi a hatásuk?
  • Hogyan működik az FTP-ben az aktív, és hogyan a passzív mód?
  • Hogyan működik a „blind TCP connection spoofing” támadás, és hogyan lehet ellene védekezni?
A lap eredeti címe: „http://unixlinux.tmit.bme.hu/index.php?title=IP-alapok&oldid=4960”
Személyes eszközök