![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Spis Treści] [Sekcja 5 - Tworzenie systemu ze źródeł] [Sekcja 7 - Ustawienia klawiatury i wyświetlania]
Dla zrozumienia większości z tego dokumentu, zalecane jest zapoznanie się i zrozumienie sekcji 5 FAQ konfiguracja i instalacja jądra, działania narzędzi ifconfig(8) oraz netstat(1) na podstawie odpowiadających im stron manuala.
Jeśli administrujesz siecią i zajmujesz się konfiguracją protokołów routingu używając do tego celu maszyny z OpenBSD jako rutera i chcesz zagłębić się bardziej w sieci IP, powinieneś przeczytać poniższy znakomity dokument Understanding IP Addressing. Dokument ten zawiera fundamentalne informacje na temat sieci IP, jest zwłaszcza przydatny, gdy opiekujesz się wieloma sieciami.
Jeśli zajmujesz się administrowaniem takimi usługami jak serwery www, ftp czy też poczty, możesz dowiedzieć się wielu interesujących rzeczy o ich działaniu czytając odpowiednie dokumenty RFC opisujące szczegółowo protokoły oraz działanie tych usług. Oczywiście nie przeczytasz ich wszystkich - zajmij się tymi, którymi jesteś najbardziej zainteresowany lub których używasz w swojej sieci. Dokumenty RFC definiują tysiące standardów opisujących protokoły sieciowe, ich działanie oraz sposób w jaki powinny zostać realizowane.
W OpenBSD, interfejsy sieciowe nazywane są one według typu sterownika a nie typu połączenia (jak ma to miejsce np. w Linuksie). Możesz zobaczyć w jaki sposób system wykrył Twoją kartę podczas procesu uruchamiania lub później korzystając z polecenia dmesg(8). Aktualną konfigurację interfejsów sieciowych możesz zobaczyć przy pomocy ifconfig(8). Dla przykładu, oto co wyświetlone zostało przez komendę dmesg w przypadku karty sieciowej Intel Fast Ethernet, używającej nazwy fxp.
fxp0 at pci0 dev 10 function 0 "Intel 82557" rev 0x0c: irq 5, address 00:02:b3:2b:10:f7
inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
Jeśli nie wiesz, jak nazywa się Twoje urządzenie sieciowe przejrzyj listę urządzeń wspieranych przez OpenBSD dla odpowiedniej platformy. Znajdziesz tam spis wielu popularnych kart sieciowych oraz odpowiedniki ich nazw w OpenBSD. Pełna nazwa urządzenia w systemie składa się z tego właśnie synonimu (jak fxp) oraz numeru przyznanego urządzeniu przez jądro systemu (np. fxp0). Numery są przyznawane na podstawie różnych kryteriów, zależnych od karty i innych szczegółów systemu. Niektóre karty określane są poprzez kolejność w jakiej zostały wykryte podczas skanowania magistrali. Inne mogą być numerowanie poprzez zasoby sprzętowe lub adres MAC.
Sprawdzenia jakie interfejsy sieciowe zostały zidentyfikowane przez system możesz dokonać korzystając z narzędzia ifconfig(8). Poniższa komenda wyświetli wszystkie interfejsy w systemie. W tym przykładzie widać tylko jeden fizyczny interfejs Ethernetowy fxp(4).
$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
lo1: flags=8008<LOOPBACK,MULTICAST> mtu 33224
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:04:ac:dd:39:6a
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255
inet6 fe80::204:acff:fedd:396a%fxp0 prefixlen 64 scopeid 0x1
pflog0: flags=0<> mtu 33224
pfsync0: flags=0<> mtu 2020
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
sl1: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
ppp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
tun0: flags=10<POINTOPOINT> mtu 3000
tun1: flags=10<POINTOPOINT> mtu 3000
enc0: flags=0<> mtu 1536
bridge0: flags=0<> mtu 1500
bridge1: flags=0<> mtu 1500
vlan0: flags=0<> mtu 1500
address: 00:00:00:00:00:00
vlan1: flags=0<> mtu 1500
address: 00:00:00:00:00:00
gre0: flags=9010<POINTOPOINT,LINK0,MULTICAST> mtu 1450
carp0: flags=0<> mtu 1500
carp1: flags=0<> mtu 1500
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif1: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif2: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif3: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
Jak widzisz, ifconfig(8) dostarcza nam wielu użytecznych w tym momencie informacji, między innymi widać tutaj interfejs, który w powyższym przykładzie jest już skonfigurowany. Oczywistym jest, że sieć IP dostępna jest poprzez interfejs fxp0, stąd wartości "inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255". Ponadto flagi UP i RUNNING są ustawione.
Oprócz fxp0 widoczne są również domyślnie udostępnione inne interfejsy. Są to urządzenia wirtualne pełniące w systemie rozmaite funkcje. Ich szczegółowy opis znajdziesz na stronach manuala:
Interfejs jest konfigurowany podczas startu systemu w oparciu o pliki /etc/hostname.if(5), gdzie if należy zastąpić pełną nazwą interfejsu, czyli w naszym przypadku - /etc/hostname.fxp0.
Format tego pliku jest prosty:
address_family address netmask broadcast [other options]
Typowy plik interfejsu sieciowego skonfigurowanego do współpracy z adresami IPv4 może wyglądać następująco:
$ cat /etc/hostname.fxp0
inet 10.0.0.38 255.255.255.0 NONE
W tym przypadku, zdefiniowaliśmy adres IPv4 (inet), z adresem IP 10.0.0.38, maska sieciową 255.255.255.0, bez określania adresu rozgłoszeniowego (który będzie w tym przypadku domyślnie ustawiony na 10.0.0.255).
Wprowadzając dodatkowe opcje możesz skonfigurować typ Ethernetu i dla przykładu: jeśli chcesz, aby karta pracowała w trybie 100baseTX full-duplex, plik konfiguracyjny będzie wyglądał następująco:
inet 10.0.0.38 255.255.255.0 NONE media 100baseTX mediaopt full-duplex
(Oczywiście nie powinieneś nigdy wymuszać trybu full duplex o ile oba końce połączenia nie są tak ustawione! Przy braku specjalnych wymagań, ustawienia trybu połączenia powinny być wyłączone. Bardzej prawdopodonym przypadkiem jest wymuszenie 10base-T lub half duplex gdy wymaga tego twoja infrastruktura sieciowa.)
Możesz zauważyć, że w przypadku konfigurowania różnych typów interfejsów i przypisywania im specyficznych dla nich opcji format pliku pozostaje niemal identyczny!
$ cat /etc/hostname.vlan0
inet 172.21.0.31 255.255.255.0 NONE vlan 2 vlandev fxp1
10.0.0.1
search example.com
nameserver 125.2.3.4
nameserver 125.2.3.5
lookup file bind
W prawie każdym systemie Unix (i wielu systemach nie-Uniksowych), plik /etc/hosts może być używany do określenia systemów które nie są wpisane w oficjalnym systemie DNS (lub w połączeniu z pokazanym powyżej priorytecie "lookup", nie są podane w porządany sposób).
Jeżeli korzystasz z DHCP, powinieneś przeczytać 6.4 - DHCP zwracając uwagę na resolv.conf.tail(5).
puffy.example.com
# sh /etc/netstart
writing to routing socket: File exists
add net 127: gateway 127.0.0.1: File exists
writing to routing socket: File exists
add net 224.0.0.0: gateway 127.0.0.1: File exists
Zauważ, że uruchomienie skryptu spowodowało wystąpienie kilku błędów. Jest to spowodowane zainicjalizowaniem rekonfiguracji systemu już skonfigurowanego. Dla przykładu, niektóre trasy routingu istniały już w tablicy rutingu jądra. Od tej chwili obsługa sieci w Twoim systemie powinna być już skonfigurowana. Aby upewnić się, że wszystkie interfejsy zostały skonfigurowane tak jak planowałeś posłuż się narzędziem ifconfig(8).
Nawet jeśli możesz całkowicie zrekonfigurować sieć na OpenBSD bez konieczności restartu, restart systemu jest WYSOCE zalecany przy każdej znaczącej zmianie konfiguracji. Spowodowane jest to różnicami pomiędzy środowiskiem podczas uruchamiania systemu oraz środowiskiem gdy system jest uruchomiony. Dla przykładu, jeżeli podałeś nazwę symboliczną resolvera DNS w swoich plikach konfiguracyjnych, twoja konfiguracja będzie działać zgodnie z założeniami po rekonfiguracji, jednak podczas startu systemu, twój zewnętrzny resolver może być niedostępny, zatem konfiguracja się nie powiedzie.
$ netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 10.0.0.1 UGS 0 86 - fxp0
127/8 127.0.0.1 UGRS 0 0 - lo0
127.0.0.1 127.0.0.1 UH 0 0 - lo0
10.0.0/24 link#1 UC 0 0 - fxp0
10.0.0.1 aa:0:4:0:81:d UHL 1 0 - fxp0
10.0.0.38 127.0.0.1 UGHS 0 0 - lo0
224/4 127.0.0.1 URS 0 0 - lo0
Encap:
Source Port Destination Port Proto SA(Address/SPI/Proto)
$ route show
Routing tables
Internet:
Destination Gateway Flags
default 10.0.0.1 UG
127.0.0.0 LOCALHOST UG
localhost LOCALHOST UH
10.0.0.0 link#1 U
10.0.0.1 aa:0:4:0:81:d UH
10.0.0.38 LOCALHOST UGH
BASE-ADDRESS.MCA LOCALHOST U
Poniżej zamieszczone są podstawowe informacje z którymi powinieneś zapoznać się, chcąc skonfigurować maszynę z OpenBSD jako bramkę (router). Jeśli komputer ma stanowić bramkę do Internetu, zalecane jest przeczytanie instrukcji dotyczących konfiguracji filtra pakietów (Packet Filter) aby móc blokować potencjalnie niebezpieczny ruch. Ponadto, biorąc pod uwagę niewielką przestrzeń adresów IPv4 przydzielaną przez dostawców usług internetowych możesz skorzystać z informacji o translacji adresów sieciowych (NAT - Network Address Translation), aby rozsądniej wykorzystać przyznaną Ci pulę adresów IP.
Standardowe (GENERIC) jądro ma możliwość przekazywania pakietów IP (IP Forwarding), do działania, wymaga ono jednak inicjalizacji. Powinieneś w tym celu skorzystać z sysctl(8). Aby maszyna zawsze startowała z włączonym przekazywaniem pakietów powinieneś wyedytować plik /etc/sysctl.conf. Jedyne co musisz zrobić, to dodać poniższą linijkę do tego pliku.
net.inet.ip.forwarding=1
Aby uzyskać ten efekt bez restartu maszyny, możesz skorzystać bezpośrednio z narzędzia sysctl(8). Pamiętaj, że po ponownym uruchomieniu komputera, zmiana ta nie będzie obowiązywać. Do wykonania poniższej komendy musisz mieć uprawnienia root'a.
# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1
Teraz jedyne co Ci pozostaje, to ustawienie tras routingu na hostach po obu stronach Twojego rutera. Istnieje wiele możliwości wykorzystania OpenBSD jako rutera korzystając z takich narzędzi jak stworzony dla OpenBSD OpenBGPD, routed(8), mrtd, zebra, i quagga. OpenBSD wspiera oprogramowanie takie jak zebra, gated czy mrtd poprzez system portów. OpenBGPD oraz routed są instalowane jako części systemu bazowego. Potrafi także współpracować z rozmaitymi interfejsami takimi jak T1, HSSI, ATM, FDDI, Ethernet oraz połączeniami poprzez linie szeregowe (PPP/SLIP).
OpenBSD posiada prosty mechanizm nadawania aliasów IP interfejsom. Jedyne co musisz zrobić, to odpowiednio wyedytować plik /etc/hostname.<if>. Plik ten, z informacjami o konfiguracji interfejsu, jest czytany w momencie uruchamiania się systemu przez skrypt /etc/netstart(8), który jest elementem procedury startowej (rc startup hierarchy). Dla przykładu zakładamy, że użytkownik posiada interfejs dc0 i znajduje się w sieci 192.168.0.0. Pozostałe istotne informacje:
Kilka uwag na temat aliasów. W OpenBSD używasz tylko jednej nazwy interfejsu. Nie ma w tym przypadku żadnej różnicy pomiędzy pomiędzy pierwszym a drugim aliasem. W przeciwieństwie do innych systemów operacyjnych OpenBSD nie odnosi się do kolejnych aliasów, kolejno je numerując, jak np.: dc0:0, dc0:1. Jeśli odnosisz się do konkretnego 'aliasowanego' adresu IP poprzez ifconfig, lub dodajesz alias, bądź uważny i pamiętaj o składni "ifconfig int alias" zamiast "ifconfig int". Dowolny alias możesz usunąć poleceniem "ifconfig int delete".
Zakładając, że używasz wielu adresów IP, które należą do tej samej podsieci jako aliasy, maska sieciowa dla każdego z nich przyjmuje wartość 255.255.255.255. Nie musisz powielać w każdym przypadku maski pierwszego adresu IP przypisanego do interfejsu. W poniższym przykładzie, plik /etc/hostname.dc0, zawiera definicje dwóch aliasów do interfejsu dc0 skonfigurowanego początkowo jako 192.168.0.2 z maską 255.255.255.0.
# cat /etc/hostname.dc0
inet 192.168.0.2 255.255.255.0 media 100baseTX
inet alias 192.168.0.3 255.255.255.255
inet alias 192.168.0.4 255.255.255.255
Po wyedytowaniu pliku, jedyne co musisz zrobić, aby wprowadzić powyższe zmiany w konfiguracji, to uruchomić ponownie komputer. Naturalnie, możesz także nadać aliasy ręcznie, bez potrzeby restartowania systemu, używając narzędzia ifconfig(8). Do uaktywnienia pierwszego aliasu z powyższego przykładu powinieneś posłużyć się komendą:
# ifconfig dc0 inet alias 192.168.0.3 netmask 255.255.255.255
Do wyświetlenia aliasów skorzystaj z polecenia:
$ ifconfig -A
dc0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
media: Ethernet manual
inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
inet 192.168.0.3 netmask 0xffffffff broadcast 192.168.0.3
Aby skorzystać z klienta DHCP dhclient(8) dołączonego standardowo do OpenBSD, wyedytuj plik /etc/hostname.xl0 (zakładając że twoim głównym interfejsem Ethernetowym jest xl0. W rzeczywistości może to być ep0 lub fxp0, lub coś zupełnie innego). Wszystko co musisz zrobić to wpisać do tego pliku 'dhcp':
# echo dhcp >/etc/hostname.xl0
Dzięki temu OpenBSD automatycznie uruchomi klienta DHCP przy starcie dla wskazanego interfejsu. Pobrany zostanie adres IP, domyślna bramka, oraz serwery DNS.
Jeśli chcesz skonfigurować swój interfejs poprzez DHCP z linii poleceń, upewnij się, że masz plik /etc/dhclient.conf, a następnie wykonaj:
# dhclient fxp0
Gdzie fxp0 jest interfejsem na który chcesz otrzymać DHCP.
Nieważne w jaki sposób uruchamiasz klienta DHCP, zawsze możesz wyedytować /etc/dhclient.conf aby np. nie uaktualniać swojej konfiguracji serwerów DNS poprzez odkomentowanie linii 'request' (poniżej znajdziesz przykładowe domyślne opcje, które musisz odkomentować i dokonać spośród nich wyboru.)
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;
a następnie usunąć domain-name-servers. Oczywiście możesz także usnąć hostname lub pozostałe ustawienia.
Poprzez zmianę opcji w twoim pliku dhclient.conf(5), możesz przekazać klientowi DHCP jak stworzyć twój plik resolv.conf(5). Klient DHCP nadpisze wszystkie informacje jakie już miałeś wpisane do resolv.conf(5), informacjami uzyskanymi z serwera DHCP. Stracisz zatem wszystkie informacje które wprowadziłeś do resolv.conf.
Dostępne są dwa mechanizmy pozwalające temu zapobiec:
W poniższym przykładzie chcesz użyć DHCP, ale zamierzasz dodać lookup file bind do swojego pliku resolv.conf(5) tworzonego przez dhclient(8). Nie ma opcji pozwalającej na to w dhclient.conf, musisz zatem użyć resolv.conf.tail:
# echo "lookup file bind" > /etc/resolv.conf.tail
nameserver 192.168.1.1
nameserver 192.168.1.2
lookup file bind
Jeśli chcesz aby Twój OpenBSD pracował w sieci jako serwer DHCP
dhcpd(8),
wyedytuj /etc/rc.conf.local poprzez ustawienie dhcpd_flags="".
Umieść nazwę interfejsu, na którym serwer ma nasłuchiwać w pliku
/etc/dhcpd.interfaces.
# echo xl1 xl2 xl3 >/etc/dhcpd.interfaces
A następnie zabierz się za konfigurację serwera poprzez plik /etc/dhcpd.conf.
Znaczenie poniższych opcji jest chyba jasne.
option domain-name "example.com";
option domain-name-servers 192.168.1.3, 192.168.1.5;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
range 192.168.1.32 192.168.1.127;
}
Twój serwer DHCP powie klientowi, że należy do domeny "example.com" oraz że serwery DNS dla tej domeny to 192.168.1.3 i 192.168.1.5. Hosty znajdujące się w tej samej sieci co adres interfejsu Ethernetowego OpenBSD, na którym nasłuchuje DHCP należący do sieci 192.168.1.0/24 otrzymają adresy z zakresu 192.168.1.32 - 192.168.1.127. Otrzymają też informację, aby jako domyślną bramę wykorzystywały host 192.168.1.1.
Jeśli chcesz uruchomić dhcpd(8) z linii komend po edycji
/etc/dhcpd.conf, użyj:
# touch /var/db/dhcpd.leases
# dhcpd fxp0
Linia zaczynająca się poleceniem touch jest niezbędna i służy do utworzenia pustego pliku dhcpd.leases zanim będzie można uruchomić serwer dhcpd(8). Skrypty startowe OpenBSD utworzą ten plik jeśli nie będzie on istniał podczas startu systemu, jednak uruchamiając dhcpd(8) ręcznie niezbędne jest stworzenie tego pliku samodzielnie. fxp0 jest interfejsem na którym serwer DHCP będzie nasłuchiwać.
Jeśli udostępniasz usługę DHCP klientowi Windows, możesz chcieć aby
dhcpd(8) podał temu klientowi adres serwera 'WINS'. Wystarczy dodać analogiczną
do poniższej linijkę do /etc/dhcpd.conf:
option netbios-name-servers 192.168.92.55;
(gdzie zamiast 192.168.92.55 powinieneś wstawić swój adres IP serwera Windows lub Samba.) Zobacz dhcp-options(5), aby dowiedzieć się jakie inne informacje możesz dostarczyć klientom.
Protokół Punkt-do-Punktu (Point-to-Point Protocol - PPP) najczęściej wykorzystywany jest w przypadkach, gdy łączysz się ze swoim dostawcą Internetu poprzez modem. W OpenBSD możesz to zrobić na dwa sposoby poprzez:
Narzędzia ppp i pppd oferują podobna funkcjonalność jednak różnymi sposobami. pppd pracuje ze sterownikiem ppp(4) w jądrze podczas gdy ppp działa w przestrzeni użytkownika z tun(4). Dokument ten opisuje tylko demona PPP pracującego w przestrzeni użytkownika, ponieważ jest on prostszy w debagowaniu oraz w konfiguracji. Zaczniemy od konfiguracji demona PPP, który będzie mógł być uruchamiany przez zwykłych użytkowników. Aby rozpocząć potrzebujesz trochę informacji od swojego dostawcy. Oto lista rzeczy, które powinieneś wiedzieć, nim przystąpimy do pracy:
Bez części z nich możesz się obejść, ale wygodniej będzie jeśli będziesz dysponował powyższymi informacjami. Demon PPP pracujący w przestrzeni użytkownika korzysta z pliku konfiguracyjnego /etc/ppp/ppp.conf. W katalogu /etc/ppp znajdziesz kilka pomocnych plików, które mogą definiować różne konfiguracje dla różnych specyficznych sytuacji. Zalecane jest, abyś się z nimi zapoznał.
Podstawowa konfiguracja działającego w przestrzeni użytkownika demona PPP polega na edycji pliku /etc/ppp/ppp.conf. Domyślnie tego pliku nie ma w Twoim systemie, ale znajduje się plik /etc/ppp/ppp.conf.sample, z którego możesz skorzystać tworząc swój plik ppp.conf. Poniżej opisana zostanie najbardziej podstawowa i typowa konfiguracja. Oto przykładowy plik ppp.conf, który definiuje kilka domyślnych ustawień:
default:
set log Phase Chat LCP IPCP CCP tun command
set device /dev/cua01
set speed 115200
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
Sekcja poniżej default: będzie przetwarzana przy każdym uruchomieniu demona. Umieszczamy w niej wszystkie niezbędne informacje. Korzystając z "set log" konfigurujemy poziomy logowania. Możesz zmienić te ustawienia, aby dowiedzieć się więcej na temat ustawienia poziomów logowania zajrzyj do ppp(8). Wyboru urządzenia, pod którym jest nasz modem dokonujemy w sekcji "set device", w tym przypadku modem podłączony jest do drugiego portu szeregowego, port pierwszy to urządzenie /dev/cua00. Korzystając z "set speed" ustalamy prędkość połączenia, a w "set dial" podajemy parametry naszego połączenia. Można zdefiniować w tym miejscu inny 'timeout' dla naszego połączenia itp. Podana linijka jest dość dobra i raczej nie wymaga zmian.
Teraz możemy przejść do sekcji w których podamy informacje specyficzne dla dostawcy Internetu (ISP). Informacje te podajemy w sekcjach umiejscowionych poniżej nagłówka default:. Nagłówek nowej sekcji może mieć dowolny tytuł, np. nazwę Twojego ISP. Tutaj skorzystamy z nazwy myisp:, poniżej tego nagłówka znajdziesz wszystkie informacje niezbędne do tego, aby połączenie zostało poprawnie zainicjowane:
myisp:
set phone 1234567
set login "ABORT NO\\sCARRIER TIMEOUT 5 ogin:--ogin: ppp word: ppp"
set timeout 120
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
add default HISADDR
enable dns
Oto podstawowa konfiguracja potrzebna do tego, aby połączyć się z konkretnym ISP. Opcja "set phone" ustala numer dial-up naszego ISP. Kolejna, "set login", pozwala na wprowadzenie opcji niezbędnych do poprawnego zalogowania się. Umieściliśmy tutaj timeout na 5 sekund, co oznacza, że nasza próba zalogowania się zostanie przerwana po 5 sekundach bez sygnału połączenia. W innym przypadku będziemy czekać na "login:" oraz wysłane zostanie Twoja nazwa użytkownika oraz hasło.
W powyższym przypadku nazwa użytkownika (Username) = ppp oraz hasło (Password) = ppp. Te wartości będziesz musiał zmienić ("od tłumacza: chyba że korzystasz z usług TPSA"). Wiersz "set timeout" ustala "jałowy" (idle) czas dla całego połączenia na 120 sekund. Opcja "set ifaddr" wymaga dłuższego wyjaśnienia.
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
W powyższej linii korzystamy z ustawienia adresu w formacie "set ifaddr [myaddr[/nn] [hisaddr[/nn] [netmask [triggeraddr]]]]". Czyli pierwszym adresem IP jest ten, jaki chcemy aby został nam przypisany. Jeśli dostajesz statyczny adres od swojego ISP powinieneś umieścić go właśnie tutaj. W tym przykładzie dodaliśmy /0, aby zaznaczyć, że żaden z bitów tego adresu nie wymaga dopasowania i może on zostać całkowicie zmieniony przez ISP podczas transakcji rozpoczynającej połączenie. Drugi adres IP to adres IP dostawcy. Jeśli go znasz, umieść go właśnie w tym miejscu, jeśli nie zrób tak, jak w naszym przypadku - umieść na końcu /0. Trzecia opcja to nasza maska sieciowa, w tym przypadku ustawiona na 255.255.255.0. Jeśli triggeraddr jest ustawiony, używany jest do zastąpienia myaddr podczas rozpoczęcia negocjacji IPCP. Jakkolwiek tylko adres z zakresu myaddr zostanie zaakceptowany. Ta opcja użyteczna jest w przypadkach, gdy niektóre implementacje PPP podczas negocjacji połączenia nie przyznają adresu IP dopóki nie zażądasz ``0.0.0.0.0''.
Następna opcja "add default HISADDR" ustala domyślną trasę routingu na adres ISP. Dzięki takiemu wpisowi jesteś uniezależniony od adresu IP Twojego dostawcy - za każdym razem będzie on automatycznie uaktualniony w przypadku zmiany. Dzięki opcji "enable dns" mówimy naszemu ISP aby 'zalegalizował' adresy naszych serwerów nazw. UWAGA: nie rób tego jeśli masz uruchomiony lokalny serwer DNS, ponieważ ppp obejdzie to poprzez dopisanie kilku linijek nameserver w pliku /etc/resolv.conf.
Zamiast tradycyjnych metod logowania, wielu ISP używa obecnie autoryzacji CHAP lub PAP. Jeżeli tak jest w naszym przypadku, nasz plik konfiguracyjny będzie wygladał nieco inaczej:
myisp:
set phone 1234567
set authname ppp
set authkey ppp
set login
set timeout 120
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
add default HISADDR
enable dns
W powyższym przykładzie, podaliśmy nazwę użytkownika (ppp) oraz hasło (ppp) korzystając odpowiednio z authname i authkey. Nie ma potrzeby podawać czy chodzi o autoryzację CHAP lub PAP - zostanie to wynegocjowane automatycznie. Opcja "set login" jedynie określa próbę zalogowania się, z nazwą użytkownika i hasłem podanym wcześniej.
Mamy wreszcie nasz plik ppp.conf z konfiguracją połączenia, teraz możemy spróbować połączyć się z naszym ISP. Opisanych zostanie kilka najczęściej używanych parametrów ppp:
Jeżeli powyższe próby nie powiodą się, spróbuj uruchomić /usr/sbin/ppp nie podając żadnych opcji - uruchomi się ppp w trybie interaktywnym. Możesz podawać opcje jedna po drugiej sprawdzając gdzie występują błędy lub inne problemy. Stosując konfigurację opisaną powyżej, ppp będzie logowało do pliku /var/log/ppp.log. Log ten, podobnie jak strona manuala, zawiera wszystkie pomocne informacje.
W niektórych sytuacjach może zajść potrzeba wykonania jakiejś czynności w momencie, gdy połączenie zostaje utracone lub nawiązane. Do tego typu zadań wykorzystuje się dwa pliki: /etc/ppp/ppp.linkup i /etc/ppp/ppp.linkdown. Przykładowe konfiguracje znajdziesz poniżej:
Bardzo wielu ISP oferuje obecnie usługi xDSL, znacznie szybsze niż tradycyjne metody dial-up. Opiszemy odmiany PPP takie jak ADSL i SDSL. Chociaż nie następuje fizyczne wdzwanianie, połączenia wciąż oparte są na protokole Point to Point. Załączone przykłady:
Point to Point Protocol over Ethernet (PPPoE) pozwala na przesyłanie pakietów PPP w ramkach ethernetowych. Point to Point Protocol over ATM (PPPoA) działa w sieciach ATM, takich jak te zbudowane w Wielkiej Brytanii i Belgii.
Oznacza to, że możesz nawiązać połącznie z twoim ISP korzystając tylko ze standardowej karty sieciowej i ethernetowego modemu DSL (w przeciwieństwie do modemów USB).
Jeżeli posiadasz modem który rozumie PPPoE/PPPoA, możliwe jest skonfigurowanie modemu do nawiązywania połączeń. Alternatywnie, jeżeli modem posiada funkcję bridge'a, możliwe jest jego włączenie i ustawienie modemu do przepuszczania pakietów na maszynę z uruchomionym PPPoE (patrz poniżej).
Podstawowym oprogramowaniem do PPPoE/PPPoA w OpenBSD jest pppoe(8), który jest implementacją pracującą w przestrzeni użytkownika (w taki sam sposób jak opisany wcześniej ppp(8)). Implementacja PPPoE pracująca w przestrzeni jądra, pppoe(4), została dodana do OpenBSD.
Point to Point Tunneling Protocol (PPTP) jest prawnie zastrzeżonym protokołem Microsoft'u. Klient pptp dostępny jest poprzez interfejsy z pppd(8) i może połączyć się do opartych o PPTP wirtualnych sieci prywatnych (VPN) używanych przez dostawców kablowych i xDSL. Sam pptp musi być instalowany z pakietów lub partów. Dodatkowe informacje o konfiguracji i użyciu pptp są dostępne na stronie manuala, który instaluje się razem z pakietem pptp.
Zmiana tych standardowych ustawień może być pomocna w przypadku problemów z połączeniem i routingiem. Oczywiście, aby zmiany te działały efektywnie powinny z nich korzystać obie strony połączenia.
Do zmiany tych wartości użyj sysctl i powiększ wartości:
net.inet.tcp.keepinittime
net.inet.tcp.keepidle
net.inet.tcp.keepintvl
Korzystając z sysctl -a, możesz obejrzeć aktualne ustawienia tych (i wielu innych) parametrów jądra. Aby zmienić jeden z nich, skorzystaj z sysctl net.inet.tcp.keepidle=28800.
W normalnej sytuacji nie powinieneś tego robić. Zezwala to bowiem komuś na wysłanie pakietów pod adres(y) broadcast Twoich sieci w przypadku, gdy używasz OpenBSD jako routera.
Istnieje kilka przypadków w zamkniętych sieciach gdy, może być to użyteczne, zwłaszcza korzystając ze starszych implementacji protokołu NetBIOS. Wykorzystujemy do tego celu kolejny sysctl: sysctl net.inet.ip.directed-broadcast=1. Jeśli chcesz wiedzieć dlaczego domyślnie jest ta opcja wyłączona poczytaj o atakach typu smurf.
Także do tej konfiguracji służy sysctl. Czytając w
sysctl(8):
Decydowanie o liście zarezerwowanych portów TCP, które nie powinny być
alokowane przez jądro dynamicznie. Możesz wykorzystać tę opcję, aby
nie zezwalać demonom na "podkradanie" portów, z których korzystają
inne programy. Elementy listy oddzielony mogą być przecinkami i/lub
znakami białymi.
# sysctl net.inet.tcp.baddynamic=749,750,751,760,761,871
Można także dodać, bądź usunąć, któryś z wpisów aktualnej listy.
# sysctl net.inet.tcp.baddynamic=+748
# sysctl net.inet.tcp.baddynamic=-871
net.inet.tcp.recvspace
net.inet.tcp.sendspace
NFS, sieciowy system plików (Network File System) wykorzystywany jest do współdzielenia systemów plików w sieci. Przed przystąpieniem do konfiguracji NFS powinieneś zapoznać się z kilkoma stronami manuala:
Dzięki temu rozdziałowi w prosty sposób dowiesz się jak skonfigurować NFS. Omawiamy wszystko na przykładzie serwera pracującego w sieci LAN oraz klientów, którzy wykorzystują w tej sieci NFS. W sekcji tej nie będziemy poruszać zagadnień związanych z bezpieczeństwem, zakładamy, że masz już skonfigurowany swój filtr pakietów lub inną ochronę typu firewall, aby uniemożliwić dostęp osobom z zewnątrz. Jeśli zamierzasz zezwolić na dostęp do NFS z zewnątrz w celu wymiany poufnych danych, które nie powinny trafić w niepowołane ręce, rekomendowane jest wykorzystanie IPsec. W innym przypadku możliwe jest podsłuchanie całego ruchu, który wymieniany jest przez NFS. Innym sposobem na niepowołane dostanie się do serwera jest podmienienie adresu IP na taki, któremu zezwalasz na dostęp. Istnieje jeszcze kilka metod ataku na NFS, jednak prawidłowo skonfigurowany IPsec stanowi skuteczną ochronę.
Jeszcze jedna uwaga związana z bezpieczeństwem. Nie dodawaj samych systemów plików do /etc/exports bez listy hostów, które mogą mieć dostęp do zasobów. Jeśli nie wyszczególnisz, który z nich może montować odpowiedni katalog, każdy, kto będzie mógł ustanowić z Twoim serwerem połączenie, będzie mógł montować wszystkie eksportowane przez Ciebie katalogi.
portmap(8) musi być on uruchomiony aby działał NFS. Portmap(8) w OpenBSD jest domyślnie wyłączony, dlatego dodaj linię
portmap=YES
# /usr/sbin/portmap
W naszym przykładzie serwer ma adres IP 10.0.0.1. Będzie on udostępniał NFS tylko klientom znajdującym się w swojej sieci. Pierwszym krokiem w konfiguracji jest edycja pliku /etc/exports. Umieścisz w nim zasoby, które chciałbyś udostępnić klientom oraz zdefiniujesz kto powinien mieć dostęp do poszczególnych zasobów. W pliku /etc/exports możesz użyć naprawdę wielu opcji, aby zapoznać się ze wszystkimi możliwościami przeczytaj exports(5) W tej chwili mamy /etc/exports wyglądający w ten sposób:
#
# NFS exports Database
# See exports(5) for more information. Be very careful, misconfiguration
# of this file can result in your filesystems being readable by the world.
/work -alldirs -ro -network=10.0.0 -mask=255.255.255.0
Powyższy wpis oznacza, że przez NFS dostępny będzie system plików /work. Opcja -alldirs że klienci będą mogli montować każdy katalog znajdujący się na systemie plików /work. Opcja -ro oznacza, że zezwalamy na montowanie w trybie tylko do odczytu. Ostatnie dwa argumenty mówią, że tylko hosty z sieci 10.0.0.0 o masce 255.255.255.0 mogą mieć dostęp do tego zasobu, co jest istotne w przypadku, gdy serwery pracują w kilku różnych sieciach.
Gdy Twój plik /etc/exports jest już odpowiednio skonfigurowany, możesz przejść do konfiguracji serwera. Upewnij się, czy Twoje jądro zostało skompilowane z opcją NFSSERVER oraz NFSCLIENT (standardowe jądra tak mają). Następnym krokiem jest dodanie wpisu
nfs_server=YES
# /sbin/nfsd -tun 4
Wystartowanie nfsd(8) nie jest ostatnią czynnością, oprócz tego potrzebujesz uruchomić jeszcze mountd(8). Demon ten obsługuje żądania montowania NFS. Aby go uruchomić, upewnij się, że istnieje pusty plik mountdtab, a następnie uruchom demona:
# echo -n >/var/db/mountdtab
# /sbin/mountd
Jeśli w trakcie pracy wprowadzisz jakieś zmiany w /etc/exports, musisz poinformować o tym mountd! Wystarczy sygnał HUP:
# kill -HUP `cat /var/run/mountd.pid`
W tej chwili możesz sprawdzić czy wystartowanie przez Ciebie demony pracują i są zarejestrowane w RPC. Skorzystaj z rpcinfo(8).
$ rpcinfo -p 10.0.0.1
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 633 mountd
100005 3 udp 633 mountd
100005 1 tcp 916 mountd
100005 3 tcp 916 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
Podczas zwykłego użytkowania, istnieje jeszcze kilka innych narzędzi pozwalających zobaczyć co dzieje się z NFS'em. Jedną z nich jest: showmount(8), dzięki któremu możesz dowiedzieć się. jakie zasoby są aktualnie zamontowane i przez kogo. Jest jeszcze nfsstat(1), który wyświetla kilka dodatkowych informacji. Używając showmount(8), spróbuj /usr/bin/showmount -a host. Przykładowo:
$ /usr/bin/showmount -a 10.0.0.1
All mount points on 10.0.0.1:
10.0.0.37:/work
NFS powinien być montowany poleceniem mount(8) lub w bardziej specyficzny dla niego sposób korzystając z mount_nfs(8). Do zamontowania systemu plików /work znajdującego się na hoście 10.0.0.1 do lokalnego katalogu /mnt skorzystaj z poniższej składni (możesz zamiast adresu IP użyć nazwy hosta):
# mount -o ro -t nfs 10.0.0.1:/work /mnt
Jeśli chcesz, aby montowanie przebiegało w momencie uruchamiania systemu, dodaj linijkę analogiczną do poniższej w pliku /etc/fstab:
10.0.0.1:/work /mnt nfs ro 0 0
Ważne jest, abyś jako dwa ostatnie wpisy w tej linii umieścił 0 0, aby Twój komputer nie próbował sprawdzać systemu plików programem fsck przy starcie! Inne standardowe opcje zwiększające bezpieczeństwo, takie jak noexec, nodev i nosuid powinny być także użyte zawsze, gdy jest to możliwe:
10.0.0.1:/work /mnt nfs ro,nodev,nosuid 0 0
W ten sposób, mount nie będzie interpretował urządzeń specjalnych i unieważni bity suid dzięki czemu programy na serwerze nie będą mogły wykonywać niebezpiecznych operacji na kliencie NFS. Jeśli nie montujesz żadnych programów, których chciałbyś używać przez NFS, powinieneś dodać także opcję noexec.
Bridge jest pomostem łączącym dwie lub więcej odseparowanych od siebie sieci. W przeciwieństwie do rutera, bridge jest logicznie "niewidzialny", dwa segmenty sieci myślą, że tworzą jeden segment z hostami po drugiej stronie bridge'a. Bridge będzie jedynie przekazywał pakiety pomiędzy segmentami sieci i umożliwiał łatwy i bezpośredni dostęp do zasobów pomiędzy hostami znajdującymi się w odrębnych segmentach sieci.
Pamiętaj, że ze względu na swój "niewidzialny" charakter działania, interfejs sieciowy bridge'a może posiadać (lub nie) indywidualny adres IP. Jeśli tak, interfejs ma dwa typy pracy, jeden jako bridge, drugi jako zwykły, standardowy interfejs sieciowy. Jeśli interfejs nie posiada adresu IP, bridge będzie przekazywał pakiety, jednak nie będzie dostępny z zewnątrz.
Posiadam zbiór starych systemów komputerowych, żaden z nich nie ma wbudowanego interfejsu 10BASE-TX. Posiadają natomiast łącza AUI lub AAUI. Jedną z maszyn jest terminal serwerowy z OpenBSD, mający stałe szybkie połączenie z taką samą siecią. Dodanie kolejnego interfejsu z portem coax pozwoli na wykorzystanie tej maszyny jako bridge'a pomiędzy sieciami coax.
System ten posiada dwa interfejsy, Intel EtherExpress/100 (fxp0) i kartę 3c590-Combo (ep0) dla portu coax. fxp0 jest interfejsem podłączonym do pozostałej części sieci, a zatem będzie mieć przypisany adres IP, ep0 będzie tworzyć bridge bez przypisanego adresu IP. Hosty podłączone do segmentu coax będą mogły się ze sobą komunikować tak, jakby były w drugiej części sieci. Jak do tego dojdziemy?
Plik hostname.fxp0 zawiera konfigurację interfejsu fxp0. Korzysta on z informacji dostarczanych przez DHCP, więc plik wygląda w poniższy sposób:
$ cat /etc/hostname.fxp0
dhcp NONE NONE NONE
Bez niespodzianek.
Karta ep0 posiada nieco inną konfigurację:
$ cat /etc/hostname.ep0
up media 10base2
Instruujemy system, aby aktywował interfejs korzystając z ifconfig(8) i ustawił tryb pracy na 10BASE-2 (coax). Nie przypisujemy do interfejsu adresu IP, ani żadnych podobnych informacji. Opcje kart ep znajdziesz na stronie manuala.
Teraz musimy uruchomić bridge. Inicjujemy go, poprzez plik konfiguracyjny nazwany w stylu bridgename.bridge0. A oto i jego przykładowa zawartość:
$ cat /etc/bridgename.bridge0
add fxp0
add ep0
up
Oto cała filozofia tworzenia bridge'a składającego się z dwóch interfejsów sieciowych fxp0 i ep0 oraz jego aktywacji. Czy jest istotna kolejność w jakiej to robimy? Nie, należy bowiem pamiętać, że bridge jest symetryczny - pakiety wędrują w obu kierunkach.
To już wszystko! Uruchom ponownie system i ciesz się funkcjonalnością swojego bridge'a.
Uważaj, pamiętaj o dwukierunkowej naturze bridge'a, o tym, że część danych wędruje poprzez dwa interfejsy, tak więc wystarczy, gdy będziesz je filtrował na jednym z nich. Twoje domyślne regułki "Pass all" mogą wyglądać w ten sposób:
pass in on ep0 all
pass out on ep0 all
pass in on fxp0 all
pass out on fxp0 all
Teraz, powiedzmy że chciałbym filtrować ruch wędrujący z/do starych maszyn, które wymieniłem powyżej. Chcę zezwolić im na korzystanie jedynie z usług www oraz SSH. W tym przypadku, zezwalamy na przemieszczanie się pakietów w obu kierunkach poprzez interfejs ep0, natomiast filtrowania dokonujemy na interfejsie fxp0, używając opcji keep state do przechwytywania powracających danych:
# Przepuść cały ruch przez ep0
pass in quick on ep0 all
pass out quick on ep0 all
# Zablokuj cały ruch na interfejsie fxp0
block in on fxp0 all
block out on fxp0 all
pass in quick on fxp0 proto tcp from any to any port {22, 80} \
flags S/SA keep state
Zauważ że ten zestaw regułek, zablokuje wszystko za wyjątkiem ruchu HTTP i SSH przed dotarciem zarówno do naszego bridge'a jak i każdego hosta "za nim". Inne rezultaty możesz osiągnąć filtrując ruch na drugim interfejsie.
Do monitorowania i kontrolowania utworzonego bridge'a, korzystaj z komendy brconfig(8) która może być również używana do stworzenia bridge'a.
Preboot Execution Environment, czyli PXE, pozwala wystartować komputer z sieci zamiast z dysku twardego, napędu CDROM, czy też z dyskietki startowej. Technologię tą opracował Intel, jest jednak wspierana przez znakomitą większość kart sieciowych i producentów komputerów. Warto zwrócić uwagę, że istnieje kilka standardów startu systemu z sieci, przy czym PXE opracowano stosunkowo niedawno. Tradycyjnie, PXE wykorzystuje pamięci ROM na kartach sieciowych (bądź też na płytach głównych). Są jednak dostępne odpowiednie dyskietki startowe, pozwalające na wykorzystanie PXE. Wiele pamięci ROM na starszych kartach sieciowych wspiera bootowanie z sieci, NIE wspiera jednak PXE - obecnie nie można ich wykorzystać do startu na architekturach: OpenBSD/i386 oraz amd64.
Zakładając, że maszyna z OpenBSD jest źródłem plików startowych
(NIE jest to wymagane). Plik konfiguracyjny serwera DHCP dhcpd.conf powinien zawierać linię:
filename "pxeboot";
jeżeli w zamierzeniu OpenBSD udostępnia ten plik startującym stacjom
roboczym. Na przykład:
shared-network LOCAL-NET {
option domain-name "example.com";
option domain-name-servers 192.168.1.3, 192.168.1.5;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
filename "pxeboot";
range 192.168.1.32 192.168.1.127;
default-lease-time 86400;
max-lease-time 90000;
}
}
Konieczne jest także uruchomienie demona tftpd(8). Standardowo wykonujemy to poprzez
inetd(8).
Standardowa instalacja OpenBSD posiada przykładową linię w inetd.conf
która będzie dla ciebie pomocna:
#tftp dgram udp wait root /usr/libexec/tftpd tftpd -s /tftpboot
(usuwamy # z początku tej linii) i wysłaniem do procesu inetd(8)
sygnału -HUP, aby przeładować /etc/inetd.conf.
Serwer tftpd(8) udostępnia pliki z zaznaczonego katalogu, w naszym
przypadku jest to katalog /tftpboot.
Oczywiście, katalog ten musi zostać utworzony i udostępniony.
W typowym rozwiązaniu potrzebujemy tylko kilku plików dla PXE:
Zakładając, że serwery DHCP i TFTP są już skonfigurowane, jesteśmy gotowi
do przetestowania konfiguracji.
Pozostaje tylko aktywować PXE na stacji roboczej.
W trakcie uruchamiania systemu powinniśmy zobaczyć:
Intel UNDI, PXE-2.0 (build 067)
Copyright (C) 1997,1998 Intel Corporation
For Realtek RTL 8139(X) PCI Fast Ethernet Controller v1.00 (990420)
DHCP MAC ADDR: 00 E0 C5 C8 CF E1
CLIENT IP: 192.168.1.76 MASK: 255.255.255.0 DHCP IP: 192.168.1.252
GATEWAY IP: 192.168.1.1
probing: pc0 com0 com1 apm pxe!2.1 mem540k 28m a20=on
disk: hd0*
net: mac 00:e0:c5:c8:cf:e1, ip 192.168.1.76, server 192.168.1.252
>> OpenBSD/i368 PXEBOOT 1.00
boot>
W tym momencie otrzymujemy standardowy boot prompt. Jeżeli wpiszemy
"bsd.rd", zostanie pobrany plik bsd.rd z serwera TFTP.
>> OpenBSD/i386 PXEBOOT 1.00
boot> bsd.rd
booting tftp:bsd.rd: 4375152+733120 58+122112+105468=0x516d04
entry point at 0x100120
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of The University of California. All rights reserved.
Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 4.2 (RAMDISK_CD) #468: Tue Aug 28 11:02:17 MDT 2007
...
Rozpoczyna się start systemu z jądrem
instalacyjnym bsd.rd.
CARP jest narzędziem, które pozwala uczynić system redundantnym poprzez utworzenie wirtualnej sieci pomiędzy komputerami, dzięki czemu w przypadku awarii jednego z nich, inny przejmuje jego rolę, ewentualnie obciążenie rozkładane jest na pozostałe maszyny. CARP jest udoskonaleniem standardu Virtual Router Redundancy Protocol (VRRP). Został opracowany, gdy uznano że VRRP nie jest wystarczająco "wolny", ze względu na możliwość objęcia go patentami CISCO. Aby uzyskać więcej informacji o pochodzeniu CARP`a, a także aspektach prawnych towarzyszących VRRP, odwiedź tą stronę.
Ze względu na problemy licencyjne Ryan McBridge (z pomocą Michael Shalayeff'a, Marco Pfatschbacher'a i Markusa Friedl'a) zaprojektował CARP jako narzędzie fundamentalnie różne od VRRP. Włączenie kryptografii jest najbardziej widoczną zmianą, wciąż jednak jest to tylko jedna z wielu zmian.
Jak to działa: CARP jest protokołem multicastowym. Grupuje kilka fizycznych maszyn w jednej lub kilku wirtualnych sieciach. W tej grupie, jeden komputer pełni role zarządzającego (master`a) i odpowiada na pakiety kierowane do całej grupy. Pozostałe pełnią rolę "zapasowych" (ang. "hot spares"). Nie ma znaczenia jaki jest adres IP lub MAC fizycznego interfejsu, pakiety wysłane na adres CARP wracają z informacją CARP.
W konfigurowalnych odstępach czasu, komputer zarządzający (ang. master) rozgłasza swoją aktywność na protokole 112. Jeżeli master zostanie odłączony, systemy z grupy CARP rozpoczynają rozgłaszanie, przy czym host rozgłaszający najczęściej staje się nowym masterem grupy. Ponowne pojawienie się głównego systemu, domyślnie powoduje, że staje się on zapasowym, o ile nie jest pożądane by jedna maszyna stawała się masterem zawsze kiedy jest dostępna (dla przykładu, gdy jeden host jest szybkim Sun Fire V120 natomiast pozostałe to nieporównywalnie słabsze SPARCstation). Możesz to oczywiście skonfigurować.
O ile wysoko redundantne i odporne na zakłócenia urządzenia minimalizują potrzebę posiadania CARP`a, całkowicie nie wykluczają jego zasadności. Nie istnieje bowiem urządzenie mogące zachować zdolności operacyjne po odłączeniu go od źródła zasilania, lub w sytuacji gdy administrator wpisze reboot w niewłaściwym oknie. CARP pozwala także ułatwić paczowanie i cykliczne restarty w sposób przeźroczysty dla użytkowników, a także testy oprogramowania i modernizacje sprzętu - "jeżeli nie działa, możesz wrócić, zacząć od początku, aż do uzyskania porządanego efektu".
Występują jednak sytuacje, w których CARP nie pomoże. Architektura protokołu CARP wymaga by hosty z grupy należały do tej samej fizycznej podsieci ze statycznym adresem IP, chociaż wraz z wprowadzeniem dyrektywy carpdev, nie istnieje potrzeba by fizyczny interfejs sieciowy posiadał adres IP. Podobnie, usługi wymagające stałego połączenia z serwerem (takie jak SSH czy IRC), nie mogą być przeźroczyście przenoszone na inny system, w takiej sytuacji jednak CARP pomaga zminimalizować czas niedostępności. CARP sam w sobie nie synchronizuje danych pomiędzy aplikacjami, ta czynność jest wykonywana przy użyciu "alternatywnych kanałów" takich jak pfsync(4) (dla nadmiarowego filtrowania pakietów), manualnego kopiowania danych pomiędzy serwerami przy użyciu rsync, lub dowolnej innej metody specyficznej dla danej aplikacji.
Konfiguracja CARP`a tworzona jest przy pomocy dwóch narzędzi: sysctl(8) oraz ifconfig(8). Zacznijmy od sysctl.
Parametr net.inet.carp.allow definiuje czy dany host będzie odbierał pakiety przeznaczone dla CARP. Oczywiście, jest to niezbędne, aby korzystać z CARP. Ta opcja jest domyślnie włączona.
Parametr net.inet.carp.arpbalance używany jest do rozkładania obciążenia. Włączenie jej powoduje, że CARP zapisuje w tablicach hash`ujących źródłowy adres IP rozgłoszenia. Klucze tablicy hash`ującej jest później wykorzystywane do wyboru wirtualnego hosta z dostępnej grupy zdolnej by odpowiedzieć na zapytanie. Ta opcja jest domyślnie wyłączona.
Trzeci parametr, net.inet.carp.log, aktywuje logowanie błędów w CARP. Opcja domyślnie wyłączona.
Czwarty arametr, net.inet.carp.preempt, aktywuje naturalna selekcję wśród hostów CARP. Host rozgłaszający najszybciej staje się master'em. Opcja domyślnie wyłączona, co oznacza że system nie będący masterem nie będzie się o ten status ubiegał.
Wszystkie te parametry są szczegółowo opisane w sysctl(3).
Pozostałą część konfiguracji CARP`a wykonujemy z poziomu ifconfig(8). Parametry specyficzne dla CARP advbase i advskew dotyczą przedziału pomiędzy rozgłoszeniami CARP. Wartość (w sekundach) to advskew dzielone przez 256, i ustawione w advbase. Aby ograniczyć ruch sieciowy, lub zwiększyć opóźnienie zanim system zapasowy przejmie zadania używamy advbase. Polecenie advskew pozwala na ustalenie który host będzie masterem, minimalizując opóźnienie związane z elekcją.
Parametry pass i vhid ustalają odpowiednio hasło i numer identyfikacyjny grupy CARP. Należy ustawić unikalne numery każdej z grup CARP, nawet jeżeli, ze względu na rozkładanie obciążenia, dzielą ten sam adres IP. CARP dopuszcza 255 grup.
Wreszcie, carpdev określa który fizyczny interfejs należy do określonej grupy CARP. Domyślnie jakikolwiek interfejs posiada adres IP w tej samej podsieci przypisanej do CARP, będzie on używany.
Uwzględnijmy wszystkie te informacje w testowej konfiguracji. Zakładamy że posiadamy dwa identycznie skonfigurowane serwery WWW: rachael (192.168.0.5) oraz pris (192.168.0.7), które mają zastąpić stary system o adresie 192.168.0.7. Zaczynamy:
rachael# ifconfig carp0 create
rachael# ifconfig carp0 vhid 1 pass tyrell carpdev fxp0 \
192.168.0.7 netmask 255.255.255.0
Pierwsze polecenie tworzy interfejs carp0, drugie ustawia dla tego interfejsu vhid równe 1, hasło tyrell i adres 192.168.0.7 z netmaską 255.255.255.0. Przypisanie interfejsu fxp0 jako członka. By mieć pewność, że uzyskamy te ustawienia po restarcie systemu, możemy utworzyć plik /etc/hostname.carp0 z wpisem:
inet 192.168.0.7 255.255.255.0 192.168.0.255 vhid 1 pass tyrell carpdev fxp0
Identycznie postępujemy na serwerze pris. System, który jako pierwszy podniesie interfejs CARP stanie się masterem (zakładając, że preempt jest wyłączony; odwrotnie jest to prawdą jeżeli preempt jest włączony).
Powiedzmy jednak, że nie stawiasz systemu od zera. Rachael jest działającym systemem z adresem 192.168.0.7. Jak sobie z tym poradzić? Szczęśliwie, CARP potrafi sobie radzić z taką sytuacją. Możesz po prostu przypisać adres do interfejsu CARP i pozostawić fizyczny interfejs wpisany w 'carpdev' bez przypisanego adresu IP.
Zwiększmy poziom skomplikowania, aby rachael stawał się masterem kiedy tylko będzie to możliwe. Takie rządanie może być uzasadnione kilkoma czynnikami: różnice sprzętowe, zwykłe uprzedzenie ("jeżeli ten system nie jest masterem, to jest problem"), lub znajomość domyślnego mastera bez konieczności okresowego sprawdzania.
Na systemie rachael użyjemy sysctl i wyedytujeny /etc/sysctl.conf by utrwalić wprowadzone zmiany:
rachael# sysctl net.inet.carp.preempt=1
W systemie pris:
pris# ifconfig carp0 advskew 100
znacznie opóźni rozgłaszanie pris`a, czyniąc rachael masterem kiedy tylko będzie dostępny.
Zauważmy, że używając PF'a na maszynie z CARP`em musimy przepuścić "proto carp" na każdym interfejsie obsługującym protokół CARP, przy pomocy składni podobnej do:
pass on fxp0 proto carp keep state
Rozważmy sytuację z poprzedniego przykładu za kilka miesięcy. Nasza firma rozrosła się w tym czasie i jeden serwer WWW to po prostu za mało. Co możemy zrobić? Możemy użyć CARP'a. Czas wypróbować rozkładanie obciążenia. Stwórzmy nowy interfejs i grupę CARP na rachael:
rachael# ifconfig create carp1
rachael# ifconfig carp1 vhid 2 advskew 100 pass bryant carpdev fxp0 \
192.168.0.7 netmask 255.255.255.0
Na pris`ie utwórzmy nową grupę i nowy interfejs podobnie, przy czym ustawiamy "preempt" w sysctl:
pris# ifconfig carp1 create
pris# ifconfig carp1 vhid 2 pass bryant carpdev fxp0 \
192.168.0.7 netmask 255.255.255.0
pris# sysctl net.inet.carp.preempt=1
Teraz mamy dwie grupy CARP na tym samym adresie IP. Każda grupa jest powiązana z innym hostem, co oznacza, że rachael wciąż pozostaje masterem początkowej grupy, lecz pris przejmuje nową.
Jedyne co musimy jeszcze zrobić to włączyć rozkładanie obciążenia na obu maszynach:
# sysctl net.inet.carp.arpbalance=1
Opisane przykłady dotyczą wprawdzie klastra z dwoma maszynami, nic jednak nie stoi na przeszkodzie by zastosować to do większej ich ilości. Zauważmy jednak, że nie należy oczekiwać rozłożenia 50/50 pomiędzy maszynami - CARP korzysta z klucza mieszającego by określić który system podejmie się odpowiedzi, znacznie bardziej niż opierając się na aktualnym obciążeniu.
OpenNTPD usiłuje rozwiązać większość tych problemów, dając łatwą w administracji, bezpieczną i prostą drogę do posiadania dokładnego czasu na własnym komputerze. Dostępny w OpenBSD demon ntpd(8), posiada łatwy i przejrzysty plik konfiguracyjny /etc/ntpd.conf.
Proste uruchomienie ntpd(8), poprzez rc.conf.local, spowoduje powolne dostrajanie zegara twojego komputera a następnie utrzymywanie go zsynchronizowanego z jednym z publicznie dostępnych serwerów czasu pool.ntp.org. Gdy już zegar będzie ustawiony, ntpd będzie go utrzymywał na bardzo niskim poziomie niedokładności, jednakże, jeżeli twój zegar jest niedokładny o więcej niż kilka minut jest bardzo zalecane by ustawić go początkowo możliwie dokładnym, ponieważ może potrwać dni lub tygodnie by zsynchronizować bardzo niedokładny zegar. Możesz to zrobić korzystając z opcji "-s" dla ntpd(8) lub innego programu pozwalającego ustawić aktualny czas systemowy.
Istnieją aplikacje dla których narzędzie ntpd.org jest bardziej odpowiednie; jednakże odczuwamy, że dla dużej liczby pozostałych użytkowników, OpenNTPD jest bardziej niż wystarczający.
Bardziej kompletna odpowiedź na to, pochodząca od jednego z maintainerów OpenNTPD, jest dostępna tutaj.
Gdy masz już nasłuchującego ntpd(8), może się zdażyć, że inne maszyny wciąż nie mogą się z niego synchronizować! Świerzo uruchomiony demon ntpd(8) (przykładowo, gdy właśnie go restartowałeś po zmianach ntpd.conf) odrzuca połączenia innym klientom, aż do ustawienia własnego czasu na rozsądnym poziomie stabilności. Gdy ntpd(8) uzna, że jego własna informacja o czasie jest stabilna, zgłasza to komunikatem "clock now synced" w /var/log/daemon. Nawet jeśli zegar systemowy już na początku jest całkiem dokładny, może zająć nawet 10 minut uzyskanie synchronizacji, lub godziny a nawet dni, gdy jest zupełnie niedokładny.
Urządzenia bazujące na tych układach mogą być wykorzystywane, w sposób podobny do pozostałych urządzeń sieciowych, do podłączenia OpenBSD do istniejącej sieci bezprzewodowej i skonfigurowane przy pomocy standardowego ifconfig(8) (więcej szczegółów w podręczniku systemowym man). Niektóre z tych kart mogą być wykorzystywane do pracy w trybie bramki dostępowej ("Host-Based Access Point"), pozwalając na integracje z twoim firewall`em.
Zwracamy uwagę że korzystanie z niektórych z tych kart wymaga pobrania plików firmware ponieważ producenci odmawiają wolnej ich dystrybucji, zatem nie mogą być włączone do OpenBSD. Gdy jest to możliwe strony manuala zawierają informację o kontakcie do osobny odpowiedzialnej po stronie producenta, tak abyś mógł im napisać jak się z tym czujesz, lub by przekazać im jaki produkt kupiłeś zamiast ich rozwiązania.
Inną możliwością jest wykorzystanie twojego firewall-a OpenBSD do udostępniania punktu dostępowego poprzez standardowe połączenie sieciowe do zewnętrznego mostkującego Access Point-a. Ma to tą zaletę, że pozwala na łatwe umiejscowienie anteny w najdogodniejszym miejscu, które często nie jest bezpośrednio przy firewall-u.
Routing oparty na wyborze jednej z tras o jednakowym koszcie (ECMP - Equal Cost Multipath Routing) pozwala na posiadanie wielu wpisów w tablicy routingu dla tej samej podsieci, przykładowo dla trasy domyślnej 0.0.0.0/0. Gdy kernel przegląda trasy routingu starając się określić gdzie posłać pakiety przeznaczone do danej podsieci, może wybrać jedną z wielu tras o równym koszcie. W większości przypadków routing "multi-ścieżkowy" (ang. multipath) wykorzystywany jest w połączeniach wychodzących zapewniając redundantne połączenia z siecią Internet.
Polecenie route(8) wykorzystywane jest do dodawania/zmian/kasowania tras w tablicy routingu. Argument -mpath jest używany w przypadku dodawania ścieżek multipath.
# route add -mpath default 10.130.128.1
# route add -mpath default 10.132.0.1
Sprawdzanie tras:
# netstat -rnf inet | grep default
default 10.130.128.1 UGS 2 134 - fxp1
default 10.132.0.1 UGS 0 172 - fxp2
W powyższym przykładzie możemy zobaczyć jak jedna trasa domyślna wskazuje na 10.130.128.1, który jest osiągalny przez interfejs fxp1, natomiast druga wskazuje na 10.132.0.1, osiagalny przez interfejs fxp2.
Ponieważ plik mygate(5) nie obsługuje jeszcze tego mechanizmu, poniższe linie powinny być dodane na końcu plików hostname.if(5) dla interfejsów fxp1 i fxp2. Plik /etc/mygate powinien zostać skasowany.
Na koniec nie zapomnij aktywować obsługę multipath-routingu poprzez właściwą zmienną sysctl(3).
# sysctl net.inet.ip.multipath=1
# sysctl net.inet6.ip6.multipath=1
Zmień także plik konfiguracyjny sysctl.conf(5), aby wprowadzić te zmiany na trwałe.
Spróbuj teraz prześledzić trasy do różnych celów. Kernel powinien rozłożyć obciążenie pomiędzy każdą z tras.
# traceroute -n 154.11.0.4
traceroute to 154.11.0.4 (154.11.0.4), 64 hops max, 60 byte packets
1 10.130.128.1 19.337 ms 18.194 ms 18.849 ms
2 154.11.95.170 17.642 ms 18.176 ms 17.731 ms
3 154.11.5.33 110.486 ms 19.478 ms 100.949 ms
4 154.11.0.4 32.772 ms 33.534 ms 32.835 ms
# traceroute -n 154.11.0.5
traceroute to 154.11.0.5 (154.11.0.5), 64 hops max, 60 byte packets
1 10.132.0.1 14.175 ms 14.503 ms 14.58 ms
2 154.11.95.38 13.664 ms 13.962 ms 13.445 ms
3 208.38.16.151 13.964 ms 13.347 ms 13.788 ms
4 154.11.0.5 30.177 ms 30.95 ms 30.593 ms
Więcej informacji na temat sposobu w jaki są wybierane trasy znajdziesz w dokumencie RFC2992, "Analysis of an Equal-Cost Multi-Path Algorithm".
Rozwiązanie to może okazać się mało użyteczne jeżeli interfejs wykorzystywany w routinigu wielo-scieżkowym zostanie wyłączony (np. utracone zostanie połączenie), ponieważ kernel wciąż będzie starał się przekazywać pakiety korzystając z trasy wskazującej na ten interfejs. Taki ruch będzie oczywiście gubiony i ostatecznie nigdzie nie trafi. Zdecydowanie zalecamy korzystanie z ifstated(8) w celu sprawdzania niedostępnych interfejsów i modyfikacji tablicy routingu.
[Spis treści] [Sekcja 5 - Tworzenie systemu ze źródeł] [Sekcja 7 - Ustawienia klawiatury i wyświetlania]
![[wstecz]](../../images/back.gif){kind=small}
www@openbsd.org