[OpenBSD]

[FAQ Index] [Naar Sectie 5 - Het Systeem vanaf Broncode Bouwen] [Naar Sectie 7 - Toetsenbord en Scherm Bediening]

6 - Netwerken


Inhoudsopgave


6.1 - Voor we verder gaan

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.

6.2 - Netwerkconfiguratie

Normaal gezien wordt OpenBSD initieel geconfigureerd door het installatieproces. Het is echter goed te begrijpen wat er tijdens dat proces gebeurt en hoe het werkt. Alle netwerkconfiguratie gebeurt met eenvoudige tekstbestanden in de /etc directory.

6.2.1 - Identificeren en instellen van uw netwerkinterfaces

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 33200
        priority: 0
        groups: lo
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet 127.0.0.1 netmask 0xff000000
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:04:ac:dd:39:6a
        priority: 0
        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
enc0: flags=0<>
        priority: 0
        groups: enc
        status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33200
        priority: 0
        groups: pflog

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:

Overige virtuele interfaces worden automatisch aangemaakt als ze nodig zijn, waaronder:

Interfaces worden tijdens het opstarten geconfigureerd met de /etc/hostname.if bestanden, waarbij if wordt vervangen door de volledige naam van iedere interface en iedere interface zijn eigen bestand heeft. In het bovenstaande voorbeeld zou het bestand /etc/hostname.fxp0 worden gebruikt.

De layout van dit bestand is eenvoudig:

address_family address netmask broadcast [andere opties]
Veel meer details over het formaat van dit bestand vindt u terug in de hostname.if(5) man pagina. U zal deze moeten lezen voor minder triviale configuraties.

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

6.2.2 - Standaard gateway

Zet het IP adres van uw gateway in het bestand /etc/mygate. Dit zal toelaten dat uw gateway ingesteld wordt bij het opstarten. Dit bestand bestaat uit één lijn, met alleen het adres van de gateway van deze machine:
10.0.0.1
Het is mogelijk om daar een symbolische naam te gebruiken, maar wees voorzichtig: u kan niet veronderstellen dat dingen zoals de vertaler ("resolver") volledig geconfigureerd of zelfs bereikbaar zijn tot NADAT de standaard gateway geconfigureerd is. Met andere woorden: het kan maar beter een IP adres zijn of iets dat gedefinieerd is in het /etc/hosts bestand.

6.2.3 - DNS vertaling

DNS vertaling wordt beheerd door het /etc/resolv.conf. bestand. Hier is een voorbeeld van een /etc/resolv.conf bestand:
search example.com
nameserver 125.2.3.4
nameserver 125.2.3.5
lookup file bind
In dit geval zal de standaard domeinnaam example.com zijn, er zijn twee DNS "resolvers", 125.2.3.4 en 124.2.3.5, gespecificeerd, en het /etc/hosts bestand zal geraadpleegd worden vóór de DNS vertalers.

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).

6.2.4 - Host naam

Elke Unix machine heeft een naam. In OpenBSD wordt de naam gespecificeerd als een "Fully Qualified Domain Name" (FQDN) in één lijn in het bestand /etc/myname. Indien deze machine "puffy" heet en in het domein "example.com" zit, dan zou het bestand deze ene lijn bevatten:
puffy.example.com

6.2.5 - Activating the changes

Vanaf hier kunt u ofwel herstarten of het /etc/netstart script uitvoeren. U kan dit doen door gewoon het volgende (als root) in te typen:
# 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.

6.2.6 - Routes nakijken

U kan uw routes nakijken via netstat(1) of route(8). Als u routeringsproblemen hebt, kunt u de -n vlag van route(8) gebruiken, die de IP adressen weergeeft, veeleer dan een DNS lookup te doen en de hostname weer te geven. Hier is een voorbeeld van het bekijken van uw routeringstabellen met beide programma's.
$ 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

6.2.7 - Uw OpenBSD machine instellen als een forwarding gateway

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. Dit wordt vaak gedaan met statische routes, maar meer geavanceerde netwerken kunnen gebruik maken van een ruime verzameling routing daemons die onderdeel zijn van OpenBSD om routes door te geven aan andere systemen. Dit zijn onder andere: OpenBGPD, ospfd(8), ospf6d(8), ldpd(8) en ripd(8). Aanvullend daarop bevat de ports collectie software als bird, igmpproxy en quagga. OpenBSD ondersteunt diverse T1, HSSI, ATM, FDDI en seriële (PPP/SLIP) interfaces en uiteraard vele Ethernet apparaten (inclusief 10Gb).

