Linux - síťování

Primární zdroj: http://www.spsselib.hiedu.cz/~kerslage/manuals/linux/network/
Autor: Milan Keršláger
Aktualizace:

Síťové rozhraní

Základem zprovoznění sítě je mít k dispozici síťové rozhraní. V Linuxu to znamená, že podpora pro příslušnou síťovou kartu musí být zakompilována přímo do jádra nebo musí být zaveden příslušný modul. Pokud používáme jádro, které bylo přiloženo k naší distribuci, stačí vědět, který modul je potřeba zavést. Nejjednodušší formou nápovědy v tomto kroku je podívat se na výpis adresáře, který moduly obsahuje, protože většina z nich má jména přiléhavá k patřičné síťové kartě nebo čipu, který je na ní použit. Pokud neuspějeme ani zde, lze použít autodetekci, která je obvykle obsažena na instalační disketě (CD-ROM) samotné distribuce (u Red Hatu se stačí po úspěšné iautomatické detekci podívat na 3. textovou konzoli - {CTRL}+ALT+F3).

Následuje výpis adresáře s moduly, na prvním řádku nejprve zjistíme verzi jádra, kterou používáme, abychom věděli, který adresář je ten "pravý".

pluto:~$ uname -r
2.2.13-0.4smp
pluto:~$ ls /lib/modules/2.2.13-0.4smp/net/
3c501.o       cs89x0.o    ewrk3.o         ni5010.o       sktr.o
3c503.o       de4x5.o     fmv18x.o        ni52.o         slhc.o
3c505.o       de600.o     hostess_sv11.o  ni65.o         slip.o
3c507.o       de620.o     hp-plus.o       old_tulip.o    smc-ultra.o
3c509.o       depca.o     hp.o            olympic.o      smc-ultra32.o
3c515.o       dgrs.o      hp100.o         pcnet32.o      smc9194.o
3c59x.o       dlci.o      ibmtr.o         plip.o         strip.o
3c90x.o       dmfe.o      ipddp.o         ppp.o          syncppp.o
82596.o       dummy.o     ircomm.o        ppp_deflate.o  tlan.o
8390.o        e2100.o     irda.o          rcpci.o        tulip.o
ac3200.o      eepro.o     irda_deflate.o  rtl8139.o      via-rhine.o
acenic.o      eepro100.o  irlan.o         sb1000.o       wanpipe.o
arlan-proc.o  eexpress.o  lance.o         sbni.o         wavelan.o
arlan.o       epic100.o   lne390.o        sdla.o         wd.o
at1700.o      eql.o       ltpc.o          sdladrv.o      yellowfin.o
bsd_comp.o    es3210.o    ne.o            sealevel.o     z85230.o
cops.o        eth16i.o    ne2k-pci.o      shaper.o
cosa.o        ethertap.o  ne3210.o        sis900.o

Modul můžeme zavádět ručně (modprobe jmeno_modulu) nebo zajistíme jeho automatické zavedení tak, že jméno modulu asociujeme s příslušným zařízením. Jádro pak při pokusu o konfiguraci tohoto zařízení zařídí jeho automatické zavedení. Potřebuje-li modul nějaké parametry (I/O, IRQ apod.), je potřeba je také specifikovat. Následující příklad asociuje tři zařízení (eth0, eth1 a eth2) s příslušnými moduly (ne2k-pci pro PCI kartu NE2000 kompatibilní, modul 3c59x pro rodinu karet 3C90x a modul ne pro ISA NE2000 kartu).

alias eth0 ne2k-pci
alias eth1 3c59x
alias eth2 ne
options ne irq=5
Pokud je ovladač zakompilován do jádra a potřebuje ke správné detekci síťové karty (typicky karty ISA NE2000), je potřeba zadat parametry na příkazové řádce jádra (na výzvu LILO: odpovíme např. linux ether=9,0x300,0xd0000,0xd4000,eth0). Parametry jsou uváděny v tomto pořadí: irq,iobase[,param_1[,param_2,...param_8]]],name, kde name je jméno zařízení. Pro další informace je vodítkem BootPrompt-HOWTO, NET3-4-HOWTO a další.

Dokumentaci k parametrům a jmény podporovaných síťových karet najdete v dokumentaci k jádru linuxu i (Documentation/networking) nebo přímo ve zdrojových kódech jádra (drivers/net).

Samotnou konfiguraci síťových rozhraní osvětluje následující příklad (více viz. NET3-4-HOWTO):

# nejprve loopback device
ifconfig lo 127.0.0.1 netmask 255.0.0.0
ifconfig eth0 10.0.0.1 netmask 255.255.255.0 broadcast 10.0.0.255
ifconfig eth1 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255

route add -net 10.0.3.0 netmask 255.255.255.0 gw 10.0.0.111
route add default gw 10.0.0.254
Konfiguraci záznamů pro sítě za příslušnými rozhraními dělá jádro samo. V distribuci Red Hat s výhodou použijeme konfigurační utilitu linuxconf nebo netconf.

Pro nová jádra jsou k dispozici nové utility ip, tc a další. Všechny jsou určeny k tomu, aby šlo využít nových vlastností jádra Linuxu (QoS, Traffic shaping). Stále je však udržována kompatibilita se starými utilitami, jak bylo uvedeno výše (ifconfig, route). Příklad konfigurace síťového rozhraní novými nástroji by mohl vypadat např. takto:

ip route flush scope link
ip addr flush label lo\*
ip addr flush label eth\*

ip addr add 127.0.0.1/8 dev lo brd + scope host
ip link set up dev lo
ip route add 127.0.0.0/8 dev lo

ip addr add 10.0.0.0/24 dev eth0 brd +
ip link set up dev eth0

ip route add default via 10.0.0.254

DHCP

