path: root/pl_PL.ISO8859-2/articles/filtering-bridges/article.xml

<?xml version="1.0" encoding="iso-8859-2" standalone="no"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.5-Based Extension//EN"
	"../../../share/xml/freebsd45.dtd">

<!--
     The FreeBSD Polish Documentation Project

     $FreeBSD$
     Original revision: 1.12
-->

<article lang="pl">
  <articleinfo>
    <title>Mosty filtruj±ce</title>

    <authorgroup>
      <author>
        <firstname>Alex</firstname>
        <surname>Dupre</surname>
        <affiliation>
          <address><email>sysadmin@alexdupre.com</email></address>
        </affiliation>
      </author>
    </authorgroup>

    <pubdate>$FreeBSD$</pubdate>

    <releaseinfo>$FreeBSD$</releaseinfo>

    <abstract>
      <para>Czêstokroæ zdarza siê, ¿e trzeba podzieliæ jedn± sieæ fizyczn±
        (np. Ethernet) na dwa oddzielne segmenty, nie tworz±c przy tym
	podsieci, a oba segmenty po³±czyæ ze sob± ruterem. Urz±dzenie
	³±cz±ce w ten sposób dwie sieci nazywane jest mostem. Komputer z
	FreeBSD posiadaj±cy dwa interfejsy sieciowe mo¿e z powodzeniem
	pracowaæ jako most.</para>

      <para>Zadaniem mostu jest analizowanie adresów <acronym>MAC</acronym>
        (adresów ethernetowych) nale¿±cych do urz±dzeñ przy³±czonych do obu
	interefejsów sieciowych, a nastêpnie przekazywaniu danych pomiêdzy
	obiema sieciami tylko wtedy, gdy nadawca i odbiorca nale¿± do
	innych segmentów. Pod wieloma wzglêdami most przypomina prze³±cznik
	ethernetowy wyposa¿ony w jedynie dwa porty.</para>
    </abstract>
  </articleinfo>

  <sect1 id="filtering-bridges-why">
    <title>Dlaczego korzysta siê z mostów filtruj±cych?</title>

    <para>Dziêki obni¿aj±cym siê kosztom szerokopasmowych po³±czeñ
      internetowych (xDSL), jak równie¿ z powodu niewielkiej liczby dostêpnych
      adresów IPv4, coraz czê¶ciej zdarza siê, ¿e firmy dysponuj± sta³ym
      po³±czeniem z Internetem, nie posiadaj±c przy tym zbyt wielu adresów IP.
      W takiej sytuacji przydatne jest stosowanie firewalla filtruj±cego
      pakiety wysy³ane do Internetu i z niego nadchodz±ce. Mo¿e siê jednak
      zdarzyæ, ¿e filtrowania pakietów na poziomie rutera nie da siê
      zrealizowaæ, na przyk³ad ze wzglêdu na podzia³ sieci,
      lub dlatego, ¿e to dostawca us³ug interentowych jest w³a¶cicielem
      rutera, b±d¼ te¿ sam ruter nie umo¿liwia takiego rozwi±zania. Wtedy
      w³a¶nie wskazane jest skorzystanie z mostu filtruj±cego.</para>

    <para>Firewall bêd±cy jednocze¶nie mostem mo¿e byæ wstawiony pomiêdzy
      ruter xDSL a koncentrator/prze³±cznik ethernetowy. Jego konfiguracja
      nie wymaga zajmowania siê numeracj± IP.</para>
  </sect1>

  <sect1 id="filtering-bridges-how">
    <title>Instalacja</title>

    <para>W FreeBSD w³±czenie funkcji mostu nie jest trudnym przedsiêwziêciem.
      Pocz±wszy od wydania 4.5 owe funkcje mog± byæ do³±czone jako modu³y, nie
      trzeba wiêc przebudowywaæ j±dra, co jest znacznym udogodnieniem.
      Poni¿ej opisujê obydwa sposoby.</para>

    <important>
      <para><emphasis>Nie nale¿y</emphasis> postêpowaæ wed³ug obu poni¿szych
        przepisów: skorzystanie z jednego z nich
	<emphasis>wyklucza</emphasis> korzystanie z drugiego. Wybór powinien
	zale¿eæ od w³asnych potrzeb i mo¿liwo¶ci.</para>
    </important>

    <para>Przed rozpoczêciem nale¿y upewniæ siê, ¿e dysponujemy przynajmniej
      dwiema kartami sieciowymi zdolnymi do pracy w trybie po¶redniczenia
      zarówno przy odbiorze, jak i nadawaniu; karty bêd± wysy³aæ pakiety
      opatrzone niekoniecznie ich w³asnymi adresami. Co wiêcej, by osi±gn±æ
      dobr± wydajno¶æ, powinny byæ to karty PCI obs³uguj±ce zarz±dzanie
      magistral±. Do takich nale¿± karty Intel EtherExpress Pro, a tak¿e
      karty 3Com z serii 3c9xx. Dla uproszczenia konfiguracji firewalla
      po¿ytecznym okazaæ siê mo¿e posiadanie kart dwóch ró¿nych producentów
      (korzystaj±cych z innych sterowników), by ³atwiej by³o odró¿niæ
      interfejs pod³±czony do rutera od interfejsu po³±czonego z sieci±
      wewnêtrzn±.</para>

    <sect2 id="filtering-bridges-kernel">
      <title>Konfigurowanie j±dra</title>

      <para>Pierwsza z metod jest starsza, lecz sprawdzona. Na pocz±tek
        nale¿y dodaæ nastêpuj±ce wiersze do pliku konfiguracyjnego
	j±dra:</para>

      <programlisting>options BRIDGE