6.2.8 - Aliassen instellen op een interface

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 NONE 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
(maar opnieuw wordt herstarten aanbevolen om uzelf ervan te verzekeren dat u alles hebt ingegeven zoals u verwachtte!)

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

6.3 - Hoe filter en firewall ik met OpenBSD?

Packet Filter (voortaan PF genoemd) is OpenBSD's systeem om IP verkeer te filteren en om Network Address Translation te doen. PF kan ook IP verkeer normaliseren en conditioneren, en bandbreedtecontrole voorzien en pakketvoorrang regelen. Het kan gebruikt worden om krachtige en flexibele firewalls te maken. Het wordt beschreven in de PF Gebruikersgids.

6.4 - Dynamic Host Configuration Protocol (DHCP)

Dynamic Host Configuration Protocol is een manier om netwerk interfaces "automatisch" te configureren. OpenBSD kan een DHCP server zijn (die andere machines configureert), een DHCP client (geconfigureerd door een andere machine), en in sommige gevallen kan het beide zijn.

6.4.1 - DHCP Client

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 host-name 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
Nu zou uw resolv.conf(5) aan het einde "lookup file bind" moeten bevatten.
nameserver 192.168.1.1
nameserver 192.168.1.2
lookup file bind

6.4.2 - DHCP Server

Als u OpenBSD als een DHCP server dhcpd(8), wil gebruiken, bewerk dan /etc/rc.conf.local zodat het de regel dhcpd_flags="" bevat. Bijvoorbeeld:

     # echo 'dhcpd_flags=""' >>/etc/rc.conf.local
Dit zorgt ervoor dat dhcpd wordt gestart en zich verbindt met alle NIC's met een geldige configuratie in /etc/dhcpd.conf. U kunt individuele interfaces opgeven in plaats van ze allemaal te gebruiken door ze expliciet te noemen, bijvoorbeeld dhcpd_flags="xl1 xl2 xl3".

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:

     # /etc/rc.d/dhcpd start
     dhcpd(ok)
Als er fatale configuratiefouten zijn, dan zal het afsluiten en u laten weten dat starten niet is gelukt ("dhcpd(failed)"). De reden staat vermeld in /var/log/messages.

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.

6.5 - PPP

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 PPP(8)

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.

PPP(8) gebruiken

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.

ppp(8) extra's

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:

ppp(8) variaties

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:

PPPoE/PPPoA

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.

PPTP

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.

6.6 - Netwerkparameters tunen

Eén van de doelstellingen van OpenBSD is dat het systeem Gewoon Werkt voor de overgrote meerderheid van onze gebruikers. Aan knoppen draaien die u niet begrijpt zal veel waarschijnlijker het systeem breken dan dat het de prestaties ervan zal verbeteren. Begin steeds met de standaardinstellingen en pas alleen dingen aan waarmee u werkelijk een probleem ziet.

ZEER WEINIG mensen zullen een netwerkparameter hoeven aan te passen!

6.6.1 - Ik wil niet dat de kernel dynamisch een bepaalde poort toewijst

Vertaald uit sysctl(8):

Om de lijst van gereserveerde TCP-poorten in te stellen die niet dynamisch
door de kernel toegewezen mogen worden:
 
      # sysctl net.inet.tcp.baddynamic=749,750,751,760,761,871
 
Dit kan worden gebruikt om te voorkomen dat daemons een specifieke poort
innemen die een ander programma nodig heeft om te functioneren.
Lijstelementen kunnen door komma's en/of whitespace worden gescheiden.
 
Het is ook mogelijk om poorten toe te voegen of te verwijderen van de lijst:
 
      # sysctl net.inet.tcp.baddynamic=+748
      # sysctl net.inet.tcp.baddynamic=-871

6.7 - Eenvoudig NFS gebruik

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 NFS server instellen

Deze diensten moeten ingeschakeld worden en draaien op de server:

Standaard zijn deze in OpenBSD allemaal uitgeschakeld. Voeg de volgende lijnen toe aan rc.conf.local(8) om ze in te schakelen:

portmap_flags=""
mountd_flags=""
nfsd_flags="-tun 4"

De volgende stap is het configureren van een lijst van bestandssystemen die beschikbaar zullen worden gesteld aan clients om te mounten.

