Primární zdroj: | http://www.spsselib.hiedu.cz/~kerslage/manuals/linux/network/ |
Autor: | Milan Keršláger |
Aktualizace: | echo Date("d.m.Y, H:i:s", fileMtime($_SERVER["SCRIPT_FILENAME"]))?> |
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=5Pokud 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.254Konfiguraci 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
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 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.53Kontrolu 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).
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
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
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
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-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 RELAYSoubor
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.czV 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 restartDalší podrobnosti o konfiguraci Sendmailu pomocí M4 makrojazyka se nacházejí v souboru
/usr/lib/sendmail-cf/README
z balíčku
sendmail-doc
.
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.
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ámce | Charakteristika |
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 |
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.
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
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é.
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í.
~/.nwclient
~/.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 pizduchPokud takový soubor nemáme, je potřeba uvádět jméno serveru a uživatelské jméno na každé příkazové řádce.
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ů |
ncpmount a ncpumount
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/novellPř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če | Implicitní 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 |
ncopy
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
|
pserver
nprint
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
|
nwauth
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 |
nwbols
nwbocreate
nwborm
nwboprops
Linuxové noviny - http://www.linux.cz/noviny/ | Březen 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).
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:
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/CzechACL (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 nasesitCelý 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=100Pokud 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).
http_port 3128 httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header onDá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 3128Nezapomeneme povilit IP packet forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forwardNakonec restartujeme proxy.
# 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 MASQTakto 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.