options IPFIREWALL
options IPFIREWALL_VERBOSE</programlisting>

      <para>Pierwszy wiersz w³±cza do j±dra obs³ugê mostu, drugi obs³ugê
        firewalla, a trzeci funkcje rejestruj±ce firewalla.</para>

      <para>Teraz trzeba skompilowaæ i zainstalowaæ nowe j±dro. Szczegó³owy
        opis tych czynno¶ci znale¼æ mo¿na w Podrêczniku FreeBSD, w czê¶ci
	"<ulink
	  url="../../books/handbook/kernelconfig-building.html">Building
	and Installing a Custom Kernel</ulink>".</para>
    </sect2>

    <sect2 id="filtering-bridges-modules">
      <title>£adowanie modu³ów</title>

      <para>Ta metoda instalacji jest nowsza i prostsza, polega jedynie
        na dodaniu poni¿szego wiersza do
	<filename>/boot/loader.conf</filename>:</para>

      <programlisting>bridge_load="YES"</programlisting>

      <para>W efekcie podczas ³adowania systemu wraz z j±drem zostanie
        za³adowany modu³ <filename>bridge.ko</filename>. Nie trzeba dodawaæ
	analogicznego wiersza dla modu³u <filename>ipfw.ko</filename>, gdy¿
	zostanie on za³adowany automatycznie po wykonaniu czynno¶ci
	opisanych w nastêpnej czê¶ci.</para>
    </sect2>
  </sect1>

  <sect1 id="filtering-bridges-finalprep">
    <title>Przygotowanie do pracy</title>

    <para>Przed ponownym uruchomieniem systemu oraz za³adowaniem nowego j±dra
      lub modu³ów (w zale¿no¶ci od wybranej metody instalacji), trzeba
      jeszcze dokonaæ kilku zmian w pliku konfiguracyjnym
      <filename>/etc/rc.conf</filename>. Domy¶ln± regu³± firewalla jest
      zatrzymywanie wszystkich pakietów IP. Zaczniemy od skonfigurowania
      firewalla <option>otwartego</option>, by sprawdziæ jego dzia³anie przy
      wy³±czonym filtrowaniu (dziêki temu maszyna bêdzie mog³a utrzymaæ
      po³±czenie z sieci±, co jest niezbêdne w przypadku, gdy konfiguracja
      przeprowadzana jest poprzez sieæ).
      W pliku <filename>/etc/rc.conf</filename> nale¿y umie¶ciæ poni¿sze
      wpisy:</para>

    <programlisting>firewall_enable="YES"