In dit voorbeeld hebben we een server met IP adres 10.0.0.1. Deze server zal NFS aanbieden alleen aan clients in zijn eigen subnet. Dit wordt allemaal geconfigureerd in het /etc/exports bestand. Dit bestand bevat een lijst van bestandssystemen die u toegankelijk wenst te maken via NFS en definieert wie er toegang tot heeft. Er zijn veel opties die u kan gebruiken in /etc/exports; het beste is dat u de exports(5) man pagina leest. Voor onze voorbeeldserver hebben we een exports bestand ingesteld dat er als volgt uitziet:

#
# 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. De -alldirs optie geeft aan dat clients op gelijk welk punt onder het /work mount point zullen kunnen mounten, maar ook op /work zelf. Als er bijvoorbeeld een directory was met de naam /work/monday, dan zouden clients /work kunnen mounten (en toegang hebben tot alle bestanden/directories onder die directory) of ze zouden /work/monday kunnen mounten en enkel toegang hebben tot de bestanden/directories die daarin zitten. De -ro optie geeft aan dat clients alleen read-only toegang zullen krijgen. 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.

Een andere belangrijke opmerking 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.

Nu kan u de serverdiensten opstarten. U kan ofwel herstarten (na ze ingeschakeld te hebben zoals in de instructies hierboven) of ze manueel opstarten.

# /etc/rc.d/portmap start
# /etc/rc.d/mountd start
# /etc/rc.d/nfsd start

De nfsd_flags schakelen TCP (-t) en UDP (-u) verbindingen in en zorgen dat er 4 instanties (-n) van nfsd draaien. U kunt het best een gepast aantal NFS server instanties instellen om het maximale aantal gelijktijdige client verzoeken die u wil bedienen af te handelen, door de nfsd_flags regel in rc.conf.local aan te passen.

U bent nu klaar om de geëxporteerde bestandssystemen te mounten vanaf de client(s).

Onthou: als u wijzigingen aanbrengt in /etc/exports terwijl NFS reeds draait, dan moet u mountd hierover inlichten! HUP gewoon mountd en de wijzigingen vinden plaats.

# /etc/rc.d/mountd reload

NFS bestandssystemen mounten

NFS bestandssystemen kunnen vanaf een client gemount worden zonder diensten of daemons in te schakelen. Ze kunnen net zoals gelijk welk ander bestandssysteem gemount worden.

NFS bestandssystemen moeten gemount worden via mount(8), of meer bepaald mount_nfs(8). Om een bestandssysteem /work op host 10.0.0.1 te mounten naar een lokaal bestandssysteem /mnt, doet u dit (merk op dat het niet nodig is een IP adres te gebruiken; mount zal hostnamen vertalen):

# mount -t nfs 10.0.0.1:/work /mnt

Om ervoor te zorgen dat dat bestandssysteem bij het opstarten gemount wordt, voegt u iets als dit toe in /etc/fstab:

10.0.0.1:/work /mnt nfs rw 0 0

Het is belangrijk dat u 0 0 gebruikt aan het einde van deze lijn zodat uw computer het NFS bestandssysteem bij het opstarten niet probeert te fsck'en. De andere standaard beveiligingsopties, zoals noexec, nodev en nosuid moeten hier ook gebruikt worden waar ze toepasselijk zijn. Bijvoorbeeld:

10.0.0.1:/work /mnt nfs rw,nodev,nosuid 0 0

Op deze manier kunnen devices of setuid programma's op de NFS server de beveilingsmaatregelen op de NFS client niet tenietdoen. Als u geen programma's mount die u verwacht te draaien op de NFS client, voegt u noexec toe aan deze lijst.

Wanneer u toegang verkrijgt tot een NFS mount als de root-gebruiker, vertaalt de server automatisch root's toegang naar gebruikersnaam "nobody" en groep "nobody". Dit is belangrijk om te weten bij bestandspermissies. Neem bijvoorbeeld een bestand met deze permissies:

-rw-------    1 root     wheel           0 Dec 31 03:00 _daily.B20143

Als dit bestand op een NFS share zat en de root-gebruiker probeerde toegang te krijgen tot dit bestand vanaf de NFS client, dan zou dat geweigerd worden. Dit is zo omdat de server de gebruiker "nobody" gebruikt wanneer root probeert toegang te krijgen tot dat bestand. Aangezien de gebruiker nobody geen permissies heeft voor dat bestand, wordt de toegang geweigerd.

De gebruiker en groep waarnaar root vertaald wordt, zijn configureerbaar via het exports(5) bestand op de NFS server.

