![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ Index] [Naar Sectie 5 - Het Systeem vanaf Broncode Bouwen] [Naar Sectie 7 - Toetsenbord en Scherm Bediening]
Voor het overgrote deel van dit document helpt het als u de Kernel Configuratie en Instelling sectie van de FAQ, de ifconfig(8) en netstat(1) man pagina's gelezen en tenminste gedeeltelijk begrepen hebt.
Als u een netwerkbeheerder bent, en u bent routeringsprotocols aan het opzetten, als u uw OpenBSD machine als een router gebruikt, als u diep moet ingaan op IP networken, moet u echt Understanding IP Addressing lezen. Dit is een uistekend document. "Understanding IP Addressing" bevat fundamentele kennis waarop u kan bouwen wanneer u werkt met IP netwerken, vooral wanneer u met één of meer netwerken te maken hebt of er verantwoordelijk voor bent.
Indien u werkt met toepassingen zoals web servers, ftp servers en mail servers, kan u uw voordeel doen door de RFC's te lezen. Waarschijnlijk kan u ze niet allemaal lezen. Kies er een aantal onderwerpen uit die u interesseren of die u gebruikt in uw netwerkomgeving. Zoek ze op, kom te weten hoe ze bedoeld zijn om te werken. De RFC's definiëren vele (duizenden) standaarden voor protocols op het Internet en hoe ze zouden moeten werken.
In OpenBSD worden interfaces benoemd volgens het kaarttype, niet volgens het verbindingstype. U kan uw netwerkkaart geïnitialiseerd zien worden tijdens het bootproces, of na het bootproces door gebruik van het dmesg(8) commando. U hebt ook de gelegenheid om uw netwerk interfaces te zien met het ifconfig(8) commando. Hier is bijvoorbeeld de uitvoer van dmesg voor een Intel Fast Ethernet netwerkkaart, die de device naam fxp gebruikt.
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
Als u niet weet wat uw device naam is, kijk dan naar de ondersteunde hardware lijst voor uw platform. U zal daar een lijst terugvinden van veel voorkomende kaartnamen en hun OpenBSD device namen. Combineer de korte alfabetische device naam (zoals fxp) met een nummer toegekend door de kernel en u hebt een interface naam (zoals fxp0). Het nummer wordt toegekend op basis van verscheidene criteria, afhankelijk van de kaart en andere details van het systeem. Sommige kaarten worden toegekend volgens de volgorde waarin ze gevonden worden tijdens het "proben" van een bus. Andere kunnen toegekend worden op basis van hardware-instellingen of MAC adres.
U kan te weten komen welke netwerk interfaces er geïdentificeerd zijn met de ifconfig(8) utility. Het volgende commando zal alle netwerk interfaces op een systeem weergeven. Deze voorbeelduitvoer toont ons slechts één fysische Ethernet interface, een fxp(4).
$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
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
Zoals u hier kan zien, geeft ifconfig(8) ons veel meer informatie dan we op dit punt nodig hebben. Maar het laat ons wel toe om onze interface te zien. In het bovenstaande voorbeeld is de interface kaart al geconfigureerd. Dit spreekt voor zich omdat er al een IP netwerk geconfigureerd is op fxp0, vandaar de waarden "inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255". Ook de UP en RUNNING vlaggen zijn aangezet.
Tenslotte zal u merken dat verscheidene andere interfaces standaard ingeschakeld zijn. Dit zijn virtuele interfaces die voor verschillende functies dienen. De volgende manual pagina's beschrijven ze:
De interface wordt tijdens het opstarten geconfigureerd met de /etc/hostname.if(5) bestanden, waarbij if vervangen zal worden door de volledige naam van uw interface, in het bovenstaande voorbeeld is dat /etc/hostname.fxp0.
De layout van dit bestand is eenvoudig:
address_family address netmask broadcast [andere opties]
Een typisch configuratiebestand, geconfigureerd voor een IPv4 adres, zou er als volgt uitzien:
$ cat /etc/hostname.fxp0
inet 10.0.0.38 255.255.255.0 NONE
In dit geval hebben we een IPv4 (inet) adres gedefinieerd, met als IP adres 10.0.0.38, als subnet mask 255.255.255.0, en zonder specifiek broadcastadres (dat wordt standaard 10.0.0.255 in dit geval).
U zou ook media types voor Ethernet kunnen specificeren, als u bijvoorbeeld 100baseTX full-duplex mode zou willen forceren.
inet 10.0.0.38 255.255.255.0 NONE media 100baseTX mediaopt full-duplex
(Natuurlijk mag u nooit full duplex mode forceren tenzij beide uiteinden van de verbinding hierop ingesteld zijn! Tenzij er speciale behoeften zijn, worden de media instellingen beter achterwege gelaten. Een meer waarschijnlijke situatie zou kunnen zijn dat u 10base-T of half duplex forceert indien uw infrastructuur dat vereist.)
Of, u wil misschien speciale vlaggen specifiek voor een bepaalde interface gebruiken. Aan het formaat van het hostname bestand verandert niet veel!
$ 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
Zoals bij bijna alle Unix (en vele niet-Unix) systemen, is er een /etc/hosts bestand dat kan gebruikt worden om systemen te specificeren die niet in (of indien gebruikt met de bovenstaande "lookup" prioriteit, niet zoals gewenst in) het formele DNS systeem zitten.
Indien u DHCP gebruikt, zal u 6.4 - DHCP willen lezen en nota nemen van 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
Merk op dat dit enkele fouten produceerde. Door dit script uit te voeren, herconfigureert u dingen die reeds geconfigureerd waren. Zodoende bestaan sommige routes al in de kernel routeringstabel. Van hier af zou uw systeem goed en wel draaiende en on-line moeten zijn. U kan opnieuw nagaan of uw interface juist werd ingesteld met ifconfig(8).
Hoewel u op een OpenBSD systeem het netwerk volledig kan herconfigureren zonder te herstarten, wordt het herstarten ERG aanbevolen na gelijk welke significante herconfiguratie. De reden hiervoor is dat de omgeving bij het opstarten een beetje verschillend is dan wanneer het systeem volledig draaiende is. Als u bijvoorbeeld een door DNS vertaalde symbolische naam had gespecificeerd in één van de bestanden, dan zou u waarschijnlijk vaststellen dat het zoals verwacht werkt na het herconfigureren, maar bij een initiële boot kan het zijn dat uw externe vertaler ("resolver") niet beschikbaar is, en dus zal dan de configuratie mislukken.
$ 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
Dit is de basisinformatie die u nodig hebt om uw OpenBSD machine in te stellen als een gateway (ook router genoemd). Als u OpenBSD gebruikt als een router op het Internet, stellen we voor dat u ook de Packet Filter setup instructies hieronder leest om mogelijk kwaadwillig verkeer te blokkeren. Ook kan u, door de lage beschikbaarheid van IPv4 adressen vanwege netwerk service providers en regionale registers, misschien eens kijken naar Network Address Translation voor informatie over hoe u uw IP adresruimte kan bewaren.
De GENERIC kernel heeft al de mogelijkheid om IP Forwarding toe te laten, maar dit moet ingeschakeld worden. U doet dit best met de sysctl(8) utility. Om dit permanent te wijzigen, bewerkt u het bestand /etc/sysctl.conf om IP Forwarding toe te laten. Om dit te doen voegt u de volgende lijn toe in dat configuratiebestand.
net.inet.ip.forwarding=1
Om deze wijziging door te voeren zonder te herstarten, zou u de sysctl(8) utility rechtstreeks gebruiken. Onthou echter dat die verandering dan na het herstarten niet meer van kracht is, en dat dit als root moet uitgevoerd worden.
# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1
Wijzig nu de routes op de andere hosts aan beide uiteinden. Er zijn vele mogelijke gebruiken van OpenBSD als een router door software als OpenBSD's eigen OpenBGPD, routed(8), mrtd, zebra en quagga te gebruiken. OpenBSD heeft in de ports collectie ondersteuning voor zebra, quagga en mrtd. OpenBGPD en routed worden geïnstalleerd als onderdeel van het base systeem. OpenBSD ondersteunt verscheidene T1, HSSI, ATM, FDDI, Ethernet en seriële (PPP/SLIP) interfaces.
OpenBSD heeft een eenvoudig mechanisme om IP aliassen in te stellen op een interface. Om dit te doen bewerkt u het bestand /etc/hostname.<if>. Dit bestand wordt bij het opstarten gelezen door het /etc/netstart(8) script, dat deel uitmaakt van de rc opstarthiërarchie. In het voorbeeld veronderstellen we dat de gebruiker een interface dc0 heeft en zich op het netwerk 192.168.0.0 bevindt. Andere belangrijke informatie:
Een paar kanttekeningen bij aliassen. In OpenBSD gebruikt u alleen de interface naam. Er is geen verschil tussen de eerste alias en de tweede alias. In tegenstelling tot bij sommige andere besturingssystemen, refereert OpenBSD er niet naar als dc0:0, dc0:1. Als u met ifconfig refereert naar een specifiek ge-aliased IP, of wanneer u een alias toevoegt, zeg dan zeker "ifconfig int alias" in plaats van gewoon "ifconfig int" op de commandolijn. U kan aliassen verwijderen met "ifconfig int delete".
In de veronderstelling dat u meerdere IP adressen met aliassen gebruikt die zich in hetzelfde IP subnet bevinden, wordt uw netmask instelling voor elke alias 255.255.255.255. Ze hoeven niet het netmask te volgen van het eerste IP dat aan de interface verbonden is. In dit voorbeeld, /etc/hostname.dc0, worden twee aliassen toegevoegd aan het device dc0, dat trouwens geconfigureerd was als 192.168.0.2 netmask 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
Zodra u dit bestand hebt gemaakt, vereist het slechts een herstart om in werking te treden. U kan echter de aliassen met de hand tevoorschijn toveren met de ifconfig(8) utility. Om de eerste alias te activeren zou u het volgende commando gebruiken:
# ifconfig dc0 inet alias 192.168.0.3 netmask 255.255.255.255
Om deze aliassen te bekijken moet u het volgende commando gebruiken:
$ 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
Om de DHCP client dhclient(8) te gebruiken die bij OpenBSD zit, bewerkt u /etc/hostname.xl0 (dit veronderstelt dat uw voornaamste Ethernet interface xl0 is. De uwe zou ep0 of fxp0 of nog iets anders kunnen zijn.) Al wat u in dit hostname bestand moet zetten is 'dhcp':
# echo dhcp >/etc/hostname.xl0
Dit zorgt ervoor dat OpenBSD automatisch de DHCP client start bij het opstarten. OpenBSD zal zijn IP adres, standaard gateway en DNS servers krijgen van de DHCP server.
Als u een DHCP client vanaf de commandolijn wil starten, zorg er dan voor dat /etc/dhclient.conf bestaat en probeer vervolgens:
# dhclient fxp0
waarbij fxp0 de interface is waarop u DHCP wenst te ontvangen.
Hoe u de DHCP client ook start, u kan het bestand /etc/dhclient.conf aanpassen om uw DNS niet te updaten volgens de dhcp server zijn idee van DNS door eerst de 'request' lijnen erin te uncommenten (ze zijn voorbeelden van de standaardinstellingen, maar u moet ze uncommenten om dhclient's standaardinstellingen te overschrijven.)
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;
en daarna verwijdert u domain-name-servers. Natuurlijk kan het zijn dat u ook hostname of andere instellingen wil verwijderen.
Door de opties in uw dhclient.conf(5) bestand te wijzigen, zegt u de DHCP client hoe hij uw resolv.conf(5) bestand moet opbouwen. De DHCP client overschrijft gelijk welke informatie die reeds in resolv.conf(5) staat door de informatie die hij ontvangt van de DHCP server. Daarom zal u wijzigingen die u handmatig aanbracht in resolv.conf, verliezen.
Er zijn twee mechanismen beschikbaar om dit te voorkomen:
Een voorbeeld zou zijn wanneer u DHCP gebruikt maar lookup file bind wil toevoegen aan de resolv.conf(5) aangemaakt door dhclient(8). Er is hiervoor geen optie in dhclient.conf zodat u resolv.conf.tail moet gebruiken om dit te behouden.
# echo "lookup file bind" > /etc/resolv.conf.tail
nameserver 192.168.1.1
nameserver 192.168.1.2
lookup file bind
Als u OpenBSD als een DHCP server
dhcpd(8),
wil gebruiken, bewerk dan /etc/rc.conf.local zodat het de lijn
dhcpd_flags="" bevat.
Zet de interfaces waarvan u wil dat dhcpd er op luistert in
/etc/dhcpd.interfaces.
# echo xl1 xl2 xl3 >/etc/dhcpd.interfaces
Bewerk daarna /etc/dhcpd.conf.
De opties spreken vrijwel voor zich.
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;
}
Dit zegt uw DHCP clients dat het domein om aan DNS requests toe te voegen example.com is (dus, als de gebruiker 'telnet joe' intypt dan zal het hem naar joe.example.com verwijzen). Het zal hen verwijzen naar DNS servers 192.168.1.3 en 192.168.1.5. Voor hosts die zich op hetzelfde netwerk bevinden als een Ethernet interface op de OpenBSD machine, die in het 192.168.1.0/24 bereik staat, zal het hen een IP adres toekennen tussen 192.168.1.32 en 192.168.1.127. Het zal hun standaard gateway instellen als 192.168.1.1.
Als u dhcpd(8) vanaf de commandolijn wil starten, probeer dan na het
bijwerken van
/etc/dhcpd.conf:
# touch /var/db/dhcpd.leases
# dhcpd fxp0
De touch lijn is nodig om een leeg dhcpd.leases bestand aan te maken voordat dhcpd(8) kan starten. De OpenBSD startup scripts zullen dit bestand indien nodig bij het opstarten aanmaken, maar als u dhcpd(8) handmatig start, moet u het eerst aanmaken. fxp0 is een interface waarop u een DHCP server wil starten.
Als u DHCP diensten voor een Windows machine aanbiedt, wil u misschien dat
dhcpd(8) de client een 'WINS' server adres meegeeft. Om dit te laten gebeuren,
voegt u gewoon de volgende lijn toe aan uw
/etc/dhcpd.conf:
option netbios-name-servers 192.168.92.55;
(waarin 192.168.92.55 het IP van uw Windows of Samba server is.) Zie dhcp-options(5) voor meer opties die uw DHCP clients misschien willen.
Het Point to Point Protocol (PPP) is in het algemeen wat gebruikt wordt om een verbinding op te zetten naar uw ISP via een inbelmodem. OpenBSD heeft 2 manieren om dit te doen:
ppp en pppd voeren allebei gelijkaardige functies uit, op verschillende manieren. pppd werkt met de kernel ppp(4) driver, terwijl ppp in userland werkt met tun(4). Dit document zal enkel de userland PPP daemon behandelen, omdat deze gemakkelijker is om te debuggen en om mee te interageren. Om te beginnen zal u enkele eenvoudige gegevens over uw ISP nodig hebben. Hier is een lijst van nuttige informatie die u zal nodig hebben.
U kan zonder sommige hiervan, maar het zou helpen bij het opzetten van ppp. De userland PPP daemon gebruikt het bestand /etc/ppp/ppp.conf als configuratiebestand. Er staan heel wat nuttige bestanden in /etc/ppp die verschillende instellingen kunnen hebben voor vele verschillende situaties. U kan best eens grasduinen in deze directory.
Initiële Instelling voor de userland PPP daemon bestaat uit het aanpassen van het /etc/ppp/ppp.conf bestand. Dit bestand bestaat standaard niet, maar er is een bestand /etc/ppp/ppp.conf.sample dat u gewoon kan bewerken om uw eigen ppp.conf bestand te maken. Hier zal ik beginnen met de eenvoudigste en waarschijnlijk meest gebruikte setup. Hier is een snel gemaakt ppp.conf bestand dat gewoon enkele standaardwaarden instelt:
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"
De sectie onder het default: label wordt elke keer uitgevoerd. Hier stellen we al onze essentiële informatie in. Met "set log" stellen we onze logging niveau's in. Dit kan veranderd worden: verwijs naar ppp(8) voor meer info over logging niveau's instellen. Ons device wordt ingesteld met "set device". Dit is het device waarop de modem staat. In dit voorbeeld staat de modem op com poort 2. Daarom zou com poort 1 /dev/cua00 zijn. Met "set speed" stellen we de snelheid van onze inbelverbinding in en met "set dial" stellen we onze inbelparameters in. Hiermee kunnen we onze timeout tijd instellen, enz. Deze lijn zou echter min of meer moeten blijven zoals ze is.
Nu kunnen we overgaan tot het instellen van de informatie, specifiek voor onze ISP. We doen dit door nog een label toe te voegen onder onze default: sectie. Dit label mag u noemen zoals u wil - het makkelijkst is om gewoon de naam van uw ISP te gebruiken. Hier zal ik myisp: als ons label gebruiken dat refereert naar onze ISP. Hier is een eenvoudige instelling die alles omvat wat we nodig hebben om verbonden te geraken:
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
We hebben hier de essentiële info ingesteld voor die specifieke ISP. De eerste optie "set phone" stelt het inbelnummer van uw ISP in. De "set login" stelt onze login opties in. Hier hebben we een timeout van 5 ingesteld; dit betekent dat we onze loginpoging staken na 5 seconden als er geen carrier gevonden wordt. Anders zal hij wachten tot "login:" verstuurd wordt en vervolgens uw gebruikersnaam en wachtwoord doorsturen.
In dit voorbeeld is onze Username = ppp en Password = ppp. Deze waarden moeten veranderd worden. De lijn "set timeout" stelt de idle timeout in op 120 seconden voor de volledige duur van de verbinding. De "set ifaddr" lijn is een beetje lastig. Hieronder volgt een meer uitvoerige uitleg.
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
In de bovenstaande lijn hebben we het ingesteld volgens het formaat "set ifaddr [myaddr[/nn] [hisaddr[/nn] [netmask [triggeraddr]]]]". Dus het eerst vermelde IP is wat we als ons IP willen. Als u een statisch IP hebt, stelt u dat hier in. In ons voorbeeld gebruiken we /0 wat zegt dat er geen bits van dit IP adres moeten overeenkomen en dat het hele ding mag vervangen worden. Het tweede vermelde IP is wat we verwachten als hun IP. Als u dit kent mag u het specificeren. Opnieuw weten we in onze lijn niet wat er toegekend zal worden, dus we laten het aan hen over om het ons te zeggen. De derde optie is ons netmask, hier ingesteld op 255.255.255.0. Als triggeraddr gespecificeerd wordt, wordt het gebruikt in plaats van myaddr in de initiële IPCP negotiatie. Er zal echter alleen een adres aanvaard worden dat in het myaddr bereik ligt. Dit is nuttig wanneer genegotieerd wordt met bepaalde PPP implementaties die geen IP nummer toekennen tenzij hun peer ``0.0.0.0'' aanvraagt.
De volgende optie is "add default HISADDR" die onze standaard route naar hun IP instelt. Dit is 'sticky', wat betekent dat als hun IP adres verandert, onze route automatisch wordt aangepast. Met "enable dns" vragen we onze ISP om onze nameserver adressen te authenticeren. Doe dit NIET als u een lokale DNS draait, aangezien ppp het gebruik ervan gewoon zal omzeilen door enkele nameserver lijnen te plaatsen in /etc/resolv.conf.
In plaats van traditionele login methodes gebruiken vele ISP's nu ofwel CHAP ofwel PAP authenticatie. Als dit het geval is, zal onze configuratie er lichtjes anders uitzien:
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
In het bovenstaande voorbeeld specificeren we onze gebruikersnaam (ppp) en paswoord (ppp) met respectievelijk authname en authkey. Het is niet nodig om te specificeren of CHAP of PAP gebruikt wordt - dit wordt automatisch genegotieerd. "set login" geeft louter aan om proberen in te loggen met de voorheen opgegeven gebruikersnaam en paswoord.
Nu we ons ppp.conf bestand hebben ingesteld, kunnen we beginnen met een verbinding naar onze ISP proberen te maken. Ik zal enkele veelgebruikte argumenten van ppp toelichten:
Als het bovenstaande niet werkt, probeer dan /usr/sbin/ppp zonder opties uit te voeren - dit zal ppp in interactieve modus draaien. De opties kunnen één voor één gespecificeerd worden om fouten of andere problemen op te sporen. Met de instellingen van hierboven zal ppp loggen naar /var/log/ppp.log. Die log zal, net als de man pagina, alle nuttige informatie bevatten.
In sommige situaties wil u misschien commando's uitvoeren terwijl uw verbinding gemaakt of verbroken wordt. Er zijn twee bestanden die u kan aanmaken precies voor deze situaties: /etc/ppp/ppp.linkup en /etc/ppp/ppp.linkdown. Voorbeeldconfiguraties kunt u hier bekijken:
Vele ISP's bieden nu xDSL diensten aan, die sneller zijn dan traditionele inbelmethodes. Dit omvat varianten zoals ADSL en SDSL. Hoewel er geen fysisch bellen plaatsvindt, is de verbinding nog steeds gebaseerd op het Point to Point Protocol. Voorbeelden zijn:
Het Point to Point Protocol over Ethernet (PPPoE) is een methode om PPP pakketten in Ethernet frames te versturen. Het Point to Point Protocol over ATM (PPPoA) wordt typisch gedraaid op ATM netwerken, zoals die in het VK en België.
Typisch betekent dit dat u een verbinding met uw ISP kan maken door een standaard Ethernet kaart en Ethernet-gebaseerde DSL modem te gebruiken (in tegenstelling tot een enkel-USB modem).
Als u een modem hebt die PPPoE/PPPoA spreekt, is het mogelijk om de modem in te stellen om het verbinden te doen. Als alternatief, indien de modem een `bridge' modus heeft, is het mogelijk om deze in te schakelen en de modem de pakketten te laten "passeren" naar een machine die PPPoE software draait.
De voornaamste software interface tot PPPoE/PPPoA op OpenBSD is pppoe(8), een userland implementatie (nogal gelijkaardig aan hoe we ppp(8) hierboven beschreven hebben). Een kernel PPPoE implementatie, pppoe(4), werd in OpenBSD ingevoerd.
Het Point to Point Tunneling Protocol (PPTP) is een proprietair Microsoft protocol. Een pptp client is beschikbaar, die interfacet met pppd(8) en kan verbinden met de PPTP-gebaseerde Virtual Private Networks (VPN) gebruikt door sommige kabel en xDSL providers. pptp zelf moet geïnstalleerd worden vanuit packages of ports. Verdere instructies over het instellen en het gebruiken van pptp zijn beschikbaar in de man pagina die samen met het pptp package geïnstalleerd wordt.
U gebruikt dit normaal om rekening te houden met routerings- of verbindingsproblemen. Natuurlijk, om het meest effectief te zijn, moeten beide uiteinden van de verbinding gelijkaardige waarden gebruiken.
Om dit te tweaken, gebruikt u sysctl en verhoogt u de waarden van:
net.inet.tcp.keepinittime
net.inet.tcp.keepidle
net.inet.tcp.keepintvl
Met sysctl -a kan u de huidige waarden van deze (en vele andere) parameters bekijken. Om er een te veranderen, doet u iets als sysctl net.inet.tcp.keepidle=28800.
Normaal gezien wil u dit niet doen. Dit laat toe dat iemand verkeer naar het broadcast adres(sen) van uw verbonden netwerk(en) stuurt indien u OpenBSD gebruikt als een router.
Er zijn enkele gevallen, in gesloten netwerken, waarin dit nuttig zou kunnen zijn, vooral wanneer er oudere implementaties van het NetBIOS protocol in gebruik zijn. Dit is nog een andere sysctl. sysctl net.inet.ip.directed-broadcast=1 zet dit aan. Lees over smurf aanvallen als u wil weten waarom dit standaard is uitgeschakeld.
Ook hiervoor is er een sysctl. Uit
sysctl(8):
Set the list of reserved TCP ports that should not be allocated by the
kernel dynamically. This can be used to keep daemons from stealing a
specific port that another program needs to function. List elements may
be separated by commas and/or whitespace.
# sysctl net.inet.tcp.baddynamic=749,750,751,760,761,871
It is also possible to add or remove ports from the current list.
# sysctl net.inet.tcp.baddynamic=+748
# sysctl net.inet.tcp.baddynamic=-871
net.inet.tcp.recvspace
net.inet.tcp.sendspace
NFS, of Network File System, wordt gebruikt om bestandssystemen over het netwerk te delen. Hier zijn een aantal aangewezen man pagina's om te lezen alvorens een NFS server op te zetten:
Deze sectie zal de stappen doorlopen voor een eenvoudige setup van NFS. Dit voorbeeld behandelt de server in een LAN, met clients die NFS gebruiken in deze LAN. Beveiliging van NFS wordt hier niet behandeld. We gaan er van uit dat u al pakket filtering of andere firewall bescherming hebt opgezet, om toegang van buitenaf te beletten. Als u toegang van buitenaf tot uw NFS server toelaat, en er staat gevoelige informatie op, dan raden we ten zeerste aan dat u IPsec gebruikt. Anders kunnen mensen mogelijk uw NFS verkeer te zien krijgen. Iemand zou zich ook kunnen voordoen als het IP adres dat u toelaat tot uw NFS server. Er zijn verscheidene aanvallen mogelijk. Wanneer het goed geconfigureerd is, beschermt IPsec tegen deze soort aanvallen.
Een andere belangrijke bemerking omtrent beveiliging. Voeg niet gewoon een bestandssysteem toe aan /etc/exports zonder een soort lijst van toegelaten host(s). Zonder een lijst van hosts die een bepaalde directory kunnen mounten, kan iedereen die uw host kan bereiken, zomaar uw NFS exports mounten.
portmap(8) moet draaien opdat NFS zou kunnen werken. Portmap(8) is standaard uitgeschakeld op OpenBSD, dus u moet deze lijn
portmap=YES
# /usr/sbin/portmap
De instelling bestaat uit een server met als IP 10.0.0.1. Deze server zal NFS aanbieden enkel aan clients binnen dat netwerk. De eerste stap om NFS in te stellen is om uw /etc/exports bestand in te stellen. Dit bestand bevat een lijst van bestandssystemen waartoe u via NFS toegang wenst en definieert wie er toegang toe heeft. Er zijn vele opties die u kan gebruiken in uw /etc/exports bestand, en u kan best de exports(5) man pagina lezen. Voor dit voorbeeld ziet onze /etc/exports er als volgt uit:
#
# 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
Dit betekent dat het lokale bestandssysteem /work beschikbaar zal gemaakt worden via NFS. -alldirs geeft aan dat clients op gelijk welk punt onder het /work mount point zullen kunnen mounten. -ro geeft aan dat het enkel zal toegelaten zijn om read-only te mounten. De laatste twee argumenten geven aan dat enkel clients binnen het 10.0.0.0 netwerk met een netmask van 255.255.255.0 geauthoriseerd zullen worden om dit bestandssysteem te mounten. Dit is belangrijk voor sommige servers die langs verschillende netwerken toegankelijk zijn.
Zodra uw /etc/exports bestand ingesteld is, kan u verder gaan met het instellen van uw NFS server. U moet nakijken of de opties NFSSERVER & NFSCLIENT in uw kernel configuratie staan. (GENERIC kernel heeft deze opties inbegrepen.) Vervolgens voegt u de lijn
nfs_server=YES
# /sbin/nfsd -tun 4
U moet niet enkel de nfsd(8) server opstarten, maar u moet ook mountd(8) opstarten. Dit is de daemon die werkelijk de mount requests op NFS bedient. Om mountd(8) te starten, zorg ervoor dat een leeg mountdtab bestand bestaat, en start de daemon:
# echo -n >/var/db/mountdtab
# /sbin/mountd
Als u wijzigingen aanbrengt in /etc/exports terwijl NFS reeds draait, moet u mountd hierover inlichten. HUP het gewoon:
# kill -HUP `cat /var/run/mountd.pid`
Van hier af kan u controleren om zeker te zijn dat al deze daemons goed en wel draaien en geregistreerd bij RPC. Om dit te doen, gebruikt u 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
Bij normaal gebruik zijn er nog enkele andere hulpmiddelen die u toelaten om te zien wat er gebeurt met NFS. Eén ervan is showmount(8), dat u kan laten zien wat er momenteel gemount is en door wie. Er is ook nfsstat(8) dat veel uitgebreidere statistieken toont. Om showmount(8) te gebruiken, probeer /usr/bin/showmount -a host. Bijvoorbeeld:
$ /usr/bin/showmount -a 10.0.0.1
All mount points on 10.0.0.1:
10.0.0.37:/work
NFS bestandssystemen worden gemount met mount(8), of meer bepaald, mount_nfs(8). Om een bestandssysteem /work op host 10.0.0.1 te mounten op een lokaal filesysteem /mnt, voert u dit uit (merk op dat u geen IP adres hoeft te gebruiken; mount zoekt hostnamen op):
# mount -o ro -t nfs 10.0.0.1:/work /mnt
Om uw systeem te laten mounten bij het opstarten, voegt u iets als dit toe aan uw /etc/fstab:
10.0.0.1:/work /mnt nfs ro 0 0
Het is belangrijk dat u aan het einde van deze lijn 0 0 gebruikt zodat uw computer bij het starten niet probeert om het NFS filesystem te fsck'en!!!! De andere standaard beveiligingsopties, zoals noexec, nodev en nosuid, worden ook best gebruikt indien ze van toepassing zijn. Bijvoorbeeld:
10.0.0.1:/work /mnt nfs ro,nodev,nosuid 0 0
Op deze manier kunnen devices of setuid programma's op de NFS server geen beveiligingsmaatregelen op de NFS client ondermijnen. Als u geen programma's mount die u verwacht te draaien op de NFS client, voegt u dan noexec toe aan deze lijst.
Een bridge is een verbinding tussen twee of meer afzonderlijke netwerken. In tegenstelling tot een router, worden pakketten door de bridge "onzichtbaar" overgedragen -- logisch gezien lijkt het alsof de twee netwerksegmenten één segment zijn voor knooppunten aan gelijk welke zijde van de bridge. De bridge zal enkel pakketten doorsturen die van het ene naar het andere segment moeten, dus ze bieden onder andere een gemakkelijke manier om in een complex netwerk het verkeer te verlagen en laten toch toe om elk knooppunt indien nodig toegang te verschaffen tot gelijk welk ander knooppunt.
Merk op dat door deze "onzichtbare" aard een interface in een bridge al dan niet een eigen IP adres kan hebben. Als het er een heeft, dan heeft de interface effectief twee werkingsmodi, één als deel van een bridge, de andere als een normale, alleenstaande NIC. Als geen van de interfaces een IP adres heeft, stuurt de bridge netwerkdata door, maar zal van buitenaf niet onderhouden kunnen worden (wat een nuttige eigenschap kan zijn).
Eén van mijn computer rekken bevat een aantal oudere systemen, waarvan geen enkel een ingebouwde 10BASE-TX NIC heeft. Hoewel ze allemaal een AUI of AAUI connector hebben, is mijn voorraad transceivers beperkt tot coax. Een van de machines in dit rek is een OpenBSD-gebaseerde terminal server die altijd aan staat en met het hogesnelheidsnetwerk verbonden is. Door een tweede NIC met een coax poort toe te voegen zal ik deze machine als een bridge naar het coax netwerk kunnen gebruiken.
Dit systeem heeft nu twee NICs, een Intel EtherExpress/100 (fxp0) en een 3c590-Combo kaart (ep0) voor de coax poort. fxp0 is de verbinding met de rest van mijn netwerk en zal dus een IP adres hebben, ep0 zal enkel voor bridging dienen en zal geen IP adres hebben. Machines verbonden met het coax segment zullen communiceren alsof ze op de rest van mijn netwerk zaten. Hoe laten we dit nu gebeuren?
Het bestand hostname.fxp0 bevat de configuratie info voor de fxp0 kaart. Deze machine is ingesteld met DHCP, dus het bestand ziet er als volgt uit:
$ cat /etc/hostname.fxp0
dhcp NONE NONE NONE
Geen verrassingen hier.
De ep0 kaart is een beetje verschillend, zoals u al kon raden:
$ cat /etc/hostname.ep0
up media 10base2
Hier dragen we het systeem op om deze interface te activeren met ifconfig(8) en hem op 10BASE-2 (coax) in te stellen. IP adres of gelijkaardige informatie hoeft voor deze interface niet gespecificeerd te worden. De opties die de ep kaart aanvaardt, staan uitgebreid in de man pagina ervan.
Nu moeten we de bridge instellen. Bridges worden geïnitialiseerd door het bestaan van een bestand met een naam als bridgename.bridge0. Hier is een voorbeeld voor mijn situatie hier:
$ cat /etc/bridgename.bridge0
add fxp0
add ep0
up
Dit zegt: stel een bridge in die bestaat uit de twee NICs, fxp0 en ep0, en activeer ze. Doet het ertoe in welke volgorde de kaarten staan? Neen, onthou dat een bridge heel symmetrisch is -- pakketten stromen in en uit in beide richtingen.
Dat is het! Herstart, en u hebt nu een werkende bridge.
Hou in het achterhoofd dat, door de aard van een bridge, dezelfde gegevens door beide interfaces stromen, zodat u slechts op één interface hoeft te filteren. Uw standaard "Pass all" opdrachten zouden er ongeveer zo kunnen uitzien:
pass in on ep0 all
pass out on ep0 all
pass in on fxp0 all
pass out on fxp0 all
Nu, stel dat ik graag het verkeer dat deze oude machines zien, wil filteren, ik wil dat alleen Web en SSH verkeer ze bereikt. In dit geval zullen we alle verkeer in en uit de ep0 interface laten, maar filteren op de fxp0 interface, gebruik makend van keep state om de antwoordgegevens te behandelen:
# Pass all traffic through ep0
pass in quick on ep0 all
pass out quick on ep0 all
# Block fxp0 traffic
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
Merk op dat deze regelset belet dat er ook maar iets, behalve ingaand HTTP en SSH verkeer, ofwel de bridge ofwel gelijk welk ander knooppunt "erachter" bereikt. Andere resultaten zouden kunnen bekomen worden door op de andere interface te filteren.
Om de bridge die u gemaakt hebt in de gaten te houden en te beheren, gebruikt u het brconfig(8) commando, dat ook kan gebruikt worden om een bridge te maken na het opstarten.
In de verondestelling dat een OpenBSD machine de bron van de bootbestanden
is (dit is NIET vereist), moet uw DHCP server
dhcpd.conf
bestand de volgende lijn bevatten:
filename "pxeboot";
om de DHCP server dit bestand te laten aanbieden aan het bootende werkstation.
Bijvoorbeeld:
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;
}
}
U zal ook de
tftpd(8)
daemon moeten activeren. Dit gebeurt typisch via
inetd(8).
De standaard OpenBSD installatie heeft een voorbeeldlijn in
inetd.conf die het mooi voor u doet:
#tftp dgram udp wait root /usr/libexec/tftpd tftpd -s /tftpboot
waarin het '#' teken eenvoudigweg verwijderd moet worden. Stuur inetd(8)
een -HUP signaal om het /etc/inetd.conf te laten herladen.
tftpd(8) biedt bestanden aan vanuit een welbepaalde directory, in het geval
van deze lijn, is die directory /tftpboot, wat we in dit voorbeeld
zullen gebruiken.
Vanzelfsprekend moet deze directory aangemaakt en bevolkt worden.
Typisch moet u daar slechts enkele bestanden hebben voor PXE booting:
Wanneer uw DHCP en TFTP servers draaien, bent u klaar om het te proberen.
U zal de PXE boot op uw systeem of netwerkkaart moeten activeren;
raadpleeg hiervoor uw systeemdocumentatie.
Zodra u dit ingeschakeld hebt, zou u iets moeten zien dat lijkt op het
volgende:
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] mem[540k 28m a20=on]
disk: hd0*
net: mac 00:e0:c5:c8:cf:e1, ip 192.168.1.76, server 192.168.1.252
>> OpenBSD/i386 PXEBOOT 1.00
boot>
Op dit punt hebt u de standaard OpenBSD boot prompt.
Als u hier gewoon "bsd.rd" typt, zal u het bestand
bsd.rd van de TFTP server afhalen.
>> 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
...
De bsd.rd installatiekernel zal nu opstarten.
CARP is een hulpmiddel om systeemredundantie te helpen bereiken, door meerdere computers onderling een enkele virtuele netwerkinterface te laten aanmaken, zodat als gelijk welke machine faalt, een andere in de plaats kan antwoorden, en/of een graad van belastingsverdeling tussen systemen toe te laten. CARP is een verbetering ten opzichte van de Virtual Router Redundancy Protocol (VRRP) standaard. Het werd ontwikkeld nadat VRRP niet vrij genoeg geacht werd wegens een mogelijk overlappend Cisco patent. Voor meer informatie over de oorsprong van CARP en de juridische problemen omtrent VRRP, bezoekt u alstublieft deze pagina.
Om juridische conflicten te vermijden, ontwierp Ryan McBride (met de hulp van Michael Shalayeff, Marco Pfatschbacher en Markus Friedl) CARP zo dat het fundamenteel verschillend zou zijn. De opname van cryptografie is de meest prominente verandering, maar toch slechts één van de vele.
Hoe het werkt: CARP is een multicast protocol. Het groepeert verscheidene fysische computers samen onder één of meer virtuele adressen. Van deze is één systeem de master en antwoordt op alle pakketten bestemd voor de groep, de andere systemen fungeren als "hot spares". Wat het IP en MAC adres van de lokale fysische interface ook zijn, pakketten verstuurd naar het CARP adres worden teruggezonden met de CARP informatie.
Op configureerbare intervals kondigt de master zijn werking op IP protocol nummer 112 aan. Als de master offline gaat, beginnen de andere systemen in de CARP groep met aankondigen. De host die het vaakst kan aankondigen, wordt de nieuwe master. Wanneer het hoofdsysteem opnieuw on-line komt, wordt het standaard een backup host, als het echter meer wenselijk is om één host altijd master te laten zijn wanneer mogelijk (bv. één host is een snelle Sun Fire V120 en de andere zijn in vergelijking trage SPARCstation IPCs), dan kan u ze zo instellen.
Hoewel hoogredundante en fout-tolerante hardware de nood aan CARP minimaliseert, neemt het deze niet weg. Er bestaat geen hardware fouttolerantie die kan helpen als iemand een stroomkabel uitsnokt, of als uw systeembeheerder in het verkeerde venster reboot typt. CARP maakt het ook gemakkelijker om de patch en reboot cyclus transparant te maken voor gebruikers, en gemakkelijker om een software of hardware upgrade te testen--als het niet werkt, kan u terugvallen op uw "spare" totdat het opgelost is.
Er zijn echter situaties waarin CARP niet zal helpen. Het ontwerp van CARP vereist dat de leden van een groep op hetzelfde fysische subnet zitten met een statisch IP adres, hoewel met de introductie van het carpdev sleutelwoord IP adressen op de fysische interfaces niet langer nodig zijn. Gelijkaardig zullen diensten die een voortdurende verbinding met de server vereisen (zoals SSH of IRC) niet transparant naar het andere systeem overgezet worden--hoewel in dit geval CARP kan helpen met de down-tijd te minimaliseren. CARP op zichzelf synchroniseert geen gegevens tussen toepassingen, dit moet gedaan worden door "alternatieve kanalen" zoals pfsync(4) (voor redundante filtering), het handmatig dupliceren van gegevens tussen machines met rsync, of wat er ook geschikt is voor uw toepassing.
De bediening van CARP staat op twee plaatsen: sysctl(8) en ifconfig(8). Laten we eerst naar de sysctls kijken.
De eerste sysctl, net.inet.carp.allow, definieert of de host überhaupt CARP pakketten behandelt. Dit is duidelijk noodzakelijk om CARP te gebruiken. Deze sysctl is standaard ingeschakeld.
De tweede, net.inet.carp.arpbalance, wordt gebruikt voor load balancing. Als deze functionaliteit is ingeschakeld, voert CARP een "source-hash" uit op het bron-IP van een aanvraag. De hash wordt vervolgens gebruikt om een virtuele host te selecteren uit de beschikbare pool om de aanvraag af te handelen. Dit is standaard uitgeschakeld.
De derde, net.inet.carp.log, logt CARP fouten. Standaard uitgeschakeld.
De vierde, net.inet.carp.preempt schakelt natuurlijke selectie tussen CARP hosts in. De meest geschikte voor de job (dat betekent, het meest frequent kunnen aankondigen) zal master worden. Standaard uitgeschakeld, wat betekent dat een systeem dat geen master is niet zal proberen om (opnieuw) master status te winnen.
Al deze sysctl variabelen zijn gedocumenteerd in sysctl(3).
Voor de rest van de configuratie van CARP, verlaten we ons op ifconfig(8). De CARP-specifieke commando's advbase en advskew hebben te maken met het interval tussen CARP aankondigingen. De formule (in seconden) is advskew gedeeld door 256, vervolgens opgeteld bij advbase. advbase kan gebruikt worden om het netwerkverkeer te verlagen of om langere latentie toe te laten alvorens een backup host overneemt; advskew laat u bepalen welke host master zal zijn zonder veel "failover" vertraging (als dat vereist zou zijn).
Vervolgens stelt pass een wachtwoord in, en stelt vhid het virtuele host identifier nummer van de CARP groep in. U moet een uniek nummer toekennen voor elke CARP groep, zelfs als (voor load balancing doeleinden) ze hetzelfde IP adres delen. CARP is beperkt tot 255 groepen.
Tenslotte specificeert carpdev welke fysische interface bij deze bepaalde CARP groep hoort. Standaard zal gelijk welke interface gebruikt worden die een IP adres in hetzelfde subnet aan de CARP interface heeft toegekend.
Laten we al deze instellingen samenbrengen in een basisconfiguratie. Stel dat u twee identiek geconfigureerde Web servers gebruikt, rachael (192.168.0.5) en pris (192.168.0.6), om een ouder systeem te vervangen dat op 192.168.0.7 stond. De commando's:
rachael# ifconfig carp0 create
rachael# ifconfig carp0 vhid 1 pass tyrell carpdev fxp0 \
192.168.0.7 netmask 255.255.255.0
maken de carp0 interface en geven ze een vhid van 1, een wachtwoord tyrell, en het IP adres 192.168.0.7 met masker 255.255.255.0. Ken fxp0 toe als lidinterface. Om dit blijvend te maken na het herstarten, kan u een /etc/hostname.carp0 bestand aanmaken dat er zo uitziet:
inet 192.168.0.7 255.255.255.0 192.168.0.255 vhid 1 pass tyrell carpdev fxp0
Doe hetzelfde op pris. Welk systeem ook de CARP interface het eerst on-line brengt, zal master zijn (in de veronderstelling dat preempt uitgeschakeld is; het tegengestelde is waar wanneer preempt ingeschakeld is).
Maar stel dat u niet vanaf nul begint met opstellen. Rachael was reeds op haar plaats op het adres 192.168.0.7. Hoe zou u daar omheen werken? Gelukkig kan CARP met deze situatie omgaan. U kent gewoon het adres toe aan de CARP interface en in een CARP groep, zodat het niet nodig is de commando's hierboven te veranderen. Het is gewoonlijk echter netter om voor elk systeem een IP te hebben-- dit maakt individuele monitoring en toegang veel eenvoudiger.
Laten we nog een laag complexiteit toevoegen; we willen dat rachael wanneer mogelijk master blijft. Er zijn verscheidene redenen waarom we dit zouden kunnen willen: hardwareverschillen, eenvoudig vooroordeel, "als dit systeem geen master is, is er een probleem," of de standaard master kennen zonder met scripts de uitvoer van ifconfig te verwerken en via e-mail te versturen.
Op rachael zullen we de sysctl gebruiken die we hoger aangemaakt hebben, en vervolgens /etc/sysctl.conf bewerken om het blijvend te maken.
rachael# sysctl net.inet.carp.preempt=1
We zullen ook op pris de configuratie doen:
pris# ifconfig carp0 advskew 100
Dit vertraagt lichtjes de aankondigingen van pris, wat betekent dat rachael master zal zijn indien levend.
Merk op dat indien u PF gebruikt op een ge-CARPte computer, u "proto carp" moet meegeven aan alle betrokken interfaces, met een lijn gelijkaardig aan:
pass on fxp0 proto carp keep state
Blik enkele maanden vooruit. Ons bedrijf uit het voorgaande voorbeeld is gegroeid tot op het punt waar een enkele interne Web server het maar net redt onder de belasting. Wat te doen? CARP ter hulp. Het is tijd om load balancing uit te proberen. Creëer een nieuwe CARP interface en groep op rachael:
rachael# ifconfig carp1 create
rachael# ifconfig carp1 vhid 2 advskew 100 pass bryant carpdev fxp0 \
192.168.0.7 netmask 255.255.255.0
Ook op pris zullen we de nieuwe groep en interface aanmaken, en vervolgens de "preempt" sysctl instellen:
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
Nu hebben we twee CARP groepen met hetzelfde IP adres. Elke groep wordt naar een verschillende host gedraaid, wat betekent dat rachael master zal blijven van de oorspronkelijke groep, maar pris zal de nieuwe overnemen.
Al wat we nu nog moeten doen is op beide machines de sysctl voor load balancing inschakelen die we voorheen besproken hebben:
# sysctl net.inet.carp.arpbalance=1
Hoewel dit voorbeelden zijn voor een twee-machine cluster, zijn dezelfde principes van toepassing op meer systemen. Bemerk echter alstublieft, dat er niet verwacht wordt dat u perfect 50/50 verdeling zal bekomen tussen de twee machines--CARP gebruikt een hash van het bron-IP adres om te bepalen welk systeem de aanvraag afhandelt, veeleer dan volgens belasting.
OpenNTPD is een poging om sommige van deze problemen op te lossen, door een triviaal te beheren, veilige en eenvoudige NTP-compatibele manier te voorzien om op uw computer over nauwkeurige tijd te beschikken. OpenBSD's ntpd(8) wordt beheerd met een eenvoudig te begrijpen configuratiebestand, /etc/ntpd.conf.
Gewoon ntpd(8) activeren via rc.conf.local zal ertoe leiden dat de klok van uw computer traag naar de pool.ntp.org servers, een verzameling publiek beschikbare tijdservers. toe evolueert, en vervolgens zichzelf ermee gesynchroniseerd houdt. Zodra uw klok nauwkeurig gezet is, zal ntpd ze op een hoge nauwkeurigheidsgraad houden, als uw klok echter meer dan enkele minuten verkeerd staat, wordt het ten zeerste aanbevolen dat u ze eerst ongeveer juist zet, aangezien het dagen of weken kan duren om een heel verkeerde klok te synchroniseren. U kan dit doen met de "-s" optie van ntpd(8) of gelijk welke andere manier om uw systeemklok nauwkeurig in te stellen.
Er zijn toepassingen waarbij de ntp.org ntpd meer gepast is; er wordt echter vastgesteld dat voor een grote meerderheid van de gebruikers OpenNTPD meer dan voldoende is.
Een meer volledig antwoord hierop door een van de maintainers van OpenNTPD kan hier gelezen worden.
Het kan gebeuren dat wanneer uw ntpd(8) luistert, andere machines er nog steeds niet mee kunnen synchroniseren! Een pas opgestarte ntpd(8) daemon (als u hem bijvoorbeeld net hebt herstart na het wijzigen van ntpd.conf) weigert tijdsinformatie aan te bieden aan andere clients totdat hij eerst zijn eigen klok tot een redelijk niveau van stabiliteit heeft aangepast. Wanneer ntpd(8) zijn eigen tijdsinformatie stabiel beschouwt, kondigt hij dit aan met een "clock now synced" bericht in /var/log/daemon. Zelfs als de systeemklok in het begin vrij nauwkeurig is, kan het tot 10 minuten duren om gesynchroniseerd te geraken, en uren of dagen als de klok bij het begin niet nauwkeurig ingesteld is.
Adapters gebaseerd op deze chips kunnen gebruikt worden zoals gelijk welke andere netwerkadapter om een OpenBSD systeem met een bestaand draadloos netwerk te verbinden, en worden geconfigureerd met ifconfig(8) (kijk alstublieft in de manual pagina's voor details). Sommige van deze kaarten kunnen ook in de "Host-Based Access Point" mode gebruikt worden, wat hen toelaat om een draadloos toegangspunt te vormen voor uw netwerk als onderdeel van uw firewall.
Merk op dat om bepaalde van deze kaarten te gebruiken, u de firmwarebestanden moet bekomen, waarvan de fabrikanten de vrije verspreiding weigeren toe te laten, zodat ze niet in OpenBSD kunnen opgenomen worden. Wanneer het mogelijk is, bevatten de man pagina's waarnaar hierboven verwezen wordt, contactinformatie zodat u de juiste mensen bij de fabrikanten kan contacteren om hen te laten weten wat u hierover denkt, of om hen te laten weten welk ander product u in de plaats hebt gekocht.
Een andere mogelijkheid om te overwegen om uw OpenBSD-gebaseerde firewall draadloze toegang te laten voorzien, is om een conventionele NIC en een extern bridging Access Point te gebruiken. Dit heeft het bijkomend voordeel dat het u toelaat om gemakkelijk de antenne te plaatsen waar die het meest effectief is, wat meestal niet direct aan de achterzijde van uw firewall is.
Gelijke-kost multipath routering verwijst naar het hebben van meerdere routes in de routeringstabel voor hetzelfde netwerk, zoals de standaardroute, 0.0.0.0/0. Wanneer de kernel een route opzoekt om te bepalen naar waar hij pakketten moet verzenden die bestemd zijn voor dat netwerk, kan hij gelijk welke van de gelijke-kost routes kiezen. In de meeste scenario's wordt multipath routering gebruikt om redundante uplinkverbindingen aan te bieden, bv. redundante verbindingen naar het Internet.
Het route(8) commando wordt gebruikt voor het toevoegen/wijzigen/verwijderen van routes in de routeringstabel. Het -mpath argument wordt gebruikt voor het toevoegen van multipath routes.
# route add -mpath default 10.130.128.1
# route add -mpath default 10.132.0.1
Verifieer de routes:
# netstat -rnf inet | grep default
default 10.130.128.1 UGS 2 134 - fxp1
default 10.132.0.1 UGS 0 172 - fxp2
In dit voorbeeld kunnen we zien dat één standaard route wijst naar 10.130.128.1, dat toegankelijk is via de fxp1 interface, en de andere route wijst naar 10.132.0.1, dat toegankelijk is via fxp2.
Aangezien het mygate(5) bestand nog geen multipath standaard routes ondersteunt, moeten de bovenstaande commando's toegevoegd worden onderaan de hostname.if(5) bestanden voor de fxp1 en fxp2 interfaces. Het /etc/mygate bestand moet dan verwijderd worden.
Vergeet tenslotte niet het gebruik van multipath routes te activeren door de juiste sysctl(3) variabele in te schakelen.
# sysctl net.inet.ip.multipath=1
# sysctl net.inet6.ip6.multipath=1
Zorg ervoor dat u sysctl.conf(5) aanpast om de wijzigingen blijvend te maken.
Probeer nu een traceroute naar verschillende bestemmingen. De kernel zal het verkeer balanceren over elke multipath route.
# 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
Voor meer informatie over hoe de route gekozen wordt, raadpleegt u RFC2992, "Analysis of an Equal-Cost Multi-Path Algorithm".
Het loont de moeite om te noteren dat als een interface die gebruikt wordt door een multipath route, uitvalt (dus haar draaggolf verliest), de kernel nog steeds pakketten zal proberen door te sturen die de route gebruiken die naar die interface wijst. Dit verkeer gaat natuurlijk op in het niets en gaat nergens naartoe. Het wordt sterk aanbevolen om ifstated(8) te gebruiken om te controleren op onbeschikbare interfaces en de routeringstabel naargelang aan te passen.
[FAQ Index] [Naar Sectie 5 - Het Systeem vanaf Broncode Bouwen] [Naar Sectie 7 - Toetsenbord en Scherm Bediening]
![[terug]](../../images/back.gif){kind=small}
www@openbsd.org