From owner-p4-projects@FreeBSD.ORG Sun Jul 20 08:24:05 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 9FCDD106567C; Sun, 20 Jul 2008 08:24:05 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 640611065671 for ; Sun, 20 Jul 2008 08:24:05 +0000 (UTC) (envelope-from pgj@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 519E38FC0C for ; Sun, 20 Jul 2008 08:24:05 +0000 (UTC) (envelope-from pgj@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.1/8.14.1) with ESMTP id m6K8O544050079 for ; Sun, 20 Jul 2008 08:24:05 GMT (envelope-from pgj@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.2/8.14.1/Submit) id m6K8O4d8050077 for perforce@freebsd.org; Sun, 20 Jul 2008 08:24:04 GMT (envelope-from pgj@FreeBSD.org) Date: Sun, 20 Jul 2008 08:24:04 GMT Message-Id: <200807200824.m6K8O4d8050077@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to pgj@FreeBSD.org using -f From: Gabor Pali To: Perforce Change Reviews Cc: Subject: PERFORCE change 145492 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 08:24:05 -0000 http://perforce.freebsd.org/chv.cgi?CH=145492 Change 145492 by pgj@disznohal on 2008/07/20 08:23:47 MFen: 1.227 -> 1.228 hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml 1.185 -> 1.186 hu_HU.ISO8859-2/books/handbook/eresources/chapter.sgml 1.83 -> 1.84 hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml 1.444 -> 1.447 hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml 1.104 -> 1.105 hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml 1.114 -> 1.116 hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml 1.321 -> 1.324 hu_HU.ISO8859-2/books/handbook/security/chapter.sgml 1.128 -> 1.129 hu_HU.ISO8859-2/books/handbook/serialcomms/chapter.sgml 1.59 -> 1.60 hu_HU.ISO8859-2/share/sgml/mailing-lists.ent Affected files ... .. //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml#4 edit .. //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/eresources/chapter.sgml#9 edit .. //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml#10 edit .. //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml#6 edit .. //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml#4 edit .. //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml#4 edit .. //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml#5 edit .. //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/serialcomms/chapter.sgml#6 edit .. //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/share/sgml/mailing-lists.ent#8 edit Differences ... ==== //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml#4 (text+ko) ==== @@ -7,7 +7,7 @@ @@ -2512,8 +2512,9 @@ keresztül. Végül gyõzödjünk meg róla, - hogy az /etc/make.conf tartalma a - fordítási csoport mindegyik + hogy az /etc/make.conf és a + /etc/src.conf állományok + tartalma a fordítási csoport mindegyik gépénél megegyezik a fordító gépével. Ez azt jelenti, hogy a fordító gépnek az alaprendszer ugyanazon ==== //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/eresources/chapter.sgml#9 (text+ko) ==== @@ -7,7 +7,7 @@ @@ -716,6 +716,12 @@ + &a.wip-status.name; + A &os;-vel kapcsolatos folyamatban levõ + fejlesztések helyzetjelentései + + + &a.www.name; A www.FreeBSD.org @@ -2011,6 +2017,48 @@ + + &a.wip-status.name; + + + A &os;-vel kapcsolatos folyamatban levõ + fejlesztések + helyzetjelentése + + Ezen a levelezési listán kerülnek + bejelentésre a &os; + továbbfejlesztéséhez + fûzõdõ különbözõ + munkák és azok haladásának + menete. Az ide befutó üzeneteket + moderálják. Javasoljuk, hogy + elsõdlegesen az adott témához + tartozó tematikus &os; listára + küldjük a bejelentésünket és + csak egy másolatot erre a listára. Ennek + köszönhetõen a munkánk az adott + témaspecifikus listán rögtön meg + is vitatható, mivel ezen a listán semmi + ilyen nem engedélyezett. + + A lista archívumába tekintve + tájékozódhatunk arról, hogy pontosan + milyen formai követelmények illene megfelelnie a + beküldenõ üzenetünknek. + + A listára beérkezõ üzenetekbõl + egy szerkesztett válogatás jelenik meg + néhány havonta a &os; honlapján a Projekt + helyzetjelentésének részeként + + + . A korábban beküldött + jelentések mellett itt még találhatunk + további példákat. + + + ==== //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml#10 (text+ko) ==== @@ -7,7 +7,7 @@ ==== //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml#6 (text+ko) ==== @@ -7,7 +7,7 @@ The FreeBSD Hungarian Documentation Project Translated by: PALI, Gabor %SOURCE% en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml - %SRCID% 1.444 + %SRCID% 1.447 --> @@ -389,23 +389,12 @@ - Ausztria: - :pserver:anoncvs@anoncvs.at.FreeBSD.org:/home/ncvs (a - cvs login használatával - tetszõleges jelszó megadható) - - Franciaország: :pserver:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs (pserver (a jelszó anoncvs), ssh (nincs jelszó)) - Németország: - :pserver:anoncvs@anoncvs.de.FreeBSD.org:/home/ncvs (rsh, - pserver, ssh, ssh/2022) - - Japán: :pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs (a cvs login @@ -4026,6 +4015,22 @@ + Oroszország + + + rsync://cvsup4.ru.FreeBSD.org + + Elérhetõ gyûjtemények: + + + FreeBSD-gnats: A GNATS + hibanyilvántartó + adatbázis. + + + + + Tajvan ==== //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml#4 (text+ko) ==== @@ -7,7 +7,7 @@ @@ -1132,7 +1132,8 @@ A következõ módon indíthatjuk el: - &prompt.root; /etc/rc.d/nfslocking start + &prompt.root; /etc/rc.d/lockd start +&prompt.root; /etc/rc.d/statd start Ha nincs szükségünk valódi zárolásra az NFS kliensek ==== //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/printing/chapter.sgml#4 (text+ko) ==== @@ -7,7 +7,7 @@ @@ -1615,18 +1615,20 @@ A nyomtatóeszköz azonosítása - A portok beállításával - foglalkozó szakaszban már + A Hardveres beállítás + címû szakaszban már beazonosítottuk, hogy a &os; a /dev könyvtárban melyik eszközleírón keresztül fogja megszólítani a nyomtatót. Most ideje - ugyanezt tudatni az LPD-vel is. - Így amikor a nyomtatási rendszer ki szeretne - nyomtatni egy munkát, a szûrõprogram - nevében ezt az eszközt nyitja meg (ahol a - szûrõn keresztül továbbítjuk az - adatokat a nyomtató felé). + ugyanezt tudatni az LPD + démonnal is. Így amikor a nyomtatási + rendszer ki szeretne nyomtatni egy munkát, a + szûrõprogram nevében ezt az eszközt + nyitja meg (ahol a szûrõn keresztül + továbbítjuk az adatokat a nyomtató + felé). Az lp tulajdonság segítségével a @@ -2726,11 +2728,11 @@ :if=/usr/local/libexec/ifhp: Készen is vagyunk! Most már nyugodtan - beírhatjuk, hogy lpr - sima.szöveg vagy - lpr - akármi.ps, mind a - kettõnek ki kell tudnia nyomtatódnia. + beírhatjuk, hogy + lpr sima.szöveg vagy + lpr akármi.ps, + mind a kettõnek ki kell tudnia + nyomtatódnia. ==== //depot/projects/docproj_hu/doc/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml#5 (text+ko) ==== @@ -7,7 +7,7 @@ @@ -1996,21 +1996,21 @@ egyetlen tûzfal nem képes például szövegesen válaszolni a kapcsolatok kezdeményezõinek. Ellenben bármelyik - TCP szoftver képes erre, sõt - még többre is. A következõ + TCP-wrapper szoftver képes erre, + sõt még többre is. A következõ néhány szakaszban szemügyre vesszük a - TCP burkolók számos + TCP wrapperek számos lehetõségét, és ahol lehetséges, ott konfigurációs állományokkal is illusztráljuk ezek használatát. A TCP burkoló szoftverek - kiterjesztik az inetd képességeit - minden alatta dolgozó szerverdémon - támogatására. Ezzel a módszerrel meg - lehet oldani a naplózást, üzenetek - küldését a kapcsolatokhoz, a démonok - elérhetõségének + kiterjesztik az inetd + képességeit minden alatta dolgozó + szerverdémon támogatására. Ezzel a + módszerrel meg lehet oldani a naplózást, + üzenetek küldését a kapcsolatokhoz, a + démonok elérhetõségének korlátozását stb. Noha ezen lehetõségek közül néhány tûzfallal is megvalósítható, ezzel nem @@ -2029,13 +2029,13 @@ rendszerünk biztonságában egy újabb remek védelmi vonalat képvisel. - Mivel lényegében ez az inetd + Mivel lényegében ez az + inetd beállításának kibõvítése, ezért a szakasz elolvasásához feltételezzük az inetd - beállításával kapcsolatos - tudnivalók ismeretét. + linkend="network-inetd">inetd beállításával + kapcsolatos tudnivalók ismeretét. Bár az &man.inetd.8; által indított @@ -2051,10 +2051,10 @@ &os; alatt a TCP burkolók használatának egyetlen feltétele - csupán annyi, hogy az inetd parancsot - a paraméterrel indítsuk az - rc.conf állományból. - Az egyébként az + csupán annyi, hogy az inetd + parancsot a paraméterrel + indítsuk az rc.conf + állományból. Az egyébként az alapbeállítás. Természetesen nem árt, ha helyesen állítjuk be az /etc/hosts.allow állományt @@ -2080,8 +2080,8 @@ /etc/hosts.allow állományban szereplõ beállításokkal. A &os; alapértelmezett beállításai szerint - minden inetd által indított - démonhoz lehet kapcsolódni. Ennek + minden inetd által + indított démonhoz lehet kapcsolódni. Ennek megváltoztatásával az alapkonfiguráció áttekintése után foglalkozunk. @@ -2095,10 +2095,10 @@ IP-cím vagy szögletes zárójelek ([ ]) között megadott IPv6 formátumú cím. A cselekvést - tartalmazó mezõ lehet allow vagy - deny annak megfelelõen, hogy - engedélyezzük vagy tiltjuk a megadott - címrõl a csatlakozást. Nem szabad + tartalmazó mezõ (action) lehet + allow vagy deny annak + megfelelõen, hogy engedélyezzük vagy tiltjuk a + megadott címrõl a csatlakozást. Nem szabad elfelejtenünk, hogy az így megadott beállítások közül mindig az elsõként illeszkedõ @@ -2126,7 +2126,7 @@ qpopper : ALL : allow Miután hozzáadtuk ezt a sort, az - inetd szervert újra kell + inetd szervert újra kell indítanunk. Ezt vagy a &man.kill.1; paranccsal, vagy pedig az /etc/rc.d/inetd szkript restart paraméterével @@ -2240,9 +2240,10 @@ A korábban már kifejtett helyettesítõ karakterek túl, mint - például az %a, még léteznek - továbbiak is. Róluk a &man.hosts.access.5; man - oldalon találhatjuk meg a teljes listát. + például az %a, még + léteznek továbbiak is. Róluk a + &man.hosts.access.5; man oldalon találhatjuk meg a + teljes listát. @@ -4413,54 +4414,6 @@ egyaránt támogatja az IPv4 és IPv6 protokollcsaládokat. - - A &os;-ben Fast IPsec néven - találunk egy hardvergyorsítással - támogatott IPsec protokollkészletet is, - amelyet még az OpenBSD-bõl vettek át. Ez - (amikor lehetséges) a &man.crypto.4; alrendszeren - keresztül egy kriptográfiai célhardver - bevonásával igyekszik növelni az IPsec - teljesítményét. Ez az alrendszer - még új, és még nem is ismeri az - IPsec KAME változata által - felkínált összes lehetõséget. - A hardvergyorsítással kisegített IPsec - engedélyezéséhez a következõ - opciót kell hozzátennünk a rendszermag - beállításait tartalmazó - állományhoz: - - - a rendszermag - beállításai - FAST_IPSEC - - - -options FAST_IPSEC # az új IPsec (nem megy az IPSEC-kel együtt) - - - Vegyük észre, hogy jelen pillanatban a - Fast IPsec alrendszer nem - használható az IPsec KAME változata - helyett. Ennek részleteirõl a &man.fast.ipsec.4; - man oldalon tájékozódhatunk. - - - - A rendszermag beállításai - között az - opcióra is szükségünk lesz ahhoz, hogy - a tûzfalak megfelelõ módon követni - tudják a &man.gif.4; tunnelek - állapotát. - - -options IPSEC_FILTERGIF # a tunnelekbõl érkezõ IPsec csomagok szûrése - - - IPsec ESP @@ -4592,9 +4545,12 @@ - A forgatókönyv: két, interneten - keresztül összekötött hálózat, - melyeket egyként akarunk használni + A forgatókönyv: adott egy otthoni és egy + vállalati hálózat, amelyek + külön-külön csatlakoznak az internetre, + és <acronym>VPN</acronym> használatával + ezeket egyetlen hálózatként + szeretnénk használni VPN @@ -4626,1084 +4582,359 @@ a hálózatok belsõ címei lehetnek publikus vagy privát IP-címek, nem - számít. Az átjárón - igény szerint végezhetünk - címfordítást (NAT) is; - - - a két hálózat belsõ - IP-címei nem fedik át - egymást. Habár elméletben - lehetséges a VPN és NAT - technológiák elegyítése, ezt a - típusú felállást itt most nem - preferáljuk. + számít. Fontos viszont, hogy ezek ne + ütközzenek, vagyis ne használja egyszerre + mind a kettõ a 192.168.1.x + címtartományt. + - Ha belül mind a két hálózat - ugyanolyan tartományú IP-címeket - használ (például 192.168.1.x), akkor az egyiküket - át kell számozni. + + + + + Tom + Rhodes + +
trhodes@FreeBSD.org
+ + Írta: + + + - A hálózat felépítése - tehát valahogy így nézhet ki: + Az IPsec beállítása &os; alatt - - - - + Kezdésképpen a + Portgyûjteménybõl telepítenünk kell a + security/ipsec-tools portot. + Ez a programcsomag rengeteg olyan alkalmazást tartalmaz, + amely segítségünkre lehet a + beállítások elvégzése + során. - - 1. hálózat [ Belsõ gépek ] Privát hálózat: 192.168.1.2-254 - [ Win9x/NT/2K ] - [ UNIX ] - | - | - .---[fxp1]---. Privát IP: 192.168.1.1 - | FreeBSD | - `---[fxp0]---' Publikus IP: A.B.C.D - | - | - -=-=- Internet -=-=- - | - | - .---[fxp0]---. Publikus IP: W.X.Y.Z - | FreeBSD | - `---[fxp1]---' Privát IP: 192.168.2.1 - | - | -2. hálózat [ Belsõ gépek ] - [ Win9x/NT/2K ] Privát hálózat: 192.168.2.2-254 - [ UNIX ] - - + A következõ lépésben létre + kell hoznunk két &man.gif.4; típusú + pszeudoeszközt, melyeken keresztül a két + hálózat között egy tunnel + segítségével ki tudjuk + építeni a szükséges kapcsolatot. + Ehhez root + felhasználóként futtassuk a + következõ parancsokat (a + belsõ és + külsõ + megnevezésû paramétereket + cseréljük ki a valós belsõ és + külsõ átjárók + címeire): - Figyeljük meg a két publikus IP-címet. A - leírás további részében - betûkkel hivatkozunk rájuk, tehát ahol ezek - szerepelnek, oda kell behelyettesíteni a saját - publikus címeinket. A két - átjáró címében .1 az - utolsó szám, és hogy két - hálózat privát IP-címei - eltérnek (192.168.1.x - és 192.168.2.x). A - privát hálózatokon belül minden - számítógépet úgy - állítottunk be, hogy alapértelmezés - szerint a .1 számú - gépet használják - átjárónak. + &prompt.root; ifconfig gif0 create + &prompt.root; ifconfig gif0 belsõ1 belsõ2 + &prompt.root; ifconfig gif0 tunnel külsõ1 külsõ2 - Hálózati szemszögbõl ez azért - fontos, mert így az egyes hálózatok - úgy látják egymás gépeit, - mintha közvetlenül ugyanahhoz az - útválasztóhoz csatlakoznának — - jóllehet ez egy kicsit lassúcska - útválasztó, ami idõnként - hajlamos eldobni a csomagokat. + Tekintsük például, hogy a + vállalati LAN publikus + IP-címe 172.16.5.4, valamint a privát + IP-címe 10.246.38.1. Az otthoni + LAN publikus + IP-címe legyen most 192.168.1.12, valamint a belsõ + privát IP-címe pedig 10.0.0.5. - Ez tehát azt jelenti (például), hogy a - 192.168.1.20 címû - számítógépnek gond - nélküli megy a + Elsõre ez talán még nem teljesen + érthetõ, ezért az &man.ifconfig.8; parancs + használatával is nézzük meg a + példában szereplõ hálózatok + konfigurációját: - ping 192.168.2.34 + Az elsõ átjáró: - parancs. Ugyanígy a &windows;-os gépek is - képesek látni a másik - hálózaton levõ - számítógépeket, belépni - egymás megosztásaiba és így - tovább, pontosan úgy, mint a helyi - hálózaton levõ gépek - esetében. +gif0: flags=8051 mtu 1280 +tunnel inet 172.16.5.4 --> 192.168.1.12 +inet6 fe80::2e0::81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6 +inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00 - Ne feledjük, hogy mindennek egyszerre - biztonságosnak is kell lennie. Vagyis a két - hálózat közti forgalmat titkosítanunk - kell. +A második átjáró: - A VPN létrehozása a két - hálózat között egy - többlépcsõs folyamat. Ezek a - lépcsõk az alábbiak: +gif0: flags=8051 mtu 1280 +tunnel inet 192.168.1.12 --> 172.16.5.4 +inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 +inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4 - - - Az interneten keresztül hozzunk létre egy - virtuális hálózati - összeköttetést a két - hálózat között. A &man.ping.8; - és hasonló segédprogramok - segítségével gyõzõdjünk - meg a - mûködõképességérõl. - + Miután elvégeztük az iménti + beállításokat, a &man.ping.8; paranccsal + már mind a két privát + IP-tartománynak + elérhetõnek kell lennie, ahogy azt az alábbi + példa is érzékeltetni + kívánja: - - A hálózatok között zajló - forgalom akadálymentes - titkosításához szükség - esetén alkalmazzuk valamilyen biztonsági - házirendet. A &man.tcpdump.1; és - hasonló segédprogramok - használatával ellenõrizzük a - hálózati forgalom - titkosítását. - + otthoni-halo# ping 10.0.0.5 +PING 10.0.0.5 (10.0.0.5): 56 data bytes +64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms +64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms +64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms +64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms +--- 10.0.0.5 ping statistics --- +4 packets transmitted, 4 packets received, 0% packet loss +round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms - - A &os; átjárókon - állítsunk be olyan szoftvereket, amelyekkel a - &windows;-os számítógépek is - képesek látni egymást a - virtuális magánhálózaton - keresztül. - - +vallalati-halo# ping 10.246.38.1 +PING 10.246.38.1 (10.246.38.1): 56 data bytes +64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms +64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms +64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms +64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms +64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms +--- 10.246.38.1 ping statistics --- +5 packets transmitted, 5 packets received, 0% packet loss +round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms - - Az elsõ lépés: a - <quote>virtuális</quote> hálózati - összeköttetés kialakítása - és kipróbálása + Az elvárásainknak megfelelõen + tehát a privát címeken mind a két + oldalnak képesnek kell lennie ICMP + csomagokat küldenie és fogadnia. A + következõ lépésben meg kell mondanunk az + átjáróknak hogyan + irányítsák a csomagokat a két + hálózat közti forgalom megfelelõ + áramlásához. Ezt az alábbi + paranccsal elérhetjük el: - Tegyük fel, hogy a bejelentkeztünk az elsõ - hálózat átjárójára - (amelynek a publikus IP-címe A.B.C.D, a privát IP-címe - 192.168.1.1), és - kiadtunk a W.X.Y.Z - címû gép privát - IP-címére egy ping - 192.168.2.1 parancsot. Hogyan is - valósítható meg ez? + &prompt.root; vallalati-halo# route add 10.0.0.0 10.0.0.5 255.255.255.0 + &prompt.root; vallalati-halo# route add net 10.0.0.0: gateway 10.0.0.5 - - - Az átjárónak el kell tudnia - érnie valahogy a 192.168.2.1 címet. Vagy - úgy is mondhatjuk, hogy a 192.168.2.1 felé ismeri az - utat. - - - A privát IP-címek tartományainak, - amilyen például a 192.168.x, nem szabadna - megjelenniük az interneten. Ehelyett minden olyan - csomagot, amelyet a 192.168.2.1 címre - küldünk, be kell csomagolnunk egy másik - csomagba. Ezt a csomagot úgy kell - beállítani, mintha az A.B.C.D címrõl - küldtük volna a W.X.Y.Z címre. Ennek - folyamatát hívják - becsomagolásnak - (encapsulation). - - - Amikor ez a csomag megérkezik a W.X.Y.Z címre, ki - kell bontani és kézbesíteni a - 192.168.2.1 - címre. - - + &prompt.root; otthoni-halo# route add 10.246.38.0 10.246.38.1 255.255.255.0 + &prompt.root; otthoni-halo# route add host 10.246.38.0: gateway 10.246.38.1 - Erre úgy is gondolhatunk, mint egy - járatra a két - hálózat között. A járat - két szája lesz az A.B.C.D és W.X.Y.Z cím, és a - járatnak ismernie kell azokat a privát - IP-címeket, amiket átereszthet. Ezen a - járaton keresztül fog mozogni a privát - IP-címek között az adat az interneten. + Itt már a belsõ gépeket az + átjárókról és az + átjárók mögül egyaránt + el tudjuk érni. A következõ példa + alapján errõl könnyedén meg is + tudunk gyõzõdni: - Ezt a járatot egy általános - felület (generic interface, avagy a - gif eszközök) - használatával hozzuk létre a &os;-k - között. Ahogy számíthattunk is - rá, az egyes átjárókon levõ - gif felületekhez négy - IP-címet kell beállítani: kettõt a - publikus címeknek, kettõt pedig a privát - címeknek. + vallalati-halo# ping 10.0.0.8 +PING 10.0.0.8 (10.0.0.8): 56 data bytes +64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms +64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms +64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms +64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms +64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms +--- 10.0.0.8 ping statistics --- +5 packets transmitted, 5 packets received, 0% packet loss +round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms - A gif eszköz támogatását be kell - építeni mind a két &os; gép - rendszermagjába. Ehhez mind a két gépen - a következõ sort kell hozzáadnunk a - rendszermag beállításait - tartalmazó állományhoz: +otthoni-halo# ping 10.246.38.107 +PING 10.246.38.1 (10.246.38.107): 56 data bytes +64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms +64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms +64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms +64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms +64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms +--- 10.246.38.107 ping statistics --- +5 packets transmitted, 5 packets received, 0% packet loss +round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms - device gif + A tunnelek beállítása volt + igazából a könnyebb rész, egy + biztonságos összeköttetés + kialakítása azonban már valamivel komolyabb + folyamatot rejt magában. A most következõ + konfigurációban erre elõre + ismert (vagyis pre-shared, PSK) + RSA-kulcsokat fogunk használni. A + konkrét IP-címektõl + eltekintve az átjárókon a + /usr/local/etc/racoon/racoon.conf + állományok hasonlóan fognak kinézni, + nagyjából valahogy így: - Ezután a megszokott menetben fordítani, - telepíteni és újraindítani a - rendszereiket. + path pre_shared_key "/usr/local/etc/racoon/psk.txt"; # az ismert kulcsot tartalmazó állomány helye +log debug; # a naplózás részletességének beállítása: ha végeztünk a teszteléssel és a hibakereséssel, akkor állítsuk át a 'notify' értékre - A járat beállítása két - lépésbõl áll. Elõször is - az &man.ifconfig.8; használatával a tunnelnek - meg kell mondanunk, hogy mik a külsõ (avagy - publikus) IP-címek. Ezután adjuk meg - ugyanígy a privát IP-címeket. +padding # ezeket ne nagyon változtassuk meg +{ + maximum_length 20; + randomize off; + strict_check off; + exclusive_tail off; +} - Az elsõ hálózat - átjáróján az alábbi - parancsokat kell kiadni a tunnel - beállításához. +timer # idõzítési beállítások, állítsuk be igény szerint +{ + counter 5; + interval 20 sec; + persend 1; +# natt_keepalive 15 sec; + phase1 30 sec; + phase2 15 sec; +} - &prompt.root; ifconfig gif0 create -&prompt.root; ifconfig gif0 tunnel A.B.C.D W.X.Y.Z -&prompt.root; ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff - +listen # cím [port], ahol a racoon majd válaszolni fog +{ + isakmp 172.16.5.4 [500]; + isakmp_natt 172.16.5.4 [4500]; +} - A másik átjárón is futtassuk - le ugyanezeket a parancsokat, de az IP-címek - sorrendjét ezúttal cseréljük - fel. +remote 192.168.1.12 [500] +{ + exchange_mode main,aggressive; + doi ipsec_doi; + situation identity_only; + my_identifier address 172.16.5.4; + peers_identifier address 192.168.1.12; + lifetime time 8 hour; + passive off; + proposal_check obey; +# nat_traversal off; + generate_policy off; - &prompt.root; ifconfig gif0 create -&prompt.root; ifconfig gif0 tunnel W.X.Y.Z A.B.C.D -&prompt.root; ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff - + proposal { + encryption_algorithm blowfish; + hash_algorithm md5; + authentication_method pre_shared_key; + lifetime time 30 sec; + dh_group 1; + } +} - Ezután már jöhet ez a parancs: +sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $hálózat/$hálózati_maszk $típus address $hálózat/$hálózati_maszk $típus + # (a $típus lehet "any" vagy "esp") +{ # a $hálózat a két összekapcsolni kívánt belsõ hálózat legyen + pfs_group 1; + lifetime time 36000 sec; + encryption_algorithm blowfish,3des,des; + authentication_algorithm hmac_md5,hmac_sha1; + compression_algorithm deflate; +} - ifconfig gif0 + A példában szereplõ összes + opció részletes kifejtése jóval + meghaladná ezen leírás kereteit, + ezért a bõvebb információkkal + kapcsolatban inkább a racoon + beállításaihoz tartozó man oldal + elolvasását javasoljuk. - Ezzel elénk tárulnak az iménti - beállításaink. Például az - elsõ hálózat - átjáróján nagyjából - ezt fogjuk látni: + A gépek közti hálózati forgalom + titkosításához be kell még + állítanunk egy SPD + házirendet is, így a &os; és a + racoon képes kódolni + és dekódolni a csomagokat. - &prompt.root; ifconfig gif0 -gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 - tunnel inet A.B.C.D --> W.X.Y.Z - inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff - + Ezt a most következő, a vállalati átjárón találhatóhoz + hasonló egyszerű shell szkripttel tudjuk elvégezni. Ezt az + állományt a rendszer indításakor fogjuk felhasználni, melyet + /usr/local/etc/racoon/setkey.conf néven + mentsünk el: - Remekül látszik, hogy létrejött - egy tunnel az A.B.C.D és - W.X.Y.Z fizikai címek - között, illetve hogy ezen a járaton - keresztül a 192.168.1.1 - és 192.168.2.1 - címek között engedélyezett a - kommunikáció. + #!/bin/sh +/usr/local/sbin/setkey -FP +/usr/local/sbin/setkey -F +# Az otthoni hálózati felé +/usr/local/sbin/setkey -c spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use; +/usr/local/sbin/setkey -c spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use; - Ezzel együtt ki kell egészítenünk - mind a két gép útválasztási - táblázatát, amit a netstat - -rn paranccsal meg is tudunk vizsgálni. Most - az elsõ hálózat - átjáróján vagyunk. + Ahogy ezzel megvagyunk, a racoon + az egyes átjárókon a következõ + paranccsal indítható el: - &prompt.root; netstat -rn -Routing tables + &prompt.root; /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log -Internet: -Destination Gateway Flags Refs Use Netif Expire -... -192.168.2.1 192.168.1.1 UH 0 0 gif0 -... - >>> TRUNCATED FOR MAIL (1000 lines) <<<