Statistieken over NFS nakijken

Eén ding om na te kijken om te verzekeren dat NFS juist werkt is dat alle diensten juist geregistreerd zijn 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(1) 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

Deze uitvoer toont dat de client 10.0.0.37 de /work export gemount heeft die aangeboden wordt vanaf de server op 10.0.0.1.

6.9 - Een netwerk bridge opzetten in OpenBSD

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).

Een eenvoudig voorbeeld van een bridge toepassing

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 hostname.bridge0. Hier is een voorbeeld voor mijn situatie hier:

$ cat /etc/hostname.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.

Een bridge die werkt als een DHCP server

Stel dat we een klein systeem hebben met vier vr(4) interfaces, vr0 tot en met vr3. We willen vr1, vr2 and vr3 instellen als een bridge, waarbij we vr0 gebruiken als uplink (bijvoorbeeld een kabelmodem). We willen ook IP adressen uitdelen met DHCP via de gebridgde interfaces. De doos moet een IP adres op het gebridgde netwerk hebben, aangezien hij DHCP server is en de router naar de buitenwereld (in tegenstelling tot het voorgaande voorbeeld waarbij de bridge niet zichtbaar was op het netwerk).

Het is niet mogelijk om een IP adres rechtstreeks toe te kennen aan een bridge(4) interface. Het IP adres zou aan één van de onderliggende interfaces toegekend moeten worden, maar we kunnen geen fysieke interface gebruiken aangezien de link down kan zijn, waarbij het adres niet bereikbaar zou zijn. Gelukkig is er sinds OpenBSD 4.7 een virtuele Ethernet interface driver vether(4) die we kunnen gebruiken voor ons doel. We zullen deze interface toevoegen aan de bridge, een IP adres toekennen en dhcpd(8) laten luisteren op dit adres.

Opmerkingen:

Zorg dat vr1, vr2 en vr3 up zijn:

$ cat /etc/hostname.vr1
up
$ cat /etc/hostname.vr2
up
$ cat /etc/hostname.vr3
up

Configureer vervolgens vether0:

$ cat /etc/hostname.vether0
inet 192.168.1.1 255.255.255.0 192.168.1.255
up

Configureer de bridge interface zodanig dat deze alle genoemde interfaces bevat:

$ cat /etc/hostname.bridge0
add vether0
add vr1
add vr2
add vr3
up

En laat tenslotte dhcpd(8) luisteren op de vether0 interface:

$ grep ^dhcpd_flags= /etc/rc.conf.local
dhcpd_flags="vether0"

Herstart en voilà!

Filteren op een bridge

Hoewel een eenvoudige bridge als deze zeker nuttig kan zijn, is het waarschijnlijk dat u iets wil DOEN met de pakketten wanneer ze doorheen uw bridge gaan. Zoals u kon verwachten, kan Packet Filter gebruikt worden om beperkingen op te leggen aan het verkeer dat doorheen uw bridge gaat.

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 ifconfig(8) commando, dat ook kan gebruikt worden om een bridge te maken na het opstarten.

Tips voor bridging

6.10 - Hoe boot ik met PXE? (i386, amd64)

De Preboot Execution Environment, of PXE, is een manier om een computer te starten via het netwerk, veeleer dan via een harde schijf, een diskette of een CD-ROM. De technologie werd aanvankelijk ontwikkeld door Intel, maar wordt nu door de meeste grote netwerkkaart- en computerfabrikanten ondersteund. Merk op dat er verschillende netwerk bootprotocols zijn, PXE is relatief recent. Traditioneel gebeurt PXE booting met ROMs op de NIC of het moederbord van het systeem, maar er zijn via verschillende bronnen bootdiskettes beschikbaar, die ook PXE booting toelaten. Veel ROMs op oudere NICs ondersteunen netwerk booting maar ondersteunen PXE NIET; OpenBSD/i386 of amd64 kan momenteel door deze kaarten niet via het netwerk gestart worden.

Hoe werkt PXE booting?

Eerst en vooral is het verstandig om te begrijpen hoe OpenBSD start op i386 en amd64 platformen. Bij aanvang van het bootproces, broadcast de PXE-capabele NIC een DHCP request over het netwerk. De DHCP server zal de adapter een IP adres toekennen, en geeft hem een bestandsnaam die via een tftp(1) server moet teruggevonden worden en uitgevoerd. Dit bestand leidt dan de rest van het boot proces. Voor OpenBSD is dit bestand pxeboot, dat de plaats inneemt van het standaard boot(8) bestand. pxeboot(8) kan dan een kernel inladen en uitvoeren (zoals bsd of bsd.rd) vanaf dezelfde tftp(1) server.