Pokud máme síť několika počítačů, není výhodné všechny obcházet a nastavovat u každé konfiguraci TCP/IP samostatně. Jednodušší je nastavit konfiguraci na jednom místě (server), odkud si ji budou jednotlivé stanice automaticky vyzvedávat. Vhodnými protokoly jsou BOOTP (starší varianta) a DHCP (novější způsob). Obě možnosti lze zajistit jednoduše pomocí jediného démona, který odpovídá na oba typy dotazů podle jedné databáze. IP adresy jsu stanicím přidělovány na základě MAC adresy jejich síťové karty. Tuto adresu zjistíme ve Windows'9x jednoduše pomocí utility winipcfg, pokud to není možné, můžeme ji vyčíst i z logu (/var/log/messages). Následující příklad uvádí příklad konfiguračního souboru, který řeší případ dvou segmentů sítě. Více informací získáte v dokumentaci démona nebo i s příklady v man dhcpd.conf.
subnet 10.0.0.0 netmask 255.255.0.0 {
  option domain-name "domena.cz";
  option domain-name-servers 10.0.0.1;
  option subnet-mask 255.255.255.0;
  option netbios-name-servers 172.16.0.1;
  option netbios-dd-server 172.16.0.1;
  option netbios-node-type 8;

  group {
    option routers 10.0.0.1;
    host stan1 {
      hardware ethernet 00:00:0C:76:46:D1;
      fixed-address 10.0.0.11;
    }
    host server {
      hardware ethernet 00:A0:24:23:9C:C9;
      fixed-address 194.108.45.3;
    }
  }

  group {
    option routers 10.0.1.1;
    host sekretarka {
      hardware ethernet 08:00:00:20:12:59;
      fixed-address 10.0.1.11;
    }
    host reditel {
      hardware ethernet 00:C0:6C:66:08:25;
      fixed-address 10.0.1.12;
    }
  }
  group {
    option routers 10.0.3.1;
    range 10.0.3.11 10.0.3.254;
}
Údaje jsou seskupeny v logických skupinách, přičemž nadřízené skupiny definují položky pro všechny podřízené skupiny. Poslední skupina umožňuje přidělit první volnou (ještě nepřidělenou) adresu stanicím v pořadí, jak o to požádají. IP adresy jsou pronajímány na určitou dobu, takže démon snadno pozná, kdy může již volnou adresu (stanice je vypnuta) přidělit jiné stanici. Pro podrobnější informace o si přečtete dokumentaci k démonu dhcp. Položky okolo Netbiosu definují WINS server. Pro podrobnější informace o WINS serveru si přečtete dokumentaci k Windows nebo programu Samba.

DNS

DNS (Domain Name Service) je služba, která umožňuje lidem používat místo IP adres jména. Jména se lépe pamatují, ovšem nelze je přímo použít pro rozlišení počítačů. Proto existuje od roku 1984 tato velmi užitečná služba.

DNS má hiearchickou strukturu. Jména se skládají z částí, které jsou odděleny tečkami a při zápisu se postupuje od konkrétních údajů (jméno počítače) k obecnějším (organizace, stát). Počet složek není omezen a každá úroveň udržuje informace jen o podřízených úrovních (decentralizace). První úroveň (poslední část jména) se nazývá "top level doména" nebo "doména první úrovně". Druhé úrovni se říká "sekundární doména" nebo "doména druhé úrovně", dále "doména třetí úrovně" atd. až ke konkrétnímu jménu počítače. Takto můžeme určit jednotlivé složky např. u jmen: www.whitehouse.gov, www.seznam.cz a www.spsselib.hiedu.cz.

O každou úroveň (doménu) se starají DNS servery, které dělíme na primární a sekundární (záložní). Veškeré informace o doméně se definují v konfiguračním souboru primárního DNS serveru. Sekundární si informace samy kopírují (orientují se podle sériového čísla). Top level domény jsou definovány na tzv. "kořenových serverech". Těch je zhruba 10 a jsou základem pro celý svět. To level domény (také tz. národní domény) jsou definovány podle normy ISO 3166 (viz. ftp://ftp.ripe.net/iso3166-countrycodes). Každá země má přidělenu dvoupísmennou zkratku, vyjímku tvoří USA, které mají z historických důvodů několik třípísmenných top level domén (com, edu, mil, gov, ...). Národní domény dále provádějí registraci podřízených domén samy (u nás viz: http://www.nic.cz/).

DNS kromě převodu jmen na IP adresy zajišťuje i zpětný převod (reverzní záznamy), který zajišťuje převod IP adresy na jméno a měl by být konzistentní s převodem jméno - IP adresa. Pokud chceme vstoupit na pole Internetu, zajistíme si nejprve svoji IP adresu a posléze si zaregistrujeme (u nadřízené domény) svoji doménu. K tomu musíme mít funkční jeden primární a alespoň jeden sekundární DNS server. K tomu bychom měli zajistit i správné reverzní mapování.

Konfigurace DNS serveru se skládá z několika souborů. Základním je soubor /etc/named.conf, ve kterém definujeme další potřebné informace. Tento soubor bude mít tuto základní kostru:

options {
        directory "/var/named";
        # pro zlepšení využití cachování se zeptáme i tady
        forwarders {
                147.230.16.1;
                192.108.150.10;
        };
        statistics-interval 0;
};
# zakážeme extra logování
logging {
        category lame-servers { null; };
        category cname { null; };
};
zone "." {
        type hint;
        file "root.cache";
};
zone "0.0.127.in-addr.arpa"{
        type master;
        file "local";
};
Takto nakonfigurovaný server (nejpoužívanějším programem je tzv. BIND) bude provádět pro stanice v síti převod (resolving) jmen na IP adresy a obráceně. Zároveň budou získané informace uchovávány po určitou dobu v paměti (caching). Pokud by náš DNS server neměl přístup k Internetu (byl by např. zřízen jen pro účely Intranetu), lze ještě vynechat záznam o odkazech na kořenové servery (sekce s odkazem na soubor root.cache).

Pro potřeby naší domény nadefinujeme záznamy pro doménu huzva.cz a reverzní záznamy pro síť 10.0.0.0. Ve výše zmíněném souboru přibudou záznamy:

zone "huzva.cz"{
        type master;
        file "huzva.hosts";
};
zone "0.0.10.in-addr.arpa"{
        type master;
        file "huzva.rev";
};
Tyto soubory budou vypadat následovně (pozor na všechny tečky):
Soubor: huzva.hosts - převod jmen na IP adresy
==============================================
$TTL 86400
@ 3600          SOA     server.huzva.cz. hostmaster.huzva.cz. (
                        1999101901 ; Serial
                                   ; defaults from RFC-1537
                        28800      ; Refresh (8 hours)
                        7200       ; Retry   (2 hours)
                        604800     ; Expire  (7 days)
                        86400      ; Minimum TTL (1 day)
                )

                TXT     "Firma Huzva CZ"

                NS      server.huzva.cz.
                NS      ns2.li.cesnet.cz.

                MX      0       server.huzva.cz.
                MX      10      relay.li.cesnet.cz.
                MX      20      rs.cesnet.cz.

; povinna polozka
localhost       A       127.0.0.1

mail            CNAME   server.huzva.cz.
cache           CNAME   server.huzva.cz.
ftp             CNAME   server.huzva.cz.
www             CNAME   server.huzva.cz.

server          A       10.0.0.1
                HINFO   Celeron366i "Linux"
                MX      0       server.huzva.cz.
                MX      10      relay.li.cesnet.cz.
                MX      20      rs.cesnet.cz.

pc1             A       10.0.0.11
pc2             A       10.0.0.12


Soubor: huzva.rev - převod IP adres na jména (reverzní)
=======================================================
$TTL 86400
@ 3600  SOA     server.huzva.cz.        hostmaster.huzva.cz. (
                1999101901 ; Serial
                           ; defaults from RFC-1537
                28800      ; Refresh (8 hours)
                7200       ; Retry   (2 hours)
                604800     ; Expire  (7 days)
                86400      ; Minimum TTL (1 day)
        )

        NS      server.huzva.cz.
        NS      ns2.li.cesnet.cz.

1       PTR     server.huzva.cz.

11      PTR     pc1.huzva.cz.
12      PTR     pc2.huzva.cz.

Soubor: local
=======================================================
@       SOA     server.huzva.cz.        hostmaster.huzva.cz. (
                1        ; Serial
                         ; defaults from RFC-1537
                8H       ; Refresh (8 hours)
                2H       ; Retry   (2 hours)
                1W       ; Expire  (7 days)
                1D       ; Minimum TTL (1 day)
        )

        NS      server.huzva.cz.

1       PTR     localhost.

Soubor: root.cache - definice kořenových nameserverů
====================================================
; lze získat i příkazem: dig @rs.internic.net . ns

.       999999  IN      NS      B.ROOT-SERVERS.NET.
.       999999  IN      NS      C.ROOT-SERVERS.NET.
.       999999  IN      NS      D.ROOT-SERVERS.NET.
.       999999  IN      NS      E.ROOT-SERVERS.NET.
.       999999  IN      NS      I.ROOT-SERVERS.NET.
.       999999  IN      NS      F.ROOT-SERVERS.NET.
.       999999  IN      NS      G.ROOT-SERVERS.NET.
.       999999  IN      NS      A.ROOT-SERVERS.NET.
.       999999  IN      NS      H.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.     999999  IN      A       128.9.0.107
C.ROOT-SERVERS.NET.     999999  IN      A       192.33.4.12
D.ROOT-SERVERS.NET.     999999  IN      A       128.8.10.90
E.ROOT-SERVERS.NET.     999999  IN      A       192.203.230.10
I.ROOT-SERVERS.NET.     999999  IN      A       192.36.148.17
I.ROOT-SERVERS.NET.     999999  IN      A       64.36.148.17
F.ROOT-SERVERS.NET.     999999  IN      A       192.5.5.241
F.ROOT-SERVERS.NET.     999999  IN      A       39.13.229.241
G.ROOT-SERVERS.NET.     999999  IN      A       192.112.36.4
A.ROOT-SERVERS.NET.     999999  IN      A       198.41.0.4
A.ROOT-SERVERS.NET.     999999  IN      A       198.41.0.58
A.ROOT-SERVERS.NET.     999999  IN      A       194.41.0.4
A.ROOT-SERVERS.NET.     999999  IN      A       196.41.0.92
H.ROOT-SERVERS.NET.     999999  IN      A       128.63.2.53
Kontrolu správně nastaveného DNS můžeme provést způsobem inspirovaným níže uvedeným přikladem použití programu nslookup. Všiměte si zvláštního zápisu pro reverzní domény (in-addr.arpa).

Převod jména na IP adresu:

pluto:~> nslookup ftp.vslib.cz
Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

Non-authoritative answer:
Name:    obelix.vslib.cz
Address:  147.230.16.8
Aliases:  ftp.vslib.cz

pluto:~> nslookup 147.230.16.8
Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

Non-authoritative answer:
Name:    obelix.vslib.cz
Address:  147.230.16.8

Práce v interaktivním režimu:

pluto:~> nslookup

Default Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

> www.whitehouse.gov
Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

Name:    www.whitehouse.gov
Addresses:  198.137.240.91, 198.137.240.92

> 147.230.16.1
Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

Name:    bubo.vslib.cz
Address:  147.230.16.1

> type=SOA
> spsselib.hiedu.cz
Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

spsselib.hiedu.cz
        origin = neptun.spsselib.hiedu.cz
        mail addr = hostmaster.neptun.spsselib.hiedu.cz
        serial = 99010700
        refresh = 28800 (8H)
        retry   = 7200 (2H)
        expire  = 3600000 (5w6d16h)
        minimum ttl = 259200 (3D)
spsselib.hiedu.cz       nameserver = neptun.spsselib.hiedu.cz
spsselib.hiedu.cz       nameserver = bubo.vslib.cz
spsselib.hiedu.cz       nameserver = jonas.hiedu.cz
neptun.spsselib.hiedu.cz        internet address = 194.108.45.33
bubo.vslib.cz   internet address = 147.230.16.1
jonas.hiedu.cz  internet address = 194.108.211.66

> type=MX
> spsselib.hiedu.cz
Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

spsselib.hiedu.cz       preference = 100, mail exchanger = adis.cesnet.cz
spsselib.hiedu.cz       preference = 200, mail exchanger = vscht.vscht.cz
spsselib.hiedu.cz       preference = 0, mail exchanger = neptun.spsselib.hiedu.cz
spsselib.hiedu.cz       preference = 50, mail exchanger = bubo.vslib.cz
spsselib.hiedu.cz       nameserver = neptun.spsselib.hiedu.cz
spsselib.hiedu.cz       nameserver = bubo.vslib.cz
spsselib.hiedu.cz       nameserver = jonas.hiedu.cz
adis.cesnet.cz  internet address = 194.50.6.3
vscht.vscht.cz  internet address = 147.33.1.1
neptun.spsselib.hiedu.cz        internet address = 194.108.45.33
bubo.vslib.cz   internet address = 147.230.16.1
jonas.hiedu.cz  internet address = 194.108.211.66

> set q=any
> spsselib.hiedu.cz
Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

spsselib.hiedu.cz       nameserver = neptun.spsselib.hiedu.cz
spsselib.hiedu.cz       nameserver = bubo.vslib.cz
spsselib.hiedu.cz       nameserver = jonas.hiedu.cz
spsselib.hiedu.cz       text = "Secondary technical school in Liberec"
spsselib.hiedu.cz       preference = 100, mail exchanger = adis.cesnet.cz
spsselib.hiedu.cz       preference = 200, mail exchanger = vscht.vscht.cz
spsselib.hiedu.cz       preference = 0, mail exchanger = neptun.spsselib.hiedu.cz
spsselib.hiedu.cz
        origin = neptun.spsselib.hiedu.cz
        mail addr = hostmaster.neptun.spsselib.hiedu.cz
        serial = 99010700
        refresh = 28800 (8H)
        retry   = 7200 (2H)
        expire  = 3600000 (5w6d16h)
        minimum ttl = 259200 (3D)
spsselib.hiedu.cz       preference = 50, mail exchanger = bubo.vslib.cz
spsselib.hiedu.cz       nameserver = neptun.spsselib.hiedu.cz
spsselib.hiedu.cz       nameserver = bubo.vslib.cz
spsselib.hiedu.cz       nameserver = jonas.hiedu.cz
neptun.spsselib.hiedu.cz        internet address = 194.108.45.33
bubo.vslib.cz   internet address = 147.230.16.1
jonas.hiedu.cz  internet address = 194.108.211.66
adis.cesnet.cz  internet address = 194.50.6.3
vscht.vscht.cz  internet address = 147.33.1.1

> prum.spsselib.hiedu.cz
Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

prum.spsselib.hiedu.cz  CPU = PC 586    OS = NOVELL 4.11
prum.spsselib.hiedu.cz  preference = 100, mail exchanger = adis.cesnet.cz
prum.spsselib.hiedu.cz  preference = 200, mail exchanger = vscht.vscht.cz
prum.spsselib.hiedu.cz  preference = 0, mail exchanger = neptun.spsselib.hiedu.cz
prum.spsselib.hiedu.cz  preference = 50, mail exchanger = bubo.vslib.cz
prum.spsselib.hiedu.cz  internet address = 194.108.45.131
spsselib.hiedu.cz       nameserver = neptun.spsselib.hiedu.cz
spsselib.hiedu.cz       nameserver = bubo.vslib.cz
spsselib.hiedu.cz       nameserver = jonas.hiedu.cz
adis.cesnet.cz  internet address = 194.50.6.3
vscht.vscht.cz  internet address = 147.33.1.1
neptun.spsselib.hiedu.cz        internet address = 194.108.45.33
bubo.vslib.cz   internet address = 147.230.16.1
jonas.hiedu.cz  internet address = 194.108.211.66

Výpis domény:

pluto:~> nslookup
Default Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

> set q=any
> antik-fryc.cz
Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

antik-fryc.cz
        origin = book.antik-fryc.cz
        mail addr = Admin.antik-fryc.cz
        serial = 98110300
        refresh = 28800 (8H)
        retry   = 3600 (1H)
        expire  = 1209600 (2W)
        minimum ttl = 86400 (1D)
antik-fryc.cz   nameserver = book.antik-fryc.cz
antik-fryc.cz   nameserver = bubo.vslib.cz
antik-fryc.cz   text = "Knihkupectvi a antikvariat Jaroslav Fryc"
antik-fryc.cz   preference = 10, mail exchanger = bubo.vslib.cz
antik-fryc.cz   preference = 20, mail exchanger = adis.cesnet.cz
antik-fryc.cz   preference = 0, mail exchanger = book.antik-fryc.cz
antik-fryc.cz   nameserver = book.antik-fryc.cz
antik-fryc.cz   nameserver = bubo.vslib.cz
book.antik-fryc.cz      internet address = 194.212.169.130
bubo.vslib.cz   internet address = 147.230.16.1
adis.cesnet.cz  internet address = 194.50.6.3

> server book.antik-fryc.cz
Default Server:  book.antik-fryc.cz
Address:  194.212.169.130

> ls antik-fryc.cz
[book.antik-fryc.cz]
$ORIGIN antik-fryc.cz.
pc3                     1D IN A         194.212.169.133
bara                    1D IN A         194.212.169.140
pc4                     1D IN A         194.212.169.134
pc5                     1D IN A         194.212.169.135
gw                      1D IN A         194.212.169.129
alena                   1D IN A         194.212.169.136
pc6                     1D IN A         194.212.169.137
book                    1D IN A         194.212.169.130
localhost               1D IN A         127.0.0.1
pc1                     1D IN A         194.212.169.131
pc2                     1D IN A         194.212.169.132

Komu patří IP bez reverzního záznamu?

pluto:~> nslookup
Default Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

> 62.168.7.194
Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

*** neptun.spsselib.hiedu.cz can't find 62.168.7.194: Non-existent host/domain
> set q=any
> 7.168.62.in-addr.arpa
Server:  neptun.spsselib.hiedu.cz
Address:  194.108.45.33

Non-authoritative answer:
7.168.62.in-addr.arpa
        origin = ns.ebanka.cz
        mail addr = dpikalek.expandia.com
        serial = 1998103003
        refresh = 10800 (3H)
        retry   = 1800 (30M)
        expire  = 604800 (1W)
        minimum ttl = 86400 (1D)

Authoritative answers can be found from:
62.in-addr.arpa nameserver = NS.RIPE.NET
62.in-addr.arpa nameserver = NS.EU.NET
62.in-addr.arpa nameserver = AUTH03.NS.UU.NET
NS.RIPE.NET     internet address = 193.0.0.193
NS.EU.NET       internet address = 192.16.202.11
AUTH03.NS.UU.NET        internet address = 198.6.1.83

Sendmail

Sendmail je velmi známý přepravní poštovní agent (MTA). Přepravuje poštovní zprávy mezi jednotlivými poštovními uzly v Internetu. Dodává se se standardním konfiguračním souborem, který umožňuje příjem a odesílání pošty pro náš počítač. Pokud potřebujeme zajistit příjem pošty pro zvláštní konfiguraci (např. pro celou doménu), je potřeba jeho konfiguraci upravit. K tomu potřebujeme balíček sendmail-cf, případně i balíček sendmail-doc, který obsahuje dokumentaci.

Následující ukázka je stadardní soubor, ze kterého se makrojazykem M4 generuje vlastní konfigurační soubor sendmailu. Tento soubor slouží k již zmíněné defaultní konfiguraci a najdeme jej zde: /usr/lib/sendmail-cf/cf/redhat.mc.

divert(-1)
dnl This is the macro config file used to generate the /etc/sendmail.cf
dnl file. If you modify thei file you will have to regenerate the
dnl /etc/sendmail.cf by running this macro config through the m4
dnl preprocessor:
dnl
dnl        m4 /etc/sendmail.mc > /etc/sendmail.cf
dnl
dnl You will need to have the sendmail-cf package installed for this to
dnl work.
include(`/usr/lib/sendmail-cf/m4/cf.m4')
define(`confDEF_USER_ID',``8:12'')
OSTYPE(`linux')
undefine(`UUCP_RELAY')
undefine(`BITNET_RELAY')
define(`confAUTO_REBUILD')
define(`confTO_CONNECT', `1m')
define(`confTRY_NULL_MX_LIST',true)
define(`confDONT_PROBE_INTERFACES',true)
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')
FEATURE(`smrsh',`/usr/sbin/smrsh')
FEATURE(mailertable)
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable')
FEATURE(redirect)
FEATURE(always_add_domain)
FEATURE(use_cw_file)
FEATURE(local_procmail)
MAILER(procmail)
MAILER(smtp)
FEATURE(`access_db')
FEATURE(`blacklist_recipients')
dnl We strongly recommend to comment this one out if you want to protect
dnl yourself from spam. However, the laptop and users on computers that do
dnl not hav 24x7 DNS do need this.
FEATURE(`accept_unresolvable_domains')
dnl FEATURE(`relay_based_on_MX')
Značky dnl značí komentáře a do výsledného souboru se obsah, který je od těchto značek vpravo, nepromítne. Jsou využívána dvě rozšíření Sendmailu o externí databáze: access a virtusertable. Databáze access slouží ke konfiguraci přístupu k sendmailu a zamezení přístupu neoprávněných klientů, resp. spammerů (kteří jsou mimo naší síť - naše síť je v tomto případě 194.108.45.0 s maskou 255.255.255.0). Její možnosti jsou využity i jako možnost odmítnutí pošty přicházející z domény holecek.cz a z konkrétní poštovní adresy velky@spammer.com a propusteny@firma.cz (díky volbě FEATURE(`blacklist_recipients')).
# file /etc/mail/access

holecek.cz          550 You are a known spammer
velky@spammer.com   550 We dislike your mails
propusteny@firma.cz 550 User has been deleted

194.108.45      RELAY
Soubor virtusertable slouží k přesměrovávání pošty. V následujícím případě směrujeme veškerou poštu přicházející do naší domény firma.cz na stroj mailbox.firma.cz (který obsahuje poštovní schránky uživatelů a je okolnímu světu skryt ve vnitřní síti naší firmy). V předávaných dopisech je jedna vyjímka, která je směrována jinak. Dále veškerá pošta pro doménu jinafirma.cz je směrována do jediné poštovní schránky (host@firma.cz).
ja@firma.cz      on@firma.cz
@firma.cz        %1@mailbox.firma.cz      
@jinafirma.cz    host@firma.cz  
V těchto případech je uzlem přijímána pošta pro domény firma.cz a jinafirma.cz. Protože Sendmail bude standardně přijímat poštu jen pro náš konkrétní stroj, musíme ostatní domény doplnit do souboru /etc/sendmail.cw (jedna doména na každý řádek). Výše zmíněné soubory access a virtusertable musí být zpracovány do DB formátu, k čemuž nejlépe poslouží následující soubor Makefile (odsazení musí být provedeno tabelátorem):
WHAT = access.db virtusertable.db sendmail.cf

all: $(WHAT)

access.db: access
	makemap hash access < access

mailertable.db: mailertable
	makemap hash virtusertable.db < virtusertable

sendmail.cf: neptun.m4
	m4 neptun.m4 > sendmail.cf
	cp -i sendmail.cf /etc
	/etc/rc.d/init.d/sendmail restart
Další podrobnosti o konfiguraci Sendmailu pomocí M4 makrojazyka se nacházejí v souboru /usr/lib/sendmail-cf/README z balíčku sendmail-doc.

IPX v Linuxu

Úvod do IPX/SPX

S protokolem IPX/SPX se setkáváme denně, zejména v prostředí Novell NetWare, kde je klíčovým protokolem. Protokol IPX/SPX počítá s vysokou rychlostí a nízkou chybovostí lokálních sítí a je jednodušší než protokol TCP/IP který je používán v rozlehlém světě Interentu. To je hlavní důvod, proč je v lokálních sítích tolik používán. Jeho konfigurace i implementace je jednoduchá a neskrývá mnoho úskalí. Protokol IPX (Internetwork Packet eXchange) pracuje jako datagramová služba a je tak obdobou protokolu IP. Naproti tomu SPX (Sequenced Packet eXchange) je navazováním spojení velice blízké protokolu TCP.

K čemu to bude dobré

Všechny počítače v síti jsou si při vzájemné komunikaci rovny. Přes to mají některé významější postavení, než ostatní. Jsou to většinou specializované stanice, které nabízejí své služby ostatním stanicím. Takovým počítačům říkáme servery, stanicím pak klienti a říkáme, že používáme architekturu klient-server. Určitě je velmi výhodné umět i z Linuxu využívat všech služeb, které nabízejí servery Novell Netware. Abychom mohli s těmito servery komunikovat, musíme umět nakonfigurovat svůj Linux tak, aby jim rozuměl. V dalších odstavcích budu přepokládat, že máme k dispozici síť typu Ethernet (např. tenký koaxiál nebo kroucenou dvoulinku) a podíváme se blíže, jak to všechno zařídit. Začneme od začátku, tedy od toho, jak komunikace na Ethernetových sítích vlastně funguje.

Nejprve se pokusím objasnit význam pojmů datagram, paket a rámec. Datagram je celistvá informace, kterou přenášíme mezi počítači. Datagram může být při přepravě dělen na více částí a takovýmto samostatným částem říkáme pakety. Aby mohl být paket přepravován po síti typu Ethernet, je ho potřeba doplnit o další nezbytné informace nutné pro jeho přepravu po síťovém médiu a takovémuto rozšířeném paketu říkáme rámec.

Ethernetové rámce

Základem přepravy dat na sítích typu Ethernet jsou takzvané rámce, které přepravují obecně jakákoliv data mezi jednotlivými počítači. Každý rámec představuje balík dat, který je možno vyslat v rámci jednoho segmentu k jinému počítači. Skládá se z hlavičky, těla (obsahuje přenášená data, tedy paket vyšší vrstvy - například IP nebo IPX) a traileru (zakončení rámce s kontrolním součtem). V hlavičce najdeme identifikaci rámce, typ přenášených dat a hardwarovou adresu odesílatele a příjemce (označovaná také jako fyzická MAC adresa). Podle této adresy síťové rozhraní dokáže samo rozeznat rámce, které jsou mu určeny a nemusí tak rušit počítač zbytečnými přerušeními. MAC adresa je pevně dána výrobcem síťové karty a většinou ji není možné měnit. Teoreticky by se na světě neměly vyskytovat dvě Ethernetové karty se stejnou MAC adresou, ale může se to stát, i když výbor IEEE (Institute of Electrical and Electronics Engineers) přiděluje každému výrobci blok adres. Pokud na takové karty narazíte, je to nepříjemné a máte z pekla štěstí :-).

Rámec je závislý na použitém přepravním médiu. Když datagram opouští Ethernet a je dále přepravován například po sériové lince, jsou zachována pouze data z těla rámce a ta pak putují dále obalena jiným přepravním protokolem.

Abychom neměli pocit, že je všechno jednoduché, existuje více norem, které předepisují, jak má hlavička rámce v sítích typu Ethernet vypadat (viz následující tabulka). Síťová karta musí umět správně dekódovat přijatý rámec, jinak ho může považovat za chybný. Proto je vhodné používat na segmentu pokud možno jen jeden rámec a nepřivádět jak síťovou kartu tak administrátora do schizofrenického stavu. Otázkou pak ovšem zůstává, který rámec je ten pravý.

Název rámceCharakteristika
Ethernet 802.2 dnešní standard firmy Novell, umí přepravovat pouze IPX/SPX
Ethernet 802.3 původní standard firmy Novell, umí přepravovat pouze IPX/SPX
Ethernet II umí přepravovat IPX/SPX i TCP/IP, nejrozšířenější, nejjednodušší
Ethernet SNAP umí přepravovat IPX/SPX i TCP/IP
Ethernetové rámce

Pokud chcete používat ve své síti protokol TCP/IP, nevyhnete se použití jednoho z posledních dvou rámců. Nejvýhodnějším je určitě Ethernet II, protože je nejjednodušší ze všech a hlavně je univerzální (lze v něm přepravovat kromě IPX/SPX a TCP/IP spoustu dalších protokolů).

Někdy není možné na jednom segmentu vystačit jen s jedním rámcem, protože například některé BootROMky nebo stanice se staršími ovladači rámec Ethernet II neumí. Ovšem určitě platí, že v jednoduchosti je síla. Proto raději důkladně zvažte, co všechno Vám na segmentu bude běhat. Neexistuje žádný důvod, proč by neměl být rámec Ethernet II používán.

Osobně používám na segmentech jen jeden rámec (Ethernet II) a ostatní přidávám jen v případě nezbytné nutnosti. Windows'95 není vhodné nechávat u protokolu IPX/SPX používat autodetekci rámců, protože to může občas vést k nepochopitelným výpadkům, zvláště ve větších sítích.

Dělení na více sítí

Protože rámce neobsahují možnost, jak je jednoduše směrovat mezi více segmenty (ani to není jejich úkol), je směrování zajištěno protokolem vyšší vrstvy, v našem případě tedy protokolem IPX. Adresa se v IPX datagramu skládá z čísla sítě a čísla uzlu, které kopíruje uz výše zmíněnou MAC adresu síťové karty. Každý segment musí mít jiné číslo sítě a pokud provozujeme na jednom segmentu více rámců, pak i každý rámec musí mít různá čísla sítí. Všechna síťová rozhraní na jednom segmentu se stejným rámcem používají stejná čísla sítí. Ty určuje administrátor při instalaci serverů a pokud dojde ke konfliktu, v horším případě to vyřadí z provozu celý segment. Stanice si obvykle zjistí číslo sítě ze serveru sama, bez nutnosti přesné konfigurace.

Vnitřní sítě

Vnitřní sítě (tzv. internal network) slouží pro snadné směrování datagramů ze stanic na místo, které Vám poskytuje nějakou službu. Vnitřní číslo sítě proto potřebuje jen server, stanice bez něj bude pracovat a vlastně ho ani na nic nepotřebuje. Vnitřní číslo sítě definuje jakousi virtuální síť uvnitř serveru, na které sice není určen žádný rámec, ale přes to musí být její číslo jedinečné a nesmí se tedy shodovat s jiným číslem sítě v naší lokální síti.

Spolupráce Linuxu s NetWare servery

Servery Novell NetWare nejčastěji komunikují se stanicemi pomocí protokolu IPX, ten je ovšem pouze přepravním protokolem. Dnes můžeme jako přepravní protokol využít také TCP/IP a překročit tak mnohem větší vzdálenosti než s protokolem IPX, ovšem konfigurace síťových rozhraní u stanic je pak výrazně složitější. Navíc je podpora TCP/IP pro NetWare na straně Linuxu zatím v plenkách. Proto se dále budeme zabývat pouze první a zřejmě také nejrozšířenější variantou.

Protokoly v prostředí NetWare

Aby si stanice se servery při vzájemném rozhovoru rozuměly, přepravovaná data měla logiku a strukturu, potřebujeme další protokoly, které budou v IPX přepravovány. Nejvýznamějším takovým protokolem je NCP (NetWare Core Protocol), který umožňuje klientům přístup k síťovým diskům, tiskárnám a dalším sdíleným zařízením. Pomocí tohoto protokolu se uživatelé také k serverům NetWare přihlašují. Dalším protokolem, se kterým se setkáme je SAP (Service Advertisement Protocol). Tímto protokolem jednotlivé servery ohlašují a nabízejí své služby v síti pomocí broadcastů. Posledním zajímavým protokolem je RIP (Routing Information Protocol), pomocí kterého si mezi sebou IPX směrovače (routery) vyměňují informace o známých sítích. Ty se pak odrazí ve směrovacích tabulkách a tím je umožněno, aby směrovače mohly předávat datagramy i do jiných sítí, než ve které pracuje stanice. Přes router může být zajištěn i překlad rámce, ale pokud se tak děje na jednom segmentu, povede to k duplikaci provozu. To je další důvod, proč je vhodnější používat na všech stanicích v síti pouze jeden jediný rámec.

Konfigurace IPX v Linuxu

Pokud má Linux vystupovat jako obyčejná stanice, která rozumí protokolu IPX, bude vystupovat jako klient a bude využívat zdroje a služby (např. sdílení disků a tisk na síťových tiskárnách), které mu budou pomocí sítě poskytovány servery.

Při konfiguraci musíme začít od základu a tím je protokol IPX. Podpora protokolu IPX musí být povolena při kompilaci jádra Linuxu (CONFIG_IPX). Pokud používáme standardní distribuční jádro, bude modul s největší pravděpodobností již připraven. Pak je potřeba správně nakonfigurovat síťové rozhraní, k čemuž potřebujeme několik utilit, které najdeme v balíku ncpfs. V tomto balíku se nachází většina utilit, které pro práci s IPX budeme v Linuxu potřebovat. Uživatelům distribuce RedHat 6.1 stačí nainstalovat balík ncpfs-2.2.0.16.a-1.i386.rpm nebo podobný, IPX je v jádrech k dispozici jako modul.

Síťové rozhraní můžeme nechat nakonfigurovat automaticky, pokud je na síti už IPX používáno. Automatickou konfiguraci obstarává jádro odposlechem provozu na síti. Pokud na síti není žádný IPX provoz, musíme rozhraní nakonfigurovat ručně. Pro běžný provoz automatickou konfiguraci nedoporučuji, protože Windows'95 vysílají do sítě chybné pakety a to pak může vést k nesprávnému rozpoznání čísla sítě a používaných typů rámců, proto je vhodná spíše jen pro první kroky. Pro manuální konfiguraci potřebujete znát číslo sítě pro každý používaný rámec. Pokud ho nevíte, informujte se u svého administrátora.

Automatická konfigurace:

    modprobe ipx
    ipx_configure --auto_interface=on --auto_primary=on
    cat /proc/net/ipx_*
Automatickou konfiguraci je vhodné zkontrolovat podle výpisu souboru /proc/net/ipx_interface, který obsahuje seznam všech registrovaných IPX rozhraní včetně typů rámců a čísel sítí. Automatické nakonfigurování rozhraní může chvíli trvat (cca 10-30 vteřin).

K ruční konfiguraci IPX rozhraní slouží utilita ipx_interface Právě jedno rozhraní by mělo být přepínačem -p označeno jako primární. Takové rozhraní je považováno za implicitní a je použito, když v programu při otevírání soketu neuvedeme číslo sítě. Tvar použití příkazu vypadá takto:

    ipx_interface činnost [-p] rozhraní typ_rámce číslo_sítě

Činnost Popis
add přidává IPX rozhraní, vždy je nutné uvést název rozhraní a typ rámce. Pokud není uvedeno číslo sítě, je zjištěno odposlechem.
del ruší na uvedeném rozhraní uvedený rámec
delall ruší všechna rozhraní
check zobrazí konfiguraci příslušného rozhraní

Typ rámce může být 802.2 pro rámec Ethernet 802.2, 802.3 pro rámec Ethernet 802.3, EtherII pro rámec Ethernet II a Snap pro rámec Ethernet SNAP.

Příklad ruční konfigurace rozhraní pro rozhraní eth0, rámec Ethernet II, číslo sítě 12 (primární interface) a rámec 802.3, číslo sítě 13:

    modprobe ipx
    ipx_interface add -p eth0 etherii 12
    ipx_interface add    eth0 802.3   13

Po těchto krocích si můžeme ověřit konfiguraci například takto:

    monkey:~# cat /proc/net/ipx_interface
    Network    Node_Address   Primary  Device     Frame_Type
    00000012   00A024D6F9F9   Yes      eth0       EtherII
    00000013   00A024D6F9F9   No       eth0       802.3

    monkey:~# cat /proc/net/ipx_route
    Network    Router_Net   Router_Node
    00003333   00000012     0020AFF67402
    00001111   00000013     0020AFF67402
    00000013   Directly     Connected
    00000012   Directly     Connected

    monkey:~# ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 00:A0:24:D6:F9:F9
              inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
              IPX/Ethernet II addr:00000012:00A024D6F9F9
              IPX/Ethernet 802.3 addr:00000013:00A024D6F9F9
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:587 errors:0 dropped:0 overruns:0
              TX packets:141 errors:0 dropped:0 overruns:0
              Interrupt:10 Base address:0x6100

Správnou funkci síťového rozhraní můžeme ověřit například výpisem dostupných NetWare serverů pomocí příkazu slist:

    monkey:~> slist
    Known NetWare File Servers     Network   Node Address
    -----------------------------------------------------
    PRUM                           0003333   000000000001
    PAT                            0001111   000000000001

Pokud bychom chtěli nakonfigurovaná rozhraní z nějakého důvodu zrušit, mohli bychom postupovat například takto (na Vašem systému nemusí být nutně použity všechny uvedené příkazy):

    ipx_configure --auto_interface=off --auto_primary=off
    ipx_interface delall
    rmmod ipx

Linux jako IPX směrovač

Pokud si to budeme přát, Linux může fungovat jako směrovač IPX protokolu mezi různými sítěmi (oddělí provoz z předává datagramy z jedné sítě do druhé, pokud je to potřeba). Směrování je prováděno na úrovni jádra operačního systému podle údajů ve směrovací tabulce IPX (vypsat si ji můžeme už zmíněným příkazem cat /proc/net/ipx_route. Tuto činnost Linux vykonává podobně jako NW server a stejně jako on musí ohlašovat ostatním směrovačům a stanicím, jaké jsou dostupné sítě a zárověn musí sám dle hlášení ostatních směrovačů automaticky upravovat své směrovací tabulky pro IPX protokol. O tuto činnost se stará zvláštní program.

Tento zvláštní program bývá označován jako démon a stačí ho vlastně jen spustit. O vše ostatní se postará sám, pokud před tím správně nakonfigurujeme všechna síťová rozhraní, což už ale perfektně umíme. Zajímavé je, že pokud budeme používat program Mars, o kterém ještě bude řeč, nebudeme démona potřebovat, protože je přímo součástí Marsu. To je velmi sympatické, i když možná někdy už méně praktické.

NCP utility

Abychom mohli k Linuxu připojovat disky z NetWare (NW) serverů, tisknout na síťových tiskárnách a využívat dalších služeb nabízených NCP protokolem, potřebujeme NCP utility. Ty jsou součástí balíku ncpfs (NCP filesystem). Součástí poslední verze je i patch pro jádro, který přináší některá vylepšení. Jak je ve světě Unixu zvykem, několik jednoúčelových programů pokrývá základní požadované funkce. Aby byl popis utilit stravitelnější, rozdělil jsem je do několika skupin a jejich popisy jsem omezil na minimum (více napoví manuálové stránky).

V současné době je v Linuxu na velmi dobré úrovni podpora tzv. bindery databáze (NW 3.x). Podpora NDS vázne zejména na přístupu firmy Novell k tomuto problému. V každém případě je dnes buď možné na serverech verze 4.x zapnout emulaci bindery nebo použít stávající podporu NDS, která sice umožňuje připojovat disky z NW serveru, ale chybí utility pro manipulaci s NDS.

Pokud jsme připojeni k NW serveru, utility toto spojení používají. Jestliže při spuštění utility nejsme k žádnému serveru připojeni, utility se po spuštění nejprve přihlásí k NW serveru, pak provedou požadovanou činnost a na závěr se od serveru odpojí.

Konfigurační soubor ~/.nwclient

Většina utilit využívá konfigurační soubor ~/.nwclient, který má uživatel ve svém domácím adresáři. V tomto souboru si můžeme předdefinovat servery, jména i hesla. Protože hesla jsou velmi citlivou záležitostí, musí být soubor čitelný jen pro vlastníka (chmod 600 ~/.nwclient), jinak s ním utility odmítnou pracovat. Záznamy v souboru se dělí na řádky s tímto pořadím údajů: Jméno_serveru/jméno_uživatele případné_heslo

Příklad souboru ~/.nwclient:

    # Osobní účet, raději bez hesla (heslo bude nutné vkládat pokaždé ručně)
    PRUM/RENE.HUZVA
    # Anonymní účet na serveru BIMBO, bez hesla
    BIMBO/GUEST -
    # Poloveřejný účet pro návštevy s heslem pižďuch
    PRUM/NAVSTEVA pizduch
Pokud takový soubor nemáme, je potřeba uvádět jméno serveru a uživatelské jméno na každé příkazové řádce.

Základní utility

Příkaz Popis příkazu Ekvivalent v NW 3.x
slist výpis známých NW serverů v síti slist
nwuserlist výpis uživatelů připojených k NW serveru userlist
nsend zasílání zpráv uživatelům send
ncopy NW file copy (v rámci jednoho serveru) ncopy
nwpasswd změna NW hesla setpass
nwfsinfo informace o NW serveru ???
ncpmount připojení disků z NW
ncpumount odpojení NW disků
Základní NCP utility

ncpmount a ncpumount

Tyto příkazy slouží k připojování a odpojování NW disku k Linuxu a jak jejich název napovídá, jsou to blízcí příbuzní známých příkazů mount a umount. Rozdílným pojetím systémů však nelze na připojených NW discích pracovat s NW přístupovými právy. Unixová práva a vlastníky lze jednotně nastavit pouze při připojování disku a to pro celý připojovaný strom.
    ncpmount -S server -U uživatel /home/huzva/novell
    ncpmount /home/huzva/novell
Při připojování je registrováno UID uživatele, který operaci provedl, a tak může připojování a odpojování provádět každý uživatel (pokud jsou obě utility SUID root), protože je mu dovoleno odpojit jen svá připojení. V následující tabulce jsou uvedeny parametry příkazové řádky, prvních pět je možné použít i u většiny ostatních utilit.

PřepínačPopis přepínačeImplicitní hodnota
-S server jméno připojovaného NW serveru první v .nwclient
-U uživatel jméno uživatele na NW serveru podle .nwclient
-P heslo uživatelovo heslo podle .nwclient
-n uživatel nemá heslo podle .nwclient
-b připojit se v režimu bindery pokud lze, nejprve k NDS
-V svazek připojit pouze tento svazek připojit všechny svazky
-u UID uživatel vlastnící připojený strom aktuální uživatel
-g GID skupina vlastnící připojený strom aktuální skupina
-f práva přístupová práva k souborům 0755
-d práva přístupová práva k adresářům 0755
Parametry příkazové řádky utilit ncpmount a ncpumount

ncopy

Tento příkaz pro kopírování značně urychluje kopírování souborů v rámci disků jednoho serveru tak, že kopírování provádí sám server a data neputují ze serveru ke stanici a pak ihned zpět na server. Jestliže zdrojové a cílové soubory nejsou na stejném NW serveru, proběhne kopírování klasickým způsobem.

Utility pro tisk

V prostředí NW jsou k dispozici tiskové fronty (print queue) a tiskové servery (print server). Fronty slouží k řazení tiskových úloh od klientů. Zde úlohy čekají, až si tiskový server úlohu vyzvedne a vytiskne ji na připojené tiskárně. Tiskové fronty jsou umístěny na serveru a tiskový server běží na počítači, ke kterému je připojena tiskárna (může to být jak server sám, tak obyčejná stanice).

Příkaz Popis příkazu Ekvivalent v NW 3.x
pqlist výpis dostupných tiskových front na NW serveru pconsole
pserver print server pro NW tiskové fronty pconsole
pqstat výpis úloh v tiskové frontě pconsole
pqrm odstranění úlohy z tiskové fronty pconsole
nprint klient pro tisk do NW tiskových front nprint
NCP utility pro tisk

pserver

Přijímá úlohy čekající v NW tiskové frontě a odesílá je do místního tiskového systému v Linuxu. Běží na pozadí a standardně každých 30 vteřin kontroluje obsah NW tiskové fronty, jestli neobsahuje úlohu připravenou k vytištění.

nprint

Umí odeslat data určená k vytištění do NW tiskové fronty. Protože vyžaduje poměrně hodně přepínačů, je vhodné si nadefinovat vlastní alias nebo použít malý skript.

Utility pro práci s NW právy a soubory

Přístupová práva k souborům a adresářům jsou v případě připojení NW disku do Linuxu posuzována jak na straně Linuxu dle aktuálního uživatele a jeho členství ve skupinách, tak následně na straně NW serveru na základě autentifikace, která při připojení disku s NW serverem proběhla.

Mějme uživatele root, který si na straně Linuxu připojí z NW serveru disk a přitom se autentifikuje k tomuto NW serveru jako René.Hužva. Root má v Linuxu určitě neomezená práva, ale do připojeného svazku bude smět zapisovat jen do adresářů, do kterých má René Hužva povolen přístup právy na NW serveru.

Příkaz Popis příkazu Ekvivalent v NW 3.x
nwgrant nastavení NW práv v adresáři grant
nwrevoke obebrání NW práv v adresáři revoke
nwrights výpis efektivních NW práv k souboru nebo adresáři rights
nwauth ověření jména a hesla na NW serveru
nwtrustee výpis seznamu NW práv k adresáři tlist
nwvolinfo výpis informací o NW svazku volinfo
nwfstime výpis nebo nastavení času NW serveru fconsole
nwpurge definitivní zrušení smazaných souborů purge
NCP utility pro práci s NW právy a soubory

nwauth

Tato utilita provede pouze autentifikaci uživatele u NW serveru. Může sloužit k ověřování uživatelů ve skriptech nebo jako součást Vašeho nového programu, který se bude autentifikovat k NW.

Utility pro práci s bindery databází

Ekvivalenty k těmto příkazům nejsou ve standardní distribuci od firmy Novell. Pro DOSové prostředí podobným způsobem asi nejlépe poslouží příkaz userprop z balíku pro multiserverové prostředí od p. Koláře.

Příkaz Popis příkazu
nwbols výpis objektů
nwbocreate vytvoření objektu
nwborm smazání objektu
nwboprops výpis properties objektu
nwbpcreate vytvoření property
nwbprm odstranění property
nwbpvalues výpis obsahu property
nwbpadd nastavení hodnoty property
nwbpset vytvoření nebo nastavení hodnoty property
NCP utility pro práci s bindery databází

nwbols

nwbocreate

nwborm

nwboprops

Funkci dalších utilit nejlépe objasní manuálové stránky.

 

Linuxové noviny - http://www.linux.cz/noviny/ Březen 1998

Firewall v řetězech

Jan Kasprzak, 14. března 1998

V tomto článku vás chci seznámit s nástrojem zvaným ipchains, jehož autorem je Paul Russel (Paul.Russell@rustcorp.com.au). Je to nástroj pro tvorbu firewallů typu packetový filtr pod Linuxem. Jeho funkčnost je nadmnožinou funkčnosti IPFW.

Účel použití IP chains v systému je stejný, jako u klasického IPFW packetového filtru: specifikovat, které packety mohou projít systémem (ať již dovnitř, ven nebo být forwardovány přes systém), dále mít možnost sledovat, kolik packetů určitého tvaru prochází systémem, a dokonce mít možnost například logovat příchod podezřelých packetů. Poslední jmenovaná vlastnost je důležitá pro skutečně aktivní obranu před útočníkem a umožňuje odchytit pokusy o průnik hned v začátcích.

Zprovoznění IP chains

Systém IP chains má dvě části: jedna je uvnitř jádra a jde o vlastní filtrovací kód, druhá část - program ipchains - slouží k nastavování jednotlivých filtrovacích pravidel. První část je možno získat jako patch do jádra (ať již vývojového - série 2.1, tak i stabilního - série 2.0). Program ipchains je dostupný ve zdrojové formě z domovské stránky IP Firewalling chains. To, že v systému je nainstalován IP chains, lze ověřit tak, že existuje soubor /proc/sys/net/ip_fwchains.

Cesta packetu počítačem

K porozumění systému IP chains je nutné vědět, jakým způsobem prochází packet počítačem (viz obrázek Cesta packetu počítačem).

[ schéma ]

Obrázek 2: Cesta packetu počítačem

V čem se liší IP chains?

V předchozím odstavci jsem popsal cestu packetu počítačem. Tato cesta je v podstatě stejná při použití klasického firewallingu (ipfwadm) i při použití IP chains. Kde je tedy rozdíl?

Klasický přístup definoval tři základní sady filtrovacích pravidel - vstupní, forwardovací a výstupní (plus čtvrtý typ - accounting). V systému IP chains může být takovýchto sad (v terminologii IP chains řetězů) libovolně mnoho a mohou na sebe navzájem odkazovat. Existují tři výchozí řetězce: input, output a forward. Jádro každým z těchto řetězců kontroluje, jestli packet smí projít dál na příslušném místě zmiňovaného obrázku. Dále existuje pět pseudořetězců ACCEPT, DENY, REJECT, REDIR a MASQ. Tyto se chovají jako běžné řetězce v tom smyslu, že mohou být odkazovány z jiných řetězců (například pokud řetězec forward odkáže všechny packety na řetězec DENY, znamená to zákaz forwardování přes tento počítač).

Logika práce IP chains je pak jasná: Pomocí programu ipchains podobně jako přes ipfwadm vytváříme filtrovací pravidla. Tak jako v ipfwadm mělo každé pravidlo typ podle toho, jestli akceptovalo nebo odmítalo packet, který mu odpovídal, spustí v IP chains každé pravidlo na packet, který mu odpovídá, nějaký jiný řetězec (ACCEPT, DENY nebo jiný). Výhoda IP chains je v tom, že nejsme odkázáni jen na standardní pseudořetězce, ale můžeme si vytvářet vlastní.

Příklad - třídy počítačů

Mějme síť, na které běží několik serverů a několik uživatelských stanic. Chceme povolit telnet, ssh a finger na servery, jakékoli spojení ze serverů ven, ale na stanice chceme povolit jen finger. Pomocí ipfwadm bychom museli pro každý počítač jednotlivě specifikovat příslušná práva. Pokud bychom se později rozhodli například povolit ssh i na stanice, museli bychom přidat tolik pravidel, jako je stanic.

Pomocí IP chains můžeme například nadefinovat řetězec stanice a řetězec servery, a příslušné packety v řetězci forward na tyto přeposílat, jdou-li na servery, na stanice nebo jinam. Případnou změnu pro celou třídu strojů pak můžeme jednoduše realizovat přidáním jediného pravidla do řetězce stanice nebo servery:

MYNET=1.2.3.0/255.255.255.0
# Definujeme pravidla pro servery:
ipchains -N servery
# Dovnitř pustíme pouze na port telnetu, ssh, fingeru ...
ipchains -A servery -d $MYNET telnet -p tcp -j ACCEPT
ipchains -A servery -d $MYNET ssh -p tcp -j ACCEPT
ipchains -A servery -d $MYNET finger -p tcp -j ACCEPT
# ... a zakážeme otvírání jakýchkoli jiných 
#     TCP spojení dovnitř
ipchains -A servery -d $MYNET -p tcp -y -j DENY
# zbytek TCP packetu povolíme:
ipchains -A servery -p tcp -j ACCEPT
# Povolíme ICMP oběma směry
ipchains -A servery -p icmp -j ACCEPT
# Zbytek zakážeme
ipchains -A forward -j DENY

# Definujeme pravidla pro stanice:
ipchains -N stanice
# Dovnitř pustíme pouze na port fingeru ...
ipchains -A stanice -d $MYNET finger -p tcp -j ACCEPT
# ... a zakážeme otvírání jakýchkoli jiných 
#     TCP spojení dovnitř
ipchains -A stanice -d $MYNET -p tcp -y -j DENY
# zbytek TCP packetu povolíme:
ipchains -A stanice -p tcp -j ACCEPT
# Povolíme ICMP oběma smery
ipchains -A stanice -p icmp -j ACCEPT
# Zbytek zakážeme
ipchains -A forward -j DENY

# Řetězec forward: definujeme servery ...
ipchains -A forward -s 1.2.3.1 -j servery
ipchains -A forward -d 1.2.3.1 -j servery
ipchains -A forward -s 1.2.3.6 -j servery
ipchains -A forward -d 1.2.3.6 -j servery
ipchains -A forward -s 1.2.3.8 -j servery
ipchains -A forward -d 1.2.3.8 -j servery

# ... a stanice ...
ipchains -A forward -s 1.2.3.2 -j stanice
ipchains -A forward -d 1.2.3.2 -j stanice
ipchains -A forward -s 1.2.3.129 -j stanice
ipchains -A forward -d 1.2.3.129 -j stanice
ipchains -A forward -s 1.2.3.123 -j stanice
ipchains -A forward -d 1.2.3.123 -j stanice

# ... a zakážeme zbytek.
ipchains -A forward -j DENY

Takto tedy máme oddělenou sadu pravidel pro servery a pro stanice, přičemž přidání další stanice nebo dalšího serveru je otázku přidání dvou pravidel do řetězce forward, povolení další TCP služby pro danou třídu počítačů obnáší jedno další pravidlo do řetězce servery nebo stanice.

Samozřejmě definování řetězců podle tříd počítačů není jedinou možností IP chains. Je možné mít například odděleně vstupní a výstupní řetězec, nebo třeba řetězce pro každý interface či protokol zvlášť.

Výhody IP chains

Hlavním přínosem IP chains je samozřejmě možnost definování vlastních řetězců. Celý systém je ale vylepšen i o mnoho dalších vlastností:

Odkazy:

  1. Linux Firewalling Chains
    http://www.adelaide.net.au/~rustcorp/ipfwchains/,
  2. Linux IPCHAINS-HOWTO
    http://www.adelaide.net.au/~rustcorp/ipfwchains/HOWTO.html.

Squid

Squid je jedna z nejznámějších tzv. proxy cache. Jejím úkolem je přebírat od klientů v lokální síti všechny požadavky a vyřizovat je tak, aby při dalším dotazu na stejný objekt (stránka, obrázek) byl tento poskytnut co nejrychleji. K tomuto účelu je pro proxy vyhrazen diskový prostor, na který si všechny statické (tj. neměnné, opak CGI nebo ASP skriptů) objekty ukládá. Pro získávání dokumentů využívá okolních proxy (např. u Vašeho providera) tak, aby minimalizoval síťový provoz (tj. pokud je možno objekt získat od nich, je to efektivnější způsob, který proxy využije).

Při ukládání objektů na disk je potřeba zajistit, aby nebyl do lokální sítě klientům donekonečna předáván zastaralý objekt. K tomu se vypočítává tzv. morální stáří dokumentu. Protože proxy nemůže vědět dopředu, kdy se objekt změní, má v podstatě dvě možnosti: buď pokaždé ověří, zda objekt nebyl na původním místě změněn nebo toto ověřování provádí občas. Toto občas je založeno na poslední modifikaci každého objektu zvlášť. Pokud byl objekt modifikován naposledy před třemi lety, je vysoká pravděpodobnost, ža v nejbližší době nebude změněn. Pokud byl modifikován před pěti minutami, dá se předpokládat, že se s objektem pracuje a že se v nejbližší době bude měnit. V tomto případě proxy ověří, zda není k dispozici novější verze objektu velmi brzo (řekněme ihned při následujícím požadavku na získání tohoto objektu od klienta v naší lokální síti).

Ve vztazích mezi jednotlivými proxy panuje buď vztah rodičovský nebo sourozenecký. V případě rodičovského (parent) vztahu proxy objekt, který od rodiče získá, uloží do svého diskového prostoru (typicky je rodičovská proxy u providera, od kterého jsme odděleni tenkou linkou). Při vztahu sourozeneckém (sibling) proxy objekty získané od sourozence na disk neukládá (typicky se jedná o spřízněnou proxy na stejném segmentu sítě, která je připojena vysokokapacitním spojením a tento sourozenecký vztah je využíván pro rozložení zátěže jednotlivých počítačů s proxy.

Následující jednoduchý případ umožňuje využívání proxy z našeho lokálního stroje (je to konfigurace obsažená v balíčku Squid z distribuce Red Hat):

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 21 443 563 70 210 1025-65535
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
icp_access allow all
miss_access allow all
error_directory /usr/lib/squid/errors/Czech
ACL (Access List) slouží k definování přístupu (http_access) k naší proxy. Pokud bychom chtěli zajistit přístup z celé naší síťě (10.0.0.0 s maskou 255.255.255.0), musíme si nadefinovat další ACL a začlenit jej do konfigurace před http_access deny all:
acl nasesit src 10.0.0.0/255.255.255.0
http_access allow nasesit
Celý konfigurační soubor /etc/squid/squid.conf je velmi hezky komentován. Pokud by to nestačilo, podívejte se na FAQ pro Squida na adrese http://www.squid-cache.org/.

Pro definici jednoho rodiče a jednoho sourozence můžeme použít:

cache_peer cache.nase.firma.cz   sibling 3128 3130 weight=200 proxy-only
cache_peer cache.nasprovider.cz parent  3128 3130 weight=100
Pokud bychom chtěli získat informace o tom, jak naše proxy funguje, stačí použít CGI skript, který je se Squidem dodáván (cachemgr.cgi). Pokud do konfigurace našeho WWW serveru Apache přidáme řádku ScriptAlias /cachemgr.cgi "/usr/lib/squid/cachemgr.cgi" nebo umístíme tento skript do adresáře cgi-bin, pak po přídání řádku cachemgr_passwd tajneheslo all můžeme zjišťovat provozní stav naší proxy. Podle základních pouček by průměrné stáří objektů mělo být kolem pěti dnů, počet page faults by neměl překračovat počet HTTP dotazů (jinak je málo paměti - můžeme ji Squidovi i ubrat direktivou cache_mem. Zde je potřeba si uvědomit, že Squid typicky zabere cca 8-16 MB RAM jen na indexy své diskové cache, které drží všechny paměti (při 2GB oblasti). Výše uvedená direktiva povoluje Squidovi zabrat další RAM pro objekty, které drží v paměti (rychlejší odezva, než z disku).

Transparentní proxy

Transparentní proxy znamená, že veškeré průchozí požadavky jsou přesměrovány (jdoucí na cílový port 80 - WWW) na lokální proxy cache, která je vyřídí. Na straně uživatele nejsou potřeba zádné dodatečné akce. Proxy (Squid) musí vědět, že se o něco takového pokoušíme, takže musíme doplnit následující volby do jeho konfiguračního souboru:
http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Dále je potřeba nastavit příslušná pravidla pro Ipchains:
# povoleno vše na zařízení loopback
ipchains -A input -i lo -j ACCEPT
# musíme povolit přímý přístup na náš port 80 (je tam WWW server)
ipchains -A input -d MY.IP.IP.IP www -p tcp -j ACCEPT
# všechen ostatní provoz musí být přesměrován na proxy
ipchains -A input -s MY.NET.IP.IP/24 -d 0.0.0.0/0 www -p tcp -j REDIRECT 3128
Nezapomeneme povilit IP packet forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
Nakonec restartujeme proxy.

Masquerade

Maškaráda je zvláštní pojem pro situaci, kdy stanice ve vnitřní síti mají IP adresy z privátního rozsahu. Při komunikaci s okolním Internetem je potřeba, aby odcházející datagramy dostaly návratovou adresu od firewallu, který jediný vlastní routovatelnou IP adresu. Průchozí datagram, který otevírá spojení, způsobí zápis do zvláštní tabulky, podle které se provede zpětný překlad při příchodu datagramu s odpovědí.
# FTP vyžaduje kernel proxy, která obhopodařuje datová spojení na jiném
# portu
modprobe ip_masq_ftp

# IP forwarding musí být povolen
echo 1 > /proc/sys/net/ipv4/ip_forward

# defaulní forward politika bude DENY
ipchains -P forward DENY

# ppp0 je VÝSTUPNÍ interface, povolíme jen síť 10.0.0.0/255.255.0.0
ipchains -A forward -s 10.0.0.0/16 -i ppp0 -j MASQ
Takto nastavená maškaráda umožní, aby fungovaly FTP, telnet, SSH a další relace, které jsou navazovány zevnitř sítě ven. Obrácené navazování spojení (tj. zvenčí dovniř) není možné bez nastavení explicitního portforwadingu.