firewall_type="open"
firewall_quiet="YES"
firewall_logging="YES"</programlisting>

    <para>Pierwszy wiersz powoduje uruchomienie firewalla (³adowany jest
      modu³ <filename>ipfw.ko</filename>, je¶li nie zosta³ wkompilowany do
      j±dra), w drugim ustawiany jest
      <option>otwarty</option> tryb jego pracy (zgodnie z opisem w
      <filename>/etc/rc.firewall</filename>). Nastêpny wiersz nakazuje nie
      pokazywaæ ³adowanych regu³, a w ostatnim w³±czane jest
      rejestrowanie.</para>

    <para>Interfejsy sieciowe s± najczê¶ciej skonfigurowane tak, ¿e tylko
      jedna z kart sieciowych ma przypisany adres IP, jednak¿e most dzia³a
      tak samo równie¿ wtedy, gdy adresy przypisane s± do obu kart lub nie s±
      przypisane do ¿adnej z nich. W tym ostatnim przypadku (brak IP) maszyna
      pe³ni±ca rolê mostu bêdzie jeszcze bardziej ukryta, gdy¿ nie bêdzie
      dostêpna z sieci; dostêp do niej mo¿liwy bêdzie poprzez konsolê lub
      trzeci interfejs sieciowy odseparowany od mostu. Niekiedy dostêp do
      sieci potrzebny jest programom uruchamianym podczas
      ³adowania systemu, na przyk³ad do okre¶lenia nazwy domeny. W takiej
      sytuacji adres IP nale¿y przydzieliæ interfejsowi zewnêtrznemu (czyli
      temu, który po³±czony jest z Internetem, gdzie znajduje siê serwer
      <acronym>DNS</acronym>), poniewa¿ most bêdzie uruchomiony dopiero w
      koñcowej fazie uruchamiania systemu. Oznacza to, ¿e interfejs
      <devicename>fxp0</devicename> (jak w przyk³adzie) musi byæ uwzglêdniony
      w sekcji ifconfig pliku <filename>/etc/rc.conf</filename>, w
      przeciwieñstwie do interfejsu <devicename>xl0</devicename>.
      Przydzielanie adresów IP obu kartom sieciowym nie ma raczej sensu,
      chyba, ¿e podczas uruchamiania systemu programy potrzebuj± dostêpu
      do obu segmentów sieci.</para>


    <para>Nale¿y mieæ na uwadze, ¿e w sieci IP opartej na Ethernecie dzia³aj±
      w rzeczywisto¶ci dwa protoko³y: jednym jest oczywi¶cie IP, drugim
      jest <acronym>ARP</acronym>. Zadaniem protoko³u <acronym>ARP</acronym>
      jest przekszta³cenie adresu IP stacji na jej adres ethernetowy (adres
      <acronym>MAC</acronym>). By mo¿liwa by³a komunikacja miêdzy dwoma
      stacjami znajduj±cymi siê po dwóch stronach mostu, pakiety
      <acronym>ARP</acronym> musz± byæ przekazywane przez most. Protokó³
      <acronym>ARP</acronym> nie jest sk³adnikiem warstwy IP, poniewa¿
      jest u¿ywany tylko wtedy, gdy IP dzia³a w sieci Ethernet. Filtrowanie
      pakietów przez firewall w FreeBSD dotyczy warstwy IP, wiêc pakiety
      innego typu (w tym tak¿e <acronym>ARP</acronym>) bêd± przekazywane
      dalej bez filtrowania, nawet je¶li konfiguracja firewalla nakazuje
      blokowanie wszystkiego.</para>

    <para>Mo¿na ju¿ uruchomiæ system ponownie i korzystaæ z niego jak
      dotychczas. Pojawi± siê nowe komunikaty dotycz±ce mostu i firewalla,
      most jednak nie bêdzie jeszcze pracowaæ, natomiast firewall bêdzie
      dzia³aæ w trybie <option>otwartym</option>, bez jakiegokolwiek
      blokowania.</para>

    <para>Je¶li pojawi± siê jakiekolwiek problemy, nale¿y siê z nimi
      uporaæ przed przyst±pieniem do kolejnego etapu pracy.</para>
  </sect1>

  <sect1 id="filtering-bridges-enabling">
    <title>Uruchamianie mostu</title>

    <para>Uruchomienie mostu polega na wykonaniu nastêpuj±cej sekwencji
      poleceñ (nazwy przyk³adowych interfejsów sieciowych
      <devicename>fxp0</devicename> i <devicename>xl0</devicename> nale¿y
      zast±piæ nazwami w³asnych interfejsów):</para>

    <screen>&prompt.root; <userinput>sysctl net.link.ether.bridge_cfg=fxp0:0,xl0:0</userinput>