Hoe doe ik het?

De eerste vanzelfsprekende stap is dat u een PXE-boot capabele computer of netwerkadapter moet hebben. Sommige documentatie zal aangeven dat alle moderne NICs en computers PXE capabel zijn, maar dit is duidelijk niet waar -- veel goedkope systemen bevatten geen PXE ROMs of gebruiken een ouder netwerk boot protocol. U hebt ook een netjes geconfigureerde DHCP en TFTP server nodig.

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 door "tftpd_flags=/tftpboot" toe te voegen aan uw /etc/rc.conf.local bestand. 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:

Merk op dat /etc/boot.conf enkel nodig is als de kernel die u wenst te starten niet bsd heet, of als de andere pxeboot standaardwaarden niet zijn wat u nodig hebt (u wenst bijvoorbeeld een seriële console te gebruiken). U kan uw tftpd(8) server testen met een tftp(1) client, en nagaan of u de nodige bestanden kan afhalen.

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 3.19
    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 3.19
    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-2013 OpenBSD.  All rights reserved.  http://www.OpenBSD.org

    OpenBSD 5.4 (RAMDISK_CD) #34: Tue Jul 30 12:20:01 MDT 2013
      ...
De bsd.rd installatiekernel zal nu opstarten.

Kan ik behalve bsd.rd nog andere OpenBSD-kernels starten met PXE?

Ja, hoewel met de tools momenteel in OpenBSD, is PXE booting in eerste instantie bedoeld is om het besturingssysteem te installeren.

6.11 - Het Common Address Redundancy Protocol (CARP)

6.11.1 - Wat is CARP en hoe werkt het?

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.

6.11.2 - Configuratie

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.log, logt CARP status veranderingen, foute packets en andere fouten. Staat standaard op het loggen van status veranderingen.

De derde, 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
Merk op dat tevens het broadcast adres is gespecificeerd naast het vhid en het wachtwoord. Het nalaten hiervan is een veel voorkomende bron van fouten, aangezien het nodig is als een plaatshouder.

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

6.11.3 - Load balancing

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.

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.

6.11.4 - Meer informatie over CARP

6.12 - OpenNTPD gebruiken

Nauwkeurige tijd is belangrijk voor veel computertoepassingen. Veel mensen hebben echter gemerkt dat hun horloge van $5 beter de tijd kan bijhouden dan hun $2000 computer. Bovenop te weten hoe laat het is, is het ook vaak belangrijk om computers te synchroniseren zodat ze het allemaal eens zijn over hoe laat het is. Een tijd lang heeft ntp.org een Network Time Protocol (RFC1305, RFC2030) toepassing geproduceerd, beschikbaar via ports, die kan gebruikt worden om klokken van computers via het Internet te synchroniseren. Het is echter een niet-triviaal programma om in te stellen, het heeft een moeilijke broncode om te controleren, en heeft grote geheugenvereisten. In het kort vervult het een belangrijke rol voor sommige mensen, maar het is verre van een oplossing voor iedereen.

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.

6.12.1 - "Maar OpenNTPD is niet zo nauwkeurig als de ntp.org daemon!"

Dat kan zijn. Dat is niet de ontwerpdoelstelling van OpenNTPD, het is bedoeld om vrij, eenvoudig, betrouwbaar en veilig te zijn. Als u echt microseconde precisie meer nodig hebt dan de voordelen van OpenNTPD, staat het u vrij om ntp.org's ntpd te gebruiken, want deze blijft beschikbaar via ports en packages. Er is geen plan of verlangen om OpenNTPD te overladen met elke denkbare mogelijkheid.

6.12.2 - "Iemand heeft beweerd dat OpenNTPD 'schadelijk' is!"