&prompt.root; <userinput>sysctl net.link.ether.bridge_ipfw=1</userinput>
&prompt.root; <userinput>sysctl net.link.ether.bridge=1</userinput></screen>

    <para>Pierwsze polecenie wskazuje interfejsy obs³ugiwane przez most,
      drugie w³±cza firewalla, wreszcie trzecie polecenie w³±cza sam
      most.</para>

    <para>Tak skonfigurowana maszyna mo¿e zostaæ w³±czona miêdzy dwie grupy
      po³±czonych w sieæ komputerów bez zak³ócania ich wzajemnej komunikacji.
      Je¶li to siê powiedzie, mo¿na dodaæ do pliku
      <filename>/etc/sysctl.conf</filename> wpisy
      <literal>net.link.ether.<replaceable>[co¶]</replaceable>=<replaceable>[co¶]</replaceable></literal>
      zgodne z powy¿szymi, by zosta³y uwzglêdnione przy ³adowaniu systemu.</para>
  </sect1>

  <sect1 id="filtering-bridges-ipfirewall">
    <title>Konfiguracja firewalla</title>

    <para>Nastêpnym krokiem jest przygotowanie regu³ firewalla,
      zabezpieczaj±cych sieæ wewnêtrzn±. Wi±¿e siê to z pewnymi utrudnieniami,
      gdy¿ nie wszystkie mo¿liwo¶ci firewalla mog± byæ wykorzystywane w
      przypadku pakietów przechodz±cych przez most. Trzeba te¿ wiedzieæ, ¿e
      miêdzy pakietami przekazywanymi, a odbieranymi przez maszynê lokaln±
      jest pewna ró¿nica. Pakiety przychodz±ce przechodz± przez firewall
      tylko raz, a nie dwa razy jak w zwyk³ych warunkach. Mówi±c dok³adniej,
      s± one filtrowane tylko przy odbiorze, tak wiêc regu³y zawieraj±ce
      <option>out</option> lub <option>xmit</option> bêd± bezu¿yteczne.
      Ja osobi¶cie u¿ywam starszej sk³adni <option>in via</option>, któr±
      rozs±dniej siê czyta. Trzeba równie¿ pamiêtaæ, ¿e filtruj±c pakiety
      przechodz±ce przez most, mo¿na u¿ywaæ tylko poleceñ
      <option>pass</option> lub <option>drop</option>. Bardziej wymy¶lne
      polecenia, jak <option>divert</option>, <option>forward</option> czy
      <option>reject</option> s± niedozwolone. Mo¿na z nich korzystaæ tylko
      w odniesieniu do pakietów wysy³anych przez maszynê mostu lub do niej
      przychodz±cych (je¶li oczywi¶cie ma ona adres IP).</para>

    <para>Nowo¶ci± w FreeBSD 4.0 jest filtrowanie z utrzymywaniem stanu. Jest
      ono znacznym u³atwieniem obs³ugi komunikacji przez
      <acronym>UDP</acronym>, polegaj±cej najczê¶ciej na wys³aniu ¿±dania, a
      za chwilê odebraniu odpowiedzi, z takimi samymi adresami IP i numerami
      portów (przy czym nadawca i odbiorca s± oczywi¶cie zamienieni
      miejscami). Praktycznie nie da siê potraktowaæ takiej wymiany jako
      pojedynczej sesji,
      pos³uguj±c siê firewallem nie przechowuj±cym informacji o stanie
      po³±czenia. Jednak¿e gdy firewall potrafi <quote>zapamiêtaæ</quote>
      wychodz±cy pakiet <acronym>UDP</acronym> i zezwoliæ na odpowied¼ w
      ci±gu kilku nastêpnych minut, wówczas zarz±dzanie komunikacj±
      <acronym>UDP</acronym> staje siê dziecinnie proste. Jak to zrobiæ,
      pokazuje poni¿szy przyk³ad. Podobnie mo¿na traktowaæ pakiety
      <acronym>TCP</acronym>, chroni to przed niektórymi atakami przez
      uniemo¿liwienie dzia³ania oraz innymi figlami, prowadzi jednak do
      szybkiego rozrastania siê tablicy stanów.</para>


    <para>Spójrzmy na przyk³adow± konfiguracjê. Zwróæmy uwagê, ¿e na pocz±tku
      pliku <filename>/etc/rc.firewall</filename> umieszczono domy¶lne regu³y
      dla interfejsu pseudosieci <devicename>lo0</devicename>, nie trzeba
      siê wiêc ju¿ nimi przejmowaæ. Inne regu³y powinny byæ umieszczone w
      oddzielnym pliku (np. <filename>/etc/rc.firewall.local</filename>),
      który by³by do³±czany podczas ³adowania systemu dziêki zmianie
      w pliku <filename>/etc/rc.conf</filename> tego wiersza, w którym
      typ firewalla by³ zdefiniowany jako <option>otwarty</option>:</para>

    <programlisting>firewall_type="/etc/rc.firewall.local"</programlisting>

    <important>
      <para>Nale¿y tu podaæ <emphasis>pe³n±</emphasis> ¶cie¿kê, w przeciwnym
        razie plik nie zostanie za³adowany, co grozi utrat± dostêpu do
	sieci.</para>
    </important>

    <para>Na potrzeby przyk³adu przyjmujemy, ¿e interfejs
      <devicename>fxp0</devicename> po³±czony jest z Internetem, natomiast
      <devicename>xl0</devicename> z sieci± wewnêtrzn±
      (<acronym>LAN</acronym>). Adres IP maszyny mostu to
      <hostid role="ipaddr">1.2.3.4</hostid> (w rzeczywisto¶ci dostawca
      us³ug interenetowych nie móg³by przydzieliæ adresu klasy A, jednak
      ¶wietnie nadaje siê on jako przyk³ad).</para>

    <programlisting># Szybkie przepuszczanie pakietów, których stan zosta³ zapamiêtany
add check-state

# Blokada sieci z RFC 1918
add drop all from 10.0.0.0/8 to any in via fxp0
add drop all from 172.16.0.0/12 to any in via fxp0
add drop all from 192.168.0.0/16 to any in via fxp0

# Maszyna bêd±ca mostem mo¿e wysy³aæ co tylko zechce
# (je¶li maszyna nie ma adresu IP, pomiñ poni¿sze wiersze)
add pass tcp from 1.2.3.4 to any setup keep-state
add pass udp from 1.2.3.4 to any keep-state
add pass ip from 1.2.3.4 to any

# Stacje sieci wewnêtrznej mog± wysy³aæ co tylko zechc±
add pass tcp from any to any in via xl0 setup keep-state
add pass udp from any to any in via xl0 keep-state
add pass ip from any to any in via xl0

# Protokó³ TCP
# Przepuszczanie SSH
add pass tcp from any to any 22 in via fxp0 setup keep-state
# Przepuszczanie SMTP jedynie do serwera poczty
add pass tcp from any to relay 25 in via fxp0 setup keep-state
# Informacje o obszarach mog± byæ przesy³ane tylko przez podrzêdny
# serwer nazw [dns2.nic.it]
add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state
# Przepuszczanie zapytañ ident - takie rozwi±zanie jest lepsze
# ni¿ oczekiwanie na przekroczenie czasu
add pass tcp from any to any 113 in via fxp0 setup keep-state
# Przepuszczenie zakresu portów dynamicznych
add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state

# Protokó³ UDP
# Przepuszczanie zapytañ DNS jedynie do serwera DNS
add pass udp from any to ns 53 in via fxp0 keep-state
# Przepuszczenie zakresu portów dynamicznych
add pass udp from any to any 49152-65535 in via fxp0 keep-state

# Protokó³ ICMP
# Przepuszczanie 'pingów'
add pass icmp from any to any icmptypes 8 keep-state
# Przepuszczanie komunikatów o b³êdach generowanych przez 'traceroute'
add pass icmp from any to any icmptypes 3
add pass icmp from any to any icmptypes 11

# Wszystko inne jest podejrzane
add drop log all from any to any</programlisting>

    <para>Czytelnicy maj±cy ju¿ do¶wiadczenie z konfiguracj± firewalla mog±
      zwróciæ uwagê na brak pewnych rzeczy. W szczególno¶ci, brakuje regu³
      zapobiegaj±cych podszywaniu siê. Rzeczywi¶cie, w¶ród powy¿szych regu³
      <emphasis>nie by³o</emphasis> takiej:</para>

    <programlisting>add deny all from 1.2.3.4/8 to any in via fxp0</programlisting>

    <para>Nakazuje ona odrzucanie pakietów, które nadchodz± z zewn±trz, a
      udaj±, ¿e s± z sieci wewnêtrznej. Jest to zwykle stosowane w celu
      zabezpieczenia siê przed próbami prze¶lizniêcia siê przez filtrowanie,
      polegaj±cymi na tworzeniu fa³szywych pakietów, wygl±daj±cych jak
      wys³ane z sieci wewnêtrznej. K³opot w tym, ¿e jest
      <emphasis>co najmniej</emphasis> jedna stacja po³±czona z interfejsem
      zewnêtrznym, której nie mo¿na zignorowaæ: jest ni± ruter. Zwykle
      jednak ochrona przed podszywaniem siê realizowana jest przez
      dostawcê us³ug internetowych na jego ruterze, nie trzeba siê wiêc
      tym przejmowaæ.</para>

    <para>Ostatnia regu³a jest bardzo podobna do regu³y przyjmowanej
      domy¶lnie, czyli odrzucania wszystkiego, co nie jest ¶ci¶le dozwolone.
      Jest jednak ró¿nica: wszystko, co jest podejrzane, jest
      rejestrowane.</para>

    <para>Dwie regu³y odpowiedzialne s± za przekazywanie pakietów
      <acronym>SMTP</acronym> i <acronym>DNS</acronym> do serwera poczty i
      serwera nazw, o ile takowe serwery s±. Zestaw regu³ powinien byæ
      oczywi¶cie dostosowany do w³asnych potrzeb, tutaj pokazany jest tylko
      pewien przyk³ad (sk³adnia regu³ jest dok³adnie opisana w dokumentacji
      systemowej &man.ipfw.8;). Trzeba mieæ na uwadze, ¿e aby poprawnie
      dzia³a³y
      <quote>relay</quote> i <quote>ns</quote>, wymagane jest, by zapytania
      DNS dzia³a³y <emphasis>zanim</emphasis> pracê rozpoczyna most. Dziêki
      temu mo¿na te¿ siê przekonaæ, czy adres IP zosta³ przypisany do
      w³a¶ciwiej karty sieciowej. Alternatywnym rozwi±zaniem jest
      wpisanie adresu IP zamiast nazwy stacji (jest to jedyna mo¿liwo¶æ
      w przypadku, gdy maszyna nie ma adresu IP).</para>

    <para>Osoby, które ju¿ kiedy¶ mia³y pewne do¶wiadczenia z konfiguracj±
      firewalla, przyzwyczajone s± zapewne do regu³ <option>reset</option>
      lub <option>forward</option> dla pakietów ident (port
      <acronym>TCP</acronym> o numerze 113). Niestety, w przypadku mostu
      takie rozwi±zanie nie wchodzi w grê, najlepiej jest po prostu
      przepu¶ciæ owe pakiety do ich adresata. Jest to stosunkowo niegro¼ne,
      gdy adresat ma wy³±czon± us³ugê ident. Mo¿na tak¿e blokowaæ po³±czenia
      z portem 113, co powoduje pewne problemy np. z us³ug±
      <acronym>IRC</acronym> (poniewa¿ zapytanie ident musi przekroczyæ
      czas oczekiwania).</para>

    <para>Niezrozumia³a mo¿e wydaæ siê obecno¶æ oddzielnych regu³, z
      których jedne zezwalaja na wysy³anie maszynie bêd±cej mostem, drugie
      natomiast stacjom sieci wewnêtrznej. Jest tak dlatego, ¿e pakiety
      wysy³ane przez maszynê lokaln± docieraj± do filtra inn± drog± ni¿
      pakiety wys³ane z sieci wewnêtrznej. Te ostatnie musz± przej¶æ przez
      most, natomiast pakiety wys³ane lokalnie trafiaj± na stos IP maszyny.
      Osobne zestawy regu³ obs³uguj± obydwa przypadki. Z kolei regu³y
      zawieraj±ce <literal>in via <devicename>fxp0</devicename></literal>
      odnosz± siê do obu rodzajów pakietów. Mówi±c ogólnie, pisz±c regu³y
      <option>in via</option> trzeba zrobiæ wyj±tek dla pakietów wysy³anych
      z lokalnej maszyny, poniewa¿ one nie przysz³y przez ¿aden z
      interfejsów.</para>
  </sect1>

  <sect1 id="filtering-bridges-contributors">
    <title>Podziêkowania</title>

    <para>Du¿a czê¶æ niniejszego artyku³u zaczerpniêta zosta³a ze starego
      dokumentu o mostach autorstwa Nicka Sayera. Inspiracj± by³o równie¿
      wprowadzenie do tematyki mostów napisane przez Steve'a Petersona.</para>

    <para>Bardzo dziêkujê Luigiemu Rizzo za implementacjê kodu mostu w
      FreeBSD, jak równie¿ za czas po¶wiêcony na odpowiedzi na moje
      pytania.</para>

    <para>Dziêkujê te¿ Tomowi Rhodesowi, który zechcia³ przyjrzeæ siê
      mojemu t³umaczeniu tego artyku³u z w³oskiego (w takim jêzyku napisany
      by³ orygina³) na angielski.</para>
  </sect1>
</article>