Sommige mensen hebben de doelstellingen van OpenNTPD niet begrepen -- een eenvoudige, veilige en gemakkelijk te onderhouden manier om de klok van uw computer nauwkeurig te houden. Als het nauwkeurig bijhouden van de tijd belangrijk is: een aantal mensen hebben al betere resultaten met OpenNTPD dan met ntp.org's ntpd gemeld. Als veiligheid belangrijk is: de broncode van OpenNTPD is veel leesbaarder (en dus controleerbaar) en werd geschreven met "native" OpenBSD functie-aanroepen zoals strlcpy, veeleer dan meer portable functies als strcpy, en werd vanaf het begin geschreven om veilig te zijn, niet "achteraf veilig gemaakt". Als het waardevol is om meer mensen tijdssynchronisatie te laten gebruiken, maakt OpenNTPD het veel gemakkelijker voor grotere aantallen mensen om het te gebruiken. Als dit "schadelijk" is, dan zijn we er allemaal voor.

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.

6.12.3 - Waarom kunnen mijn andere machines niet synchroniseren met OpenNTPD?

ntpd(8) luistert standaard op geen enkel adres. Om het als server te gebruiken, moet u de "#listen on *" lijn in /etc/ntpd.conf uit commentaar zetten en de ntpd(8) daemon herstarten. Als u natuurlijk liever op een welbepaald IP adres wil luisteren dan op alle beschikbare adressen en interfaces, vervangt u de "*" door het gewenste adres.

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.

6.13 - Wat zijn mijn draadloze netwerkmogelijkheden?

OpenBSD heeft ondersteuning voor een aantal draadloze chipsets: (AP) geeft aan dat de kaart kan gebruikt worden als access point.
(NFF) geeft aan dat de chip een niet-vrije firmware vereist die niet bij OpenBSD kan gevoegd worden.

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.

Configuren van uw draadloos netwerk

Uw draadloos netwerk kan worden ingesteld met een hostname.if(5) bestand, net als andere netwerk adapters. Maar omdat er meer opties zijn, is het vaak ingewikkelder.

Een voorbeeld van een hostname bestand voor een draadloze interface:

nwid puffyuberalles
wpakey puffyguffy
dhcp
of
inet 10.0.0.157 255.255.255.0
nwid puffyuberalles
wpakey puffyguffy
Merk op dat dhcp NA de andere regels komt, omdat de netwerkkaart pas een DHCP-request kan sturen nadat deze is ingesteld.

Trunk(4)ing van uw draadloos netwerk

Veel laptops hebben zowel een draadloze als een bedrade netwerkaansluiting. Soms bent u rechtstreeks verbonden met uw snelle netwerk en wilt u de volledige performance van de kabel, maar soms wilt u ook draadloos werken. U wilt waarschijnlijk niet uw instellingen wijzigen iedere keer als uw locatie wijzigt.

U KUNT beide interfaces op DHCP zetten, maar dan moet u bij het opstarten op een time-out wachten van de niet-gebruikte aansluiting. Bovendien is dit wat verwarrend als beide netwerkaansluiting beschikbaar zijn en wisselen tussen beide is dan irritant.

Het gebruik van een trunk(4) kan uw leven dan vereenvoudigen. Trunk(4)s zijn virtuele interfaces die zijn samengesteld uit één of meer andere netwerkinterfaces. In dit geval gebruiken we een laptop met een bedrade bge0 en een draadloze iwn0 interface. We gebruiken deze twee interfaces om een virtuele interface, trunk0, op te zetten en vervolgens met DHCP van een IP-adres te voorzien. Als we met een kabel zijn aangesloten willen we deze gebruiken, anders willen we de draadloze interface gebruiken.

Hiervoor stellen we eerst de fysieke interface in. Aangezien we ze alleen maar combineren tot een trunk0 interface, hoeven we voor de bedrade interface niet meer te doen dan hem te activeren:

# cat /etc/hostname.bge0
up
De draadloze interface heeft echter iets meer configuratie nodig. Hij moet worden verbonden met ons draadloos WPA-beveiligd netwerk:
# cat /etc/hostname.iwn0 nwid puffynet wpakey mysecretkey up
Vervolgens definiëren we onze trunk interface als volgt:
# cat /etc/hostname.trunk0 trunkproto failover trunkport bge0 trunkport iwn0 dhcp
De trunk is opgezet in "failover" mode, dus beide interfaces kunnen worden gebruikt, maar als beide beschikbaar zijn heeft bge0 de voorkeur omdat deze als eerste is toegevoegd aan het trunk device.

6.14 - Hoe kan ik gelijke-kost multipath routering doen?

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.

/etc/hostname.fxp1
!route add -mpath default 10.130.128.1
/etc/hostname.fxp2
!route add -mpath default 10.132.0.1

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] www@openbsd.org
$OpenBSD: faq6.html,v 1.80 2013/12/06 20:52:46 ajacoutot Exp $