Hoofdstuk 31. Geavanceerde netwerken

Om de verschillende aspecten van routen te illustreren, wordt het volgende voorbeeld van netstat gebruikt:

De eerste twee regels geven de standaardroute (die behandeld wordt in de volgende sectie) en de localhost-route aan.

De interface (kolom Netif) dat deze routeertabel aangeeft om voor localhost te gebruiken is lo0, ook bekend als het teruglusapparaat. Dit geeft aan dat alle verkeer voor deze bestemming intern gehouden moet worden, in plaats van het over het LAN te sturen, aangezien het alleen aankomt op de plaats waar het verzonden werd.

Het volgende dat opvalt zijn de adressen die beginnen met 0:e0:. Dit zijn Ethernet-hardware adressen, ook bekend als MAC-adressen. FreeBSD zal automatisch elke host (test0 in het voorbeeld) op het lokale Ethernet identificeren en een route voor die host toevoegen, direct van deze host over de Ethernet-interface, ed0. Er is ook een timeout (kolom Expire) met deze routesoort geassocieerd, die gebruikt wordt indien er binnen een bepaalde tijd geen bericht komt van de host. Indien dit gebeurt, wordt de route naar deze host automatisch verwijderd. Deze hosts worden geïdentificeerd door middel van een mechanisme dat bekend staat als RIP (Routing Information Protocol), dat routes naar lokale hosts bepaald door middel van een kortste-pad algoritme.

FreeBSD zal ook subnetroutes voor het lokale subnet toevoegen (10.20.30.255 is het broadcast-adres voor het subnet 10.20.30, en example.com is de domeinnaam die bij dat subnet hoort). De aanduiding link#1 verwijst naar de eerste Ethernetkaart in de machine. Merk op dat voor hen geen aanvullende interface is gespecificeerd.

Voor beide groepen (lokale netwerkhosts en lokale subnetten) worden de routes automatisch ingesteld door een daemon genaamd routed. Indien dit niet draait, zullen alleen routes die statisch gedefinieerd (i.e., expliciet vermeld zijn) bestaan.

De regel met host1 verwijst naar deze host, het kent deze door het Ethernetadres. Aangezien het de zendende host is, weet FreeBSD dat het de teruglus-interface (lo0) moet gebruiken, in plaats van het over de Ethernet-interface te verzenden.

De twee regels met host2 geven een voorbeeld van wat er gebeurt als een alias met ifconfig(8) gebruikt wordt (in de sectie over Ethernet staan redenen waarom dit gedaan wordt). Het symbool ⇒ na de interface lo0 zegt dat niet alleen de teruglus gebruikt wordt (aangezien dit adres ook verwijst naar de lokale host), maar specifiek dat dit een alias is. Zulke routes verschijnen alleen op de hosts die de alias ondersteunen; alle andere hosts op het lokale netwerk vermelden simpelweg een regel met link#1 voor zulke routes.

De laatste regel (bestemming subnet 224) heeft te maken met multicasten, wat in een andere sectie besproken wordt.

Als laatste staan in de kolom Flags verschillende attributen. Hieronder staat een korte tabel met enkele van deze vlaggen en hun betekenis:

Wanneer het lokale systeem een verbinding met een verre host moet maken, controleert het de routeertabel op reeds bekende paden. Indien de verre host binnen een subnet valt waarvan bekend is hoe het bereikt kan worden (gekloonde routes), controleert het systeem of het met de daarbij behorende interface verbinding kan maken.

Indien alle bekende paden falen, heeft het systeem één laatste mogelijkheid: de "standaardroute". Deze route is een speciaal soort gateway-route (gewoonlijk de enig aanwezige in het systeem) en is altijd gemarkeerd met een c in het vlaggenveld. Voor hosts op een LAN staat deze gateway ingesteld op de machine die een directe verbinding met de buitenwereld heeft (via een PPP-verbinding, DSL, kabelmodem, T1, of een ander netwerkinterface).

Indien de standaardroute wordt ingesteld voor een machine die zelf als gateway naar de buitenwereld werkt, zal de standaardroute de gateway-machine van de internetprovider zijn.

Hieronder volgt een voorbeeld van standaardroutes. Dit is een veelgebruikte opstelling:

De hosts Lokaal1 en Lokaal2 staan op deze site. Lokaal1 is verbonden met een internetprovider via een inbel-PPP-verbinding. Deze PPP-server is door een LAN verbonden met een andere gateway-computer door een externe interface naar de Internet-feed van de internetprovider.

De standaardroutes voor de machines zijn:

Een veelvoorkomende vraag is "Waarom (of hoe) moet worden ingesteld dat T1-GW de standaard gateway is voor Lokaal1, in plaats van de server van de internetprovider waarmee het verbonden is?".

Onthoud dat, aangezien de PPP-interface een adres gebruikt op het lokale netwerk van de internetprovider voor deze kant van de verbinding, routes voor alle andere machines op het lokale netwerk van de internetprovider automatisch aangemaakt worden. Daarom is het al bekend hoe de machine T1-GW bereikt kan worden, dus is de tussenstap dat het verkeer eerst naar de server van de internetprovider gestuurd wordt niet nodig.

Het is gebruikelijk om het adres X.X.X.1 te gebruiken als het gateway-adres voor het lokale netwerk. Dus (gebruikmakend van hetzelfde voorbeeld), indien de lokale klasse-C adresruimte 10.20.30 was en de internetprovider 10.9.9 gebruikte, zouden de standaardroutes als volgt zijn:

De standaardroute kan eenvoudig in /etc/rc.conf gedefinieerd worden. In dit voorbeeld werd de volgende regel aan /etc/rc.conf van Lokaal2 toegevoegd:

Het is ook mogelijk dit met het commando route(8) direct vanaf de opdrachtregel te doen:

Voor meer informatie over het handmatig manipuleren van netwerkrouteertabellen kan de hulppagina route(8) geraadpleegd worden.

Er is nog één andere soort opstelling die behandeld dient te worden, en dat is een host die in twee verschillende netwerken zit. Technisch gezien telt elke machine die als gateway dienst doet (in bovenstaand voorbeeld door een PPP-verbinding te gebruiken) als een dual-homed host. Maar de term wordt echt alleen gebruikt om naar een machine te verwijzen die in twee LAN’s zit.

In het ene geval heeft de machine twee Ethernetkaarten, waarbij elke kaart een adres op de gescheiden subnetten heeft. Een alternatief is dat de machine slechts één Ethernetkaart heeft en gebruikt maakt van ifconfig(8) aliasing. Het eerste wordt gebruikt indien er twee fysiek gescheiden Ethernet-netwerken in gebruik zijn, het laatste indien er één fysiek netwerksegment is, maar er twee logisch gescheiden subnetten zijn.

In beide gevallen worden er routeertabellen aangemaakt zodat elk subnet weet dat deze machine de gedefinieerde gateway (ingaande route) naar het andere subnet is. Deze opstelling, waarbij de machine dienst doet als router tussen de twee subnetten, wordt vaak gebruikt voor het implementeren van pakketfilters of firewall-beveiliging in één of beide richtingen.

Om deze machine daadwerkelijk pakketten te laten forwarden tussen de twee interfaces, moet aan FreeBSD verteld worden dat het deze mogelijkheid aan moet zetten. In de volgende sectie staan meer details over hoe dit te doen.

Een netwerkrouter is simpelweg een systeem dat pakketten van de ene naar de andere interface doorstuurt. Internetstandaarden en goede ontwerppraktijken verhinderen het FreeBSD Project dit standaard in FreeBSD aan te zetten. Deze mogelijkheid kan worden aangezet door de volgende variabele in rc.conf(5) op YES in te stellen:

Deze optie stelt de sysctl(8) variabele net.inet.ip.forwarding in op 1. Indien het nodig is om het routen tijdelijk te stoppen, kan deze variabele tijdelijk op 0 worden teruggezet.

De nieuwe router heeft routes nodig om te weten waar het het verkeer naar toe moet sturen. Voor een eenvoudig netwerk kunnen statische routes gebruikt worden. FreeBSD wordt met het standaard BSD routeer-daemon routed(8) geleverd, dat RIP (zowel versie 1 en versie 2) en IRDP spreekt. Ondersteuning voor BGP v4, OSPF v2, en andere slimme routeerprotocollen is beschikbaar via het pakket net/zebra. Ook zijn commerciële producten als GateD® beschikbaar voor complexere netwerkrouteer-oplossingen.

Er is al gesproken over hoe routes naar de buitenwereld te definiëren, maar niet over hoe de buitenwereld ons kan vinden.

Het is al bekend dat routeertabellen aangemaakt kunnen worden zodat al het verkeer voor een bepaalde adresruimte (in ons voorbeeld een klasse-C subnet) naar een bepaalde host op dat netwerk gezonden kan worden, dat de ingaande pakketten doorgeeft.

Wanneer een adresruimte aan een site wordt toegewezen, stelt de serviceprovider al hun routeertabellen zodanig in dat al het verkeer voor het bijhorende subnet naar de PPP-verbinding van de site gezonden wordt. Maar hoe weten sites door het land heen hoe naar de internetprovider van deze site te versturen?

Er bestaat een systeem (dat veel lijkt op de gedistribueerde DNS-informatie) dat alle toegewezen adresruimtes bijhoudt, en hun verbindingspunt met de Internet Backbone definieert. De "Backbone" zijn de grote kabels die Internetverkeer door het land en over de wereld sturen. Elke backbone-machine heeft een kopie van een master-verzameling van tabellen, die verkeer voor een bepaald netwerk naar een bepaalde backbone-carrier sturen, en van daaruit naar een keten van serviceproviders totdat het netwerk van de site bereikt is.

Het is de taak van de serviceprovider om bij de backbone-sites aan te geven dat zij het verbindingspunt (en dus het ingaande pad) zijn voor de site. Dit staat bekend als routepropagatie.

Soms is er een probleem met routepropagatie en kunnen sommige sites geen verbinding maken. Misschien is het nuttigste commando om proberen uit te zoeken waar het routen misgaat traceroute(8). Het is ook nuttig als er geen verbinding mogelijk lijkt met een verre machine (dus als ping(8) faalt).

Het commando traceroute(8) wordt gedraaid met de naam van de verre host waarmee geprobeerd wordt te verbinden. Het laat de gateway-hosts zien langs het gepoogde pad, dat uiteindelijk de doelhost bereikt, of wegens een gebrek aan verbinding afgebroken wordt.

Raadpleeg voor meer informatie de hulppagina voor traceroute(8).

FreeBSD ondersteunt zowel multicast-applicaties als multicast routen van huis uit. Voor multicast-applicaties is geen speciale configuratie van FreeBSD nodig; applicaties draaien over het algemeen als geleverd. Voor multicast routen dient ondersteuning in de kernel gecompileerd te worden:

Ook dient de multicast-routeer-daemon mrouted(8) ingesteld worden zodat het tunnels en DVMRP via /etc/mrouted.conf aanmaakt. Kijk voor meer details over multicast-instellingen in de hulppagina voor mrouted(8).

De meeste draadloze netwerken zijn op de IEEE® 802.11 standaarden gebaseerd. Een eenvoudig draadloos netwerk bestaat uit meerdere stations die met radio’s communiceren die in de 2,4GHz of de 5GHz band uitzenden (alhoewel dit regionaal varieert en het ook verandert om communicatie in de 2,3GHz en de 4,9GHz banden mogelijk te maken).

802.11-netwerken zijn op twee manieren georganiseerd: in infrastructuurmodus treedt één station als meester op, alle andere stations associëren met dit station; dit netwerk staat bekend als een BSS en het meesterstation heet een toegangspunt (AP). In een BSS gaat alle communicatie via het AP; zelfs als een station met een ander draadloos station wil communiceren gaan de boodschappen door het AP. In de tweede netwerkvorm is er geen meester en communiceren de stations direct. Deze netwerkvorm is een IBSS en staat gewoonlijk bekend als een ad-hoc netwerk.

802.11 netwerken begonnen in de 2,4GHz band waarbij gebruik werd gemaakt van protocollen die door de IEEE® 802.11 en 802.11b standaarden worden gedefinieerd. Deze specificaties omvatten de werkfrequenties, karakteristieken van de MAC-lagen waaronder frame- en zendsnelheden (communicatie kan met verschillende snelheden plaatsvinden). Later definieerde de 802.11a-standaard het werken in de 5GHz band, inclusief andere mechanismen voor signalering en hogere zendsnelheden. Nog later werd de 802.11g-standaard gedefinieerd om gebruik te kunnen maken van de signalerings- en zendmechanismen van 802.11a in de 2,4GHz band zodanig dat het met terugwerkende kracht werkt op 802.11b-netwerken.

Afgezien van de onderliggende zendtechnieken beschikken 802.11-netwerken over een verscheidenheid aan beveiligingstechnieken. De originele 802.11-specificaties definieerden een eenvoudig beveiligingsprotocol genaamd WEP. Dit protocol maakt gebruik van een vaste, van te voren gedeelde sleutel en het cryptografische algoritme RC4 om de gegevens die over het netwerk verstuurd worden te coderen. Alle stations dienen dezelfde sleutel te gebruiken om te kunnen communiceren. Het is bewezen dat dit mechanisme eenvoudig te kraken is en wordt nu, afgezien om voorbijgaande gebruikers te ontmoedigen het netwerk te gebruiken, nog zelden gebruikt. De huidige beveiligingsmethoden worden gegeven door de IEEE® 802.11i specificatie dat nieuwe cryptografische algoritmen en een aanvullend protocol om stations aan een toegangspunt te authenticeren en om sleutels voor gegevenscommunicatie uit te wisselen definieert. Verder worden cryptografische sleutels periodiek ververst en zijn er mechanismen om indringpogingen te detecteren (en om indringpogingen tegen te gaan). Een andere specificatie van een veelgebruikt beveiligingsprotocol in draadloze netwerken is WPA. Dit was een voorloper op 802.11i en gedefinieerd door een industriegroep als een tussenmaatregel terwijl er gewacht werd op de ratificatie van 802.11i. WPA specificeert een deel van de eisen van 802.11i en is ontworpen voor implementatie op verouderde hardware. In het bijzonder vereist WPA alleen de TKIP-sleutel die van de originele WEP-sleutel is afgeleid. 802.11i staat het gebruik van TKIP toe maar vereist ook ondersteuning voor een sterkere sleutel, AES-CCM, om gegevens te versleutelen. (De AES-sleutel was niet nodig in WPA omdat het rekenkundig te kostbaar werd geacht voor implementatie op verouderde hardware.)

Afgezien van de bovenstaande protocolstandaarden is de andere belangrijke standaard waarvan bewustzijn belangrijk is 802.11e. Deze standaard definieert het opstellen van multimediatoepassingen zoals gestroomde video en voice over IP (VoIP) binnen een 802.11-netwerk. Net als 802.11i heeft ook 802.11e een voorgaande specificatie genaamd WME (later hernoemd tot WMM) die door een industriegroep is gedefinieerd als een deelverzameling van 802.11e die nu kan worden gebruikt om multimediatoepassingen mogelijk te maken terwijl er gewacht wordt op de uiteindelijke ratificatie van 802.11e. Het belangrijkste om over 802.11e en WME/WMM te weten is dat ze gepriotiseerd verkeersgebruik van een draadloos netwerk mogelijk maken door middel van Quality of Service (QoS) protocollen en protocollen voor verbeterde mediatoegang. Een juiste implementatie van deze protocollen maken snelle gegevensbursts en gepriotiseerde verkeersstromen mogelijk.

FreeBSD ondersteunt netwerken die met 802.11a, 802.11b, en 802.11g werken. Ook worden de veiligheidsprotocollen WPA en 802.11i ondersteund (samen met 11a, 11b, of 11g) en QoS en de verkeerspriorisatieprotocollen die nodig zijn voor de protocollen WME/WMM worden voor een beperkte verzameling draadloze apparatuur ondersteund.

De infrastructuur- of BSS-modus is de modus die normaliter gebruikt wordt. In deze modus zijn een aantal draadloze toegangspunten verbonden met een bedraad netwerk. Elk draadloos netwerk heeft een eigen naam, deze naam wordt de SSID van het netwerk genoemd. Draadloze cliënten verbinden zich met de draadloze toegangspunten.

IBSS-modus, ook ad-hoc-modus genoemd, is ontworpen voor point-to-point-verbindingen. Om bijvoorbeeld een ad-hoc-netwerk tussen de machine A en de machine B op te zetten, is het slechts nodig om twee IP-adressen en een SSID te kiezen.

Op machine A:

De parameter adhoc geeft aan dat de interface in de IBSS-modus draait.

Op B zal het mogelijk moeten zijn om A te detecteren:

De I in de uitvoer bevestigt dat machine A in ad-hoc-modus verkeert. Het is slechts nodig om B met een ander IP-adres in te stellen:

Zowel A als B zijn nu klaar om informatie uit te wisselen.

FreeBSD kan als toegangspunt (AP) functioneren wat de noodzaak om een hardwarematig AP te kopen of een ad-hoc-netwerk te draaien wegneemt. Dit kan bijzonder nuttig zijn indien de FreeBSD-machine als gateway naar een ander netwerk (bijvoorbeeld het Internet) functioneert.

Een bekabelde verbinding biedt betere prestaties en betrouwbaarheid, terwijl een draadloze verbinding meer flexibiliteit en mobiliteit biedt; laptop-gebruikers zullen dit willen combineren en naadloos tussen de twee overschakelen.

In FreeBSD is het mogelijk om twee of meer netwerkinterfaces te combineren in een "failover"-opstelling, dit houdt in dat de meest geprefereerde en best beschikbare verbinding van een groep van netwerkinterfaces wordt gebruikt, en het besturingssysteem automatisch te laten overschakelen wanneer de status van de verbinding verandert.

Link-aggregatie en failover worden behandeld in Verbindingsaggregatie en failover, een voorbeeld voor het gebruik van zowel een bekabelde als een draadloze verbinding wordt gegeven in Failover-modus tussen bekabelde en draadloze interfaces.

Indien er problemen met het draadloos netwerk zijn, zijn er een aantal stappen die genomen kunnen worden om het probleem te helpen verhelpen.

Indien de bovenstaande informatie niet helpt om het probleem te verhelderen, stuur dan een probleemrapport op inclusief de uitvoer van de bovenstaande gereedschappen.

Bluetooth is een draadloze technologie om persoonlijke netwerken aan te maken die in de vrije 2,4GHz-band werken binnen een straal van 10 meter. Deze netwerken worden gewoonlijk ad-hoc gevormd en bestaan uit draagbare apparaten zoals mobiele telefoons, handhelds en laptops. In tegenstelling tot die andere populaire draadloze techniek, Wi-Fi, biedt Bluetooth een hoger niveau van serviceprofielen, zoals FTP-achtige bestandsservers, pushing van bestanden, stemtransport, emulatie van seriële lijnen, en meer.

De Bluetooth stack is in FreeBSD geïmplementeerd door gebruik te maken van het Netgraph-raamwerk (zie netgraph(4)). Veel van de Bluetooth USB-dongles worden ondersteund door het stuurprogramma ng_ubt(4). Apparaten gebaseerd op de Broadcom BCM2033 chip worden ondersteund door de stuurprogramma’s ubtbcmfw(4) en ng_ubt(4). De 3Com Bluetooth PC Card 3CRWB60-A wordt ondersteund door het stuurprogramma ng_bt3c(4). Seriële en op UART gebaseerde Bluetooth-apparaten worden ondersteund via sio(4), ng_h4(4), en hcseriald(8). Deze sectie beschrijft het gebruik van de USB Bluetooth-dongle.

Standaard zijn stuurprogramma’s voor Bluetooth-apparaten beschikbaar als kernelmodules. Voordat een apparaat wordt aangekoppeld, dient het stuurprogramma in de kernel geladen te worden:

Indien het Bluetooth-apparaat tijdens het opstarten van het systeem in het systeem aanwezig is, kan de module vanuit /boot/loader.conf geladen worden:

Prik de USB-dongle in. Uitvoer vergelijkbaar aan de onderstaande zal op de console (of in syslog) verschijnen:

service(8) wordt gebruikt om de Bluetooth-stack te starten en te stoppen. Het is een goed idee om de stack te stoppen voordat het apparaat wordt losgekoppeld, maar het is (gewoonlijk) niet fataal. Tijdens het starten van de stack verschijnt er uitvoer vergelijkbaar met de onderstaande:

Het Host Controller Interface (HCI) biedt een opdrachtinterface naar de controller van de basisband en de verbindingsbeheerder, en toegang tot hardwarestatus en controleregisters. Deze interface biedt een uniforme manier om de mogelijkheden van de basisband van Bluetooth te benaderen. De HCI-laag op de gastheer wisselt gegevens en opdrachten uit met de HCI-firmware in de Bluetooth-hardware. Het stuurprogramma voor de Host Controller Transport Layer (i.e., de fysieke bus) biedt aan beide HCI-lagen de mogelijkheid om informatie met elkaar uit te wisselen.

Voor een enkel Bluetooth-apparaat wordt een enkele Netgraph knoop van het type hci aangemaakt. De HCI-knoop is normaliter verbonden met de knoop van het Bluetooth-apparaatstuurprogramma (naar beneden toe) en de L2CAP-knoop (naar boven toe). Alle HCI-bewerkingen dienen te worden uitgevoerd op de HCI-knoop en niet op de knoop van het apparaatstuurprogramma. De standaardnaam voor de HCI-knoop is "devicehci". Kijk voor meer details in de hulppagina ng_hci(4).

Eén van de meest voorkomende taken is het ontdekken van Bluetooth-apparaten binnen radiobereik. Deze bewerking wordt ondervragen genoemd. Ondervragen en andere HCI-gerelateerde bewerkingen worden uitgevoerd met het programma hccontrol(8). Het onderstaande voorbeeld laat zien hoe kan worden uitgezocht welke Bluetooth-apparaten zich binnen het bereik bevinden. De lijst met apparaten zou binnen enkele seconden moeten binnenkomen. Bedenk dat een apparaat op afstand alleen antwoord op de ondervraging zal geven indien het in ontdekbare modus staat.

BD_ADDR is een uniek adres van een Bluetooth-apparaat, vergelijkbaar met een MAC-adres van een netwerkkaart. Dit adres is nodig voor verdere communicatie met een apparaat. Het is mogelijk om een menselijk leesbare naam aan een BD_ADDR toe te kennen. Het bestand /etc/bluetooth/hosts bevat informatie over de bekende Bluetooth-gastheren. Het volgende voorbeeld laat zien hoe de menselijk leesbare naam dat aan het apparaat op afstand was toegekend te verkrijgen is:

Tijdens het uitvoeren van een ondervraging op een Bluetooth-apparaat op afstand zal het de computer als "uw.gastheer.naam (ubt0)" vinden. De naam die aan het lokale apparaat is toegekend, kan altijd gewijzigd worden.

Het Bluetooth-systeem biedt een punt-naar-punt-verbinding (slechts twee Bluetooth-eenheden betrokken), of een punt-naar-veelpunt-verbinding. Bij een punt-naar-veelpunt-verbinding wordt de verbinding met meerdere Bluetooth-apparaten gedeeld. Het volgende voorbeeld laat zien hoe de lijst met actieve basisbandverbindingen voor het lokale apparaat te verkrijgen is:

Een verbindingshandvat is nuttig indien het beëindigen van de basisbandverbinding noodzakelijk is. Normaalgesproken is het niet nodig om dit handmatig te doen. De stack zal automatisch niet-actieve basisbandverbindingen beëindigen.

Raadpleeg hccontrol help voor een volledige lijst van beschikbare HCI-opdrachten. Voor de meeste HCI-opdrachten zijn geen beheerdersrechten nodig.

Het Logical Link Control and Adaptation Protocol (L2CAP) biedt verbindingsgeoriënteerde en verbindingsloze gegevensdiensten met mogelijkheden om protocollen te multiplexen en mogelijkheden voor segmentatie/herassemblage voor protocollen in hogere lagen. L2CAP staat toe dat protocollen en toepassingen in hogere lagen L2CAP-gegevenspakketten met een maximale lengte van 64 kB te verzenden en ontvangen.

L2CAP is op het concept van kanalen gebaseerd. Een kanaal is een logische verbinding bovenop een basisbandverbinding. Elk kanaal is op een veel-op-één manier aan een enkel protocol gebonden. Aan hetzelfde protocol kunnen meerdere kanalen worden gebonden, maar één kanaal kan niet aan meerdere protocollen worden gebonden. Elk L2CAP-pakket dat op een kanaal wordt ontvangen, wordt naar het juiste hogere protocol doorgestuurd. Meerdere kanalen kunnen dezelfde basisbandverbinding delen.

Voor elk Bluetooth-apparaat wordt een enkele Netgraph-knoop van het soort l2cap aangemaakt. De L2CAP-knoop is normaalgesproken verbonden met de Bluetooth HCI-knoop (naar beneden toe) en de knopen van de stopcontacten voor Bluetooth (naar boven toe). De standaardnaam voor de L2CAP-knoop is "devicel2cap". Zie voor meer details de hulppagina ng_l2cap(4).

Een nuttig commando is l2ping(8), dat gebruikt kan worden om andere apparaten te pingen. Sommige Bluetooth-implementaties geven niet alle verzonden gegevens terug, dus is 0 bytes normaal in het volgende voorbeeld.

Met het programma l2control(8) kunnen verschillende bewerkingen op L2CAP-knopen worden uitgevoerd. Dit voorbeeld laat zien hoe de lijst met logische verbindingen (kanalen) en de lijst met basisbandverbindingen voor het lokale apparaat verkregen kunnen worden:

Een ander diagnostisch programma is btsockstat(1). Het heeft ongeveer hetzelfde doel als netstat(1), maar dan voor Bluetooth-netwerkgerelateerde gegevensstructuren. Het onderstaande voorbeeld laat dezelfde logische verbinding zien als die van l2control(8) hierboven.

Het RFCOMM-protocol biedt emulatie van seriële poorten over het L2CAP-protocol. Het protocol is gebaseerd op de ETSI-standaard TS 07.10. RFCOMM is een eenvoudig transportprotocol, met aanvullende voorzieningen om de 9 circuits van RS-232- (EIATIA-232-E-) seriële poorten te emuleren. Het RFCOMM-protocol ondersteunt tot 60 gelijktijdige verbindingen (RFCOMM-kanalen) tussen twee Bluetooth-apparaten.

Het is de bedoeling van RFCOMM dat in een volledig communicatiepad twee toepassingen op verschillende apparaten draaien (de eindpunten van de communicatie) met daartussen een communicatiesegment. RFCOMM is bedoeld om de toepassingen te beheren die gebruik maken van de seriële poorten van de apparaten waarop ze zijn geïnstalleerd. Het communicatiesegment is een directe Bluetooth-verbinding van het ene apparaat naar het andere.

RFCOMM houdt zich alleen bezig met de verbinding tussen twee apparaten bij directe verbindingen, of tussen het apparaat en een modem in het geval van een netwerk. RFCOMM kan andere opstellingen ondersteunen, zoals modules die via draadloze Bluetooth-technologie communiceren aan de ene kant, en een draadinterface aanbieden aan de andere kant.

In FreeBSD is het RFCOMM-protocol in de laag van de Bluetooth-stopcontacten geïmplementeerd.

Standaard is Bluetooth-communicatie niet geauthenticeerd en kan elk apparaat met elk ander apparaat praten. Een Bluetooth-apparaat (bijvoorbeeld een mobiele telefoon) kan ervoor kiezen dat voor bepaalde diensten authenticatie nodig is (bijvoorbeeld voor de inbeldienst). Bluetooth-authenticatie geschied normaalgesproken met PIN-codes. Een PIN-code is een ACII-reeks van maximaal 16 tekens lang. De gebruiker dient dezelfde PIN-code op beide apparaten in te voeren. Nadat de gebruiker de PIN-code heeft ingevoerd, zullen beide apparaten een verbindingssleutel aanmaken. Hierna kan de verbindingssleutel òfwel in de apparaten zelf, òfwel in een permanente opslag worden opgeslagen. De volgende keer zullen beide apparaten de van tevoren aangemaakte verbindingssleutel gebruiken. Bovenstaande procedure wordt paren genoemd. Merk op dat indien een apparaat de verbindingssleutel verliest, het paren moet worden herhaald.

De daemon hcsecd(8) is verantwoordelijk voor het behandelen van alle verzoeken voor Bluetooth-authenticatie. Het standaard instellingenbestand is /etc/bluetooth/hcsecd.conf. Een voorbeeldsectie voor een mobiele telefoon waarvan de PIN-code willekeurig op "1234" is hieronder beschreven:

Er is geen limiet voor PIN-codes (behalve de lengte). Voor sommige apparaten (bijvoorbeeld Bluetooth-headsets) kan de PIN-code vast zijn ingebouwd. De schakelaar -d dwingt de daemon hcsecd(8) om op de voorgrond te blijven, zodat het gemakkelijk is om te zien wat er gebeurt. Stel het andere apparaat in om paarverzoeken te ontvangen en initialiseer de Bluetooth-verbinding naar het andere apparaat. Het apparaat moet zeggen dat het paarverzoek geaccepteerd is en om de PIN-code vragen. Geef dezelfde PIN-code op als in hcsecd.conf. Nu zijn de PC en het andere apparaat gepaard. Als alternatief kan paren op het andere apparaat worden geïnitialiseerd.

De volgende regel kan aan het bestand /etc/rc.conf worden toegevoegd om hcsecd automatisch met het systeem op te starten:

Het volgende is een voorbeeld van de uitvoer van de daemon hcsecd:

Het Service Discovery Protocol (SDP) biedt voor cliënttoepassingen de mogelijkheid om diensten te ontdekken die door servertoepassingen worden aangeboden alsook de kenmerken van deze diensten. De kenmerken van een dienst omvatten de soort of klasse van de aangeboden dienst en de informatie over het mechanisme of protocol dat nodig is om de dienst te gebruiken.

SDP omvat communicatie tussen een SDP-server en een SDP-cliënt. De server houdt een lijst van dienstenregistraties bij die de eigenschappen van de diensten beschrijven die met de server geassocieerd zijn. Elke dienstregistratie bevat informatie over een enkele dienst. Een cliënt kan informatie over een dienstregistratie opvragen die door de SDP-server wordt bijgehouden door een SDP-verzoek in te dienen. Indien de cliënt, of een toepassing die met de cliënt geassocieerd is, besluit om de dienst te gebruiken, moet het een aparte verbinding naar de aanbieder van de dienst openen om de dienst te gebruiken. SDP biedt een mechanisme om diensten en hun attributen te ontdekken, maar het biedt geen mechanisme om die diensten te gebruiken.

Normaalgesproken zoekt een SDP-cliënt naar diensten naar aanleiding van enkele gewenste eigenschappen van die diensten. Soms is het echter wenselijk om te ontdekken welke soorten diensten door de dienstregistraties van een SDP-server worden beschreven zonder enige voorkennis van deze diensten. Dit kijken naar alle aangeboden diensten wordt browsen genoemd.

De Bluetooth SDP-server sdpd(8) en de opdrachtregelcliënt sdpcontrol(8) zitten in de standaard FreeBSD-installatie. Het volgende voorbeeld laat zien hoe een SDP-browse query uit te voeren.

Het aanbieden van diensten op FreeBSD aan Bluetooth-cliënten wordt gedaan met de server sdpd(8). De volgende regel kan aan het bestand /etc/rc.conf worden toegevoegd:

Het daemon sdpd kan worden gestart met:

De plaatselijke servertoepassing die Bluetooth-diensten wil aanbieden aan verre cliënten zal de dienst registreren bij de plaatselijke SDP-daemon. Een voorbeeld van zo’n toepassing is rfcomm_pppd(8). Nadat het gestart is zal het de Bluetooth LAN-dienst bij de plaatselijke SDP-daemon registreren.

De lijst met diensten die bij de plaatselijke SDP-server zijn geregistreerd kan worden opgevraagd door te SDP-browsen via het plaatselijke controlekanaal:

Het inbelnetwerk (DUN) profiel wordt het meeste gebruikt met modems en mobiele telefoons. De volgende scenario’s worden in dit profiel behandeld:

Het profiel voor netwerktoegang met PPP (LAN) kan in de volgende situaties gebruikt worden:

Op FreeBSD zijn beide profielen geïmplementeerd met ppp(8) en rfcomm_pppd(8) - een wrapper die een RFCOMM Bluetooth-verbinding omzet in iets waar PPP mee overweg kan. Voordat een profiel gebruikt kan worden, dient een nieuw PPP-label in het bestand /etc/ppp/ppp.conf te worden aangemaakt. Raadpleeg de hulppagina rfcomm_pppd(8) voor voorbeelden.

In het volgende voorbeeld zal rfcomm_pppd(8) gebruikt worden om RFCOMM-verbinding met een ver apparaat met BD_ADDR 00:80:37:29:19:a4 op een DUN RFCOMM-kanaal te maken. Het eigenlijke RFCOMM-kanaalnummer wordt via SDP van het verre apparaat verkregen. Het is mogelijk om het RFCOMM-kanaal handmatig op te geven, en in dat geval zal rfcomm_pppd(8) het SDP-verzoek niet uitvoeren. Gebruik sdpcontrol(8) om het RFCOMM-kanaal op het verre apparaat te achterhalen.

Om netwerktoegang met PPP (LAN) aan te bieden moet de server sdpd(8) draaien. Er dient een nieuwe regel voor LAN-cliënten in het bestand /etc/ppp/ppp.conf aangemaakt te worden. Raadpleeg de hulppagina rfcomm_pppd(8) voor voorbeelden. Tenslotte dient de RFCOMM PPP-server op een geldig RFCOMM-kanaal gestart te worden. De RFCOMM PPP-server zal automatisch de Bluetooth LAN-dienst bij de plaatselijke SDP-daemon registreren. Het volgende voorbeeld laat zien hoe een RFCOMM PPP-server te starten:

OBEX is een veelgebruikt protocol voor eenvoudige bestandsoverdrachten tussen mobiele apparaten. Het primaire gebruik is infraroodcommunicatie, waar het wordt gebruikt voor generieke bestandsoverdrachten tussen notebooks of PDA’s, en om visitekaarten en kalenderregels tussen mobiele telefoons en andere apparaten met PIM-toepassingen over te dragen.

De OBEX-server en clieënt zijn geïmplenteerd als een pakket van derde partij, obexapp, dat beschikbaar is als de port comms/obexapp.

De OBEX-cliënt wordt gebruikt om objecten naar en/of van de OBEX-server te duwen/trekken. Een object kan bijvoorbeeld een visitekaart of een afspraak zijn. De OBEX-cliënt kan het RFCOMM-kanaalnummer van het verre apparaat via SDP opvragen. Dit kan gedaan worden door de dienstnaam in plaats van het RFCOMM-kanaalnummer op te geven. De ondersteunde dienstnamen zijn: IrMC, FTRN, en OPUSH. Het is mogelijk om het RFCOMM-kanaal als een nummer op te geven. Het onderstaande is een voorbeeld van een OBEX-sessie, waar een apparaatinformatie-object van de mobiele telefoon wordt getrokken, en een nieuw object (een visitekaart) in de gids van de telefoon wordt geduwd:

Om de dienst OBEX Object Push aan te bieden, moet de server sdpd(8) draaien. Er moet een hoofdmap worden aangemaakt waarin alle binnenkomende objecten worden opgeslagen. Het standaardpad naar de hoofdmap is /var/spool/obex. Tenslotte moet de OBEX-server op een geldig RFCOMM-kanaal worden gestart. De OBEX-server zal automatisch de dienst OBEX Object Push bij de plaatselijke SDP-daemon registeren. Het onderstaande voorbeeld laat zien hoe de OBEX-server gestart wordt:

Het Seriële Poort Profiel (SPP) zorgt ervoor dat Bluetooth-apparaten RS232 (of gelijkwaardige) seriële kabels kunnen emuleren. Het scenario dat dit profiel behandelt zorgt ervoor dat oude toepassingen Bluetooth kunnen gebruiken als vervanging van kabels, door gebruik te maken van een virtuele seriële poort.

Het programma rfcomm_sppd(1) implementeert het Seriële Poort profiel. Een pseudo-tty wordt gebruikt als abstractie voor een virtuele seriële poort. Onderstaand voorbeeld laat zien hoe met een Seriële Poortdienst voor verre apparaten te verbinden. Merk op dat het niet nodig is om een RFCOMM-kanaal te kiezen - rfcomm_sppd(1) kan het via SDP van het verre apparaat verkrijgen. Dit kan worden overruled door een RFCOMM-kanaal op de opdrachtregel te specificeren.

Als er een verbinding is, kan de pseudo-tty als seriële poort worden gebruikt:

Soms is het handig om één fysiek netwerk (zoals een Ethernet-segment) in twee gescheiden netwerksegmenten te verdelen zonder de noodzaak om een IP-subnet aan te maken en een router te gebruiken om de segmenten met elkaar te verbinden. Een apparaat dat twee netwerken op deze manier met elkaar verbindt wordt een "bridge (brug)" genoemd. Een FreeBSD-systeem met twee netwerkkaarten kan als bridge dienen.

De bridge werkt door de adressen van de MAC-laag (Ethernetadressen) van de apparaten op elke netwerkinterface te leren. Het stuurt alleen verkeer tussen twee netwerken door indien de bron en het doel zich op verschillende netwerken bevinden.

In vele opzichten is een bridge als een Ethernet-switch met erg weinig poorten.

Er zijn vandaag de dag veel situaties waarin een bridge gebruikt wordt.

Deze sectie behandelt de bridges geïmplementeerd met if_bridge(4), een stuurprogramma dat bridges met netgraph implementeert is ook beschikbaar, zie voor meer informatie de hulppagina ng_bridge(4).

Het bridge-stuurprogramma is een kernelmodule en zal automatisch door ifconfig(8) worden geladen wanneer er een bridge-interface wordt aangemaakt. Het is mogelijk om de bridge in de kernel te compileren door device if_bridge aan het kernelinstellingenbestand toe te voegen.

Pakketfiltering kan met elk firewall-pakket worden gebruikt dat via het raamwerk pfil(9) aankoppelt. De firewall kan als een module worden geladen of in de kernel worden gecompileerd.

De bridge kan als met altq(4) of dummynet(4) als een verkeersregelaar worden gebruikt.

De bridge wordt aangemaakt door interfaces te klonen. Om een bridge aan te maken wordt ifconfig(8) gebruikt, indien het bridge-stuurprogramma niet in de kernel aanwezig is zal het automatisch worden geladen.

Een bridge-interface is aangemaakt en er is automatisch een random gegenereerd Ethernetadres aan toegekend. De parameters maxaddr en timeout bepalen hoeveel MAC-adressen de bridge in de doorstuurtabel houdt en hoeveel seconden voordat elke regel wordt verwijderd nadat het voor het laatst gezien is. De andere parameters bepalen hoe Spanning Tree werkt.

Voeg de netwerkinterfaces die lid zijn aan de bridge toe. Om de bridge pakketten te laten doorsturen dienen alle lidinterfaces en de bridge actief te zijn:

De bridge stuurt nu Ethernet-frames door tussen fxp0 en fxp1. De overeenkomstige configuratie in /etc/rc.conf zodat de bridge tijdens het opstarten wordt aangemaakt is:

Indien de bridge-gastheer een IP-adres nodig heeft dan is de juiste plaats om dit in te stellen op de bridge-interface zelf in plaats van op een van de lidinterfaces. Dit kan statisch of via DHCP worden ingesteld:

Het is ook mogelijk om een IPv6-adres aan een bridge-interface toe te kennen.

Wanneer pakketten worden gefilterd, zullen gebridgede pakketten het filter inbound op de vertrekkende interface passeren, op de bridge-interface en outbound op de bestemde interface. Elke stap kan uitgezet worden. Wanneer de richting van het pakketverkeer belangrijk is, kan de firewall het beste op de lidinterfaces draaien en niet op de bridge zelf.

De bridge heeft verschillende aanpasbare instellingen voor het doorlaten van non-IP- en ARP-pakketten, en een laag 2 firewall met IPFW. Zie if_bridge(4) voor meer informatie.

Het bridge-stuurprogramma implementeert het Rapid Spanning Tree Protocol (RSTP of 802.1w) met terugwaartse compatibiliteit met het verouderde Spanning Tree Protocol (STP). Spanning Tree wordt gebruikt om lussen in een netwerktopologie te detecteren en verwijderen. RSTP biedt snellere convergentie naar een opspannende boom dan het verouderde STP, het protocol wisselt informatie met naburige switches uit om snel naar forwarding over te gaan zonder lussen te creëren. FreeBSD ondersteunt RSTP en STP als opties, waarbij RSTP de standaard is.

Spanning Tree kan op lidinterfaces worden geactiveerd met het commando stp. Voor een bridge met fxp0 en fxp1 alle huidige interfaces, wordt STP met het volgende geactiveerd:

De bridge heeft spanning tree ID 00:01:02:4b:d4:50 en prioriteit 32768. Aangezien het root id hetzelfde is geeft dit aan dat dit de hoofdbridge voor de boom is.

Een andere bridge in het netwerk heeft spanning tree ook geactiveerd:

De reegl root id 00:01:02:4b:d4:50 priority 32768 ifcost 400000 port 4 geeft aan dat de hoofdbridge 00:01:02:4b:d4:50 is zoals boven en dat de padkosten 400000 zijn vanaf deze bridge, het pad naar de hoofdbridge gaat via port 4 welke fxp0 is.

De interface lagg(4) maakt het mogelijk om meerdere netwerkinterfaces te aggregeren in één virtueel interface voor het bieden van fout-tolerante en zeer snelle verbindingen.

Het installeren van schijfloze werkstations is zowel vrij rechttoe-rechtaan als foutgevoelig. Deze fouten zijn soms moeilijk vast te stellen wegens een aantal redenen. Bijvoorbeeld:

Op dit gebied is het bezit van wat achtergrondkennis over de gebruikte mechanismen zeer nuttig om mogelijke problemen op te lossen.

Voor een succesvol opstarten dienen verschillende handelingen uitgevoerd te worden:

Zie ook de hulppagina diskless(8).

Als u vanaf een NFS-rootvolume opstart, detecteert /etc/rc dat u over NFS opstartte en draait het het script /etc/rc.initdiskless. Lees het commentaar in dit script om te begrijpen wat er gebeurt. Het is nodig om /etc en /var geheugen-backed te maken omdat deze mappen schrijfbaar moeten zijn, maar de NFS-rootmap is alleen-lezen.

Wanneer het systeem opstart, zullen er geheugen-bestandssystemen voor /etc en /var worden aangemaakt en aangekoppeld, en zal de inhoud van de cpio.gz-bestanden er naartoe worden gekopieerd.

PXE heeft een geprepareerde TFTP-server en DHCP-server nodig. De DHCP-server hoeft niet per së dezelfde machine te zijn als de TFTP-server, maar het dient bereikbaar te zijn in uw netwerk.

De ISDN-implementatie in FreeBSD biedt alleen ondersteuning voor de DSS1/Q.931 (of Euro-ISDN) standaard indien passieve kaarten gebruikt worden. Sommige actieve kaarten worden ondersteund indien de firmware ook ondersteuning voor andere signaleringsprotocollen biedt; dit omvat ook de eerst ondersteunde Primary Rate (PRI) ISDN-kaart.

De isdn4bsd-software biedt de mogelijkheid om met andere ISDN-routers te verbinden door òfwel IP over rauwe HDLC òfwel synchrone PPP te gebruiken: òfwel via kernel-PPP met isppp, een aangepast stuurprogramma voor sppp(4), òfwel via het gebruikersprogramma ppp(8). Door het gebruikersprogramma ppp(8) te gebruiken, is het combineren van twee of meer ISDN B-kanalen mogelijk. Ook zijn een toepassing die de telefoon beantwoordt en vele gereedschappen zoals een 300 Baud-modem in software beschikbaar.

Een groeiend aantal ISDN-kaarten voor de PC wordt door FreeBSD ondersteund en volgens de rapportages wordt het succesvol in heel Europa en in vele andere delen van de wereld gebruikt.

De ondersteunde passieve ISDN-kaarten zijn meestal uitgerust met de Infineon (voormalig Siemens) ISAC/HSCX/IPAC ISDN-chipsets, maar ook worden ISDN-kaarten ondersteund met chips van Cologne Chip (alleen ISA-bus), PCI-kaarten met Winbond W6692-chips, enkele kaarten met combinaties van Tiger300/320/ISAC chipsets en enkele kaarten die gebaseerd zijn op fabrikantspecifieke chipsets zoals de AVM Fritz!Card PCI V.1.0 en de AVM Fritz!Card PnP.

Momenteel zijn de actieve ISDN-kaarten die ondersteund worden de AVM B1 (ISA en PCI) BRI-kaarten en de AVM T1 PCI PRI-kaarten.

Kijk voor documentatie over isdn4bsd op de homepage van isdn4bsd, welke ook verwijzingen naar tips, errata, en veel meer documentatie zoals het isdn4bsd handboek bevat.

Indien er interesse is om ondersteuning voor een ander ISDN-protocol, een momenteel niet-ondersteunde ISDN-kaart voor de PC, of een andere verbetering voor isdn4bsd toe te voegen, dient er contact opgenomen te worden met Hellmuth Michaelis <hm@FreeBSD.org>.

Voor vragen over het installeren, instellen, en problemen met isdn4bsd oplossen is er een mailinglijst, freebsd-isdn, beschikbaar.

Terminal adapters (TA) zijn voor ISDN wat modems voor gewone telefoonlijnen zijn.

De meeste TA’s gebruiken de standaard opdrachtenverzameling van de Hayes-modem, en kunnen direct als vervanging van een modem gebruikt worden.

Een TA zal als een gewoon modem werken behalve dat de verbindings- en doorvoersnelheden veel hoger zullen zijn dan van het oude modem. Het is noodzakelijk om PPP precies hetzelfde als voor het modem in te stellen. Zorg ervoor dat de seriële snelheid zo hoog mogelijk wordt ingesteld.

Het grootste voordeel van met een TA met een internetprovider te verbinden is de mogelijkheid tot dynamisch PPP. Aangezien IP-adresruimte steeds schaarser wordt, zijn de meeste providers niet meer bereid om een statisch IP te geven. De meeste zelfstandige routers zijn niet in staat tot dynamische IP-toewijzing.

TA’s zijn geheel afhankelijk van het PPP-daemon dat gedraaid wordt voor hun mogelijkheden en stabiliteit van de verbinding. Dit maakt het mogelijk om gemakkelijk om op een FreeBSD-machine van een modem naar ISDN over te gaan, indien PPP reeds is ingesteld. Echter, dezelfde problemen die er waren met het PPP-programma zullen blijven voorkomen.

Indien maximale stabiliteit gewenst is, dient de kernel PPP-, niet de gebruikers-PPP-optie gebruikt te worden.

Van de volgende TA’s is bekend dat ze met FreeBSD werken:

De meeste andere TA’s zullen waarschijnlijk ook werken, TA-verkopers proberen er zeker van te zijn dat hun product het meeste van de AT-opdrachtverzameling van het standaardmodem accepteert.

Het echte probleem met externe TA’s is dat, net zoals bij modems, een goede seriële kaart in de computer nodig is.

Voor een goed begrip van seriële apparaten dient de tutorial FreeBSD Serial Hardware en de verschillen tussen asynchrone en synchrone seriële poorten gelezen te worden.

Een TA die op een standaard seriële poort (asynchroon) van een PC draait beperkt de snelheid tot 115.2 Kbps, zelfs als er een 128 Kbps-verbinding beschikbaar is. Om de volledige 128 Kbps waartoe ISDN in staat is te gebruiken, dient de TA op een synchrone seriële kaart overgeplaatst te worden.

Het kopen van een interne TA voorkomt het probleem van synchroon/asynchroon niet. Interne TA’s hebben simpelweg een seriële poortchip van een standaard PC ingebouwd. Dit ontlast de gebruiker alleen van het kopen van nog een seriële kabel en het vinden van nog een leeg elektronisch uitbreidingsslot.

Een synchrone kaart met een TA is minstens zo snel als een zelfstandige router, en wanneer het door een eenvoudige 386 met FreeBSD erop wordt aangestuurd, waarschijnlijk flexibeler.

De keuze tussen synchrone kaart/TA en zelfstandige router is grotendeels religieus. Hierover zijn wat discussies in de mailinglijsten gevoerd. Het wordt aangeraden om de archieven te doorzoeken voor de volledige discussie.

ISDN-bridges of -routers zijn in het geheel niet specifiek voor FreeBSD of enig ander besturingssysteem. Raadpleeg voor een volledigere beschrijving van de technologie van routing en bridging een referentieboek over netwerken.

In deze sectie zullen de termen router en bridge door elkaar worden gebruikt.

Aangezien de prijzen van eenvoudige ISDN-routers/-bridges zakken, zal dit waarschijnlijk een steeds populairdere keuze worden. Een ISDN-router is en kleine doos die direct in het plaatselijke Ethernetnetwerk geprikt wordt, en zijn eigen verbinding met de andere bridge/router beheert. Het heeft ingebouwde software om via PPP en andere populaire protocollen te communiceren.

Een router staat veel snellere doorvoer dan een standaard-TA toe, aangezien het een volledig synchrone ISDN-verbinding zal gebruiken.

Het grootste probleem met ISDN-routers en -bridges is dat samenwerking tussen fabrikanten nog steeds een probleem kan zijn. Indien er plannen zijn om met een internetprovider te verbinden, is het raadzaam de wensen met hen te bespreken.

Indien er gepland is om twee LAN-segmenten met elkaar te verbinden, zoals het thuis-LAN en het kantoor-LAN, is dit de eenvoudigste en onderhoudarmste oplossing. Aangezien de apparatuur voor beide kanten van de verbinding wordt gekocht is het zeker dat de verbinding zal werken.

De volgende installatie kan worden gebruikt om bijvoorbeeld een thuiscomputer of een netwerk van een afdelingskantoor met een netwerk van het hoofdkantoor te verbinden:

Een groot voordeel van de meeste routers/bridges is dat ze gelijktijdig 2 gescheiden onafhankelijke PPP-verbindingen met 2 gescheiden sites toestaan. Dit wordt door de meeste TA’s niet ondersteund, behalve voor specifieke (gewoonlijk dure) modellen die twee seriële poorten hebben. Dit dient niet met kanaalbinding, MPP, etcetera verward te worden.

Dit kan een erg handige eigenschap zijn indien, bijvoorbeeld, er een toegewijde ISDN-verbinding op kantoor is en het gewenst is om deze af te tappen, maar een andere ISDN-lijn op het werk ongewenst is. Een router op kantoor kan een toegewijde B-kanaal verbinding (64 Kbps) met het Internet beheren en het andere B-kanaal voor een gescheiden gegevensverbinding gebruiken. Het tweede B-kanaal kan voor inbellen, uitbellen, of dynamisch binden (MPP, etcetera) gebruikt worden met het eerste B-kanaal voor meer bandbreedte.

Een Ethernet-bridge staat ook toe om meer dan alleen IP-verkeer te verzenden. Het is ook mogelijk om IPX/SPX of enig ander protocol te gebruiken.

Het Network Address Translation daemon van FreeBSD, in het algemeen bekend als natd(8), is een daemon dat rauwe binnenkomende IP-pakketten accepteert, de bron naar die van de plaatselijke machine verandert en de pakketten terug in de uitgaande IP-pakketstroom injecteert. natd(8) doet dit door het IP-adres en de poort van de bron zo te veranderen dat wanneer de gegevens weer ontvangen worden, het in staat is om de originele plaats van de gegevens te achterhalen en ze door te sturen naar de originele aanvrager.

NAT wordt het meest gebruikt wat in het algemeen bekend is als het delen van een Internetverbinding.

Wegens de krimpende IP-ruimte in IPv4, en het groeiend aantal gebruikers van consumentenlijnen op hoge snelheid zoals kabel of DSL, hebben steeds meer mensen een oplossing als het delen van een Internetverbinding nodig. Vanwege de mogelijkheid om meerdere computers online te verbinden door één verbinding en IP-adres is natd(8) een redelijke keuze.

In de meeste gevallen heeft een gebruiker een machine verbonden met een kabel- of DSL-lijn met één IP-adres en is het gewenst om deze ene verbonden computer te gebruiken om Internettoegang aan meerdere computers over een LAN te geven.

Hiervoor dient de FreeBSD-machine op het Internet dienst doen als gateway. Deze gateway-machine heeft twee NICs nodig - één voor de verbinding met de Internetrouter, de andere voor de verbinding met het LAN. Alle machines op het LAN zijn verbonden door een hub of switch.

Dit soort installaties wordt in het algemeen gebruikt om een Internetverbinding te delen. Eén van de LAN-machines is verbonden met het Internet. De rest van de machines hebben internettoegang via die "gateway"-machine.

De mogelijkheden van de kernel voor network address translation met natd(8) staan niet aan in GENERIC, maar ze kunnen worden voorgeladen tijdens het opstarten door enkele opties aan /boot/loader.conf toe te voegen:

Ook moet de tunable net.inet.ip.fw.default_to_accept op 1 worden gezet:

Wanneer modules geen optie zijn of wanneer het gewenst is om alle benodigde mogelijkheden in de draaiende kernel te bouwen, dienen de volgende opties in het kernelinstellingenbestand aanwezig te zijn:

De volgende opties kunnen ook van pas komen:

Om de firewall en NAT tijdens het opstarten aan te zetten, moet het volgende in /etc/rc.conf staan:

Het gedefinieerd hebben van de bovenstaande opties in /etc/rc.conf zal natd -interface fxp0 draaien tijdens het opstarten. Dit kan ook handmatig worden gedraaid.

Elke machine en interface achter het LAN dient een IP-adres in de privé-netwerkruimte toegewezen te krijgen zoals gedefinieerd in RFC 1918 en een standaard gateway van het interne IP-adres van de natd-machine hebben.

Bijvoorbeeld, cliënt A en B achter het LAN hebben IP-adressen 192.168.0.2 en 192.168.0.3, terwijl de LAN-interface van de natd-machine IP-adres 192.168.0.1 heeft. De standaard gateway van cliënt A en B dient ingesteld te worden op die van de natd-machine, 192.168.0.1. Voor de externe, of Internet-interface van de natd-machine zijn geen speciale wijzigingen nodig om natd(8) te laten werken.

Het nadeel van natd(8) is dat de LAN-cliënten niet vanaf het Internet toegankelijk zijn. Cliënten op het LAN kunnen uitgaande verbinden naar de wereld maken maar kunnen geen inkomende verbindingen ontvangen. Dit vormt een probleem wanneer geprobeerd wordt om Internetdiensten op een van de LAN-cliëntmachines te draaien. Een eenvoudige om dit te omzeilen is om bepaalde Internetpoorten op de natd-machine om te leiden naar een LAN-cliënt.

Bijvoorbeeld, er draait een IRC-server op cliënt A, en er draait een webserver op cliënt B. Om dit goed te laten werken, dienen verbindingen die worden ontvangen op poorten 6667 (IRC) en 80 (web) te worden omgeleid naar de respectievelijke machines.

De optie -redirect_port dient aan natd(8) met de juiste opties te worden doorgegeven. De syntaxis is als volgt:

In het bovenstaand voorbeeld dienen de argumenten te zijn:

Dit zal de juiste tcp-poorten naar de LAN-cliënt-machines omleiden.

Het argument -redirect_port kan worden gebruikt om poortbereiken over individuele poorten aan te geven. Bijvoorbeeld, tcp 192.168.0.2:2000-3000 2000-3000 zal alle verbindingen die op poorten 2000 tot 3000 worden ontvangen omleiden naar poorten 2000 tot 3000 op cliënt A.

Deze opties kunnen worden gebruikt wanneer natd(8) direct wordt gedraaid, wanneer ze zijn geplaatst in de optie natd_flags="" van /etc/rc.conf, of wanneer ze via een instellingenbestand worden doorgegeven.

Raadpleeg voor meer instelopties natd(8).

Adressen omleiden is handig wanneer er verschillende IP-adressen beschikbaar zijn, maar ze op één machine moeten zitten. Hiermee kan natd(8) aan elke LAN-cliënt een eigen extern IP-adres toewijzen. Vervolgens overschrijft natd(8) de uitgaande pakketten van de LAN-cliënten met het juiste IP-adres en leidt het al het binnenkomende verkeer op dat ene IP-adres terug naar de specifieke LAN-cliënt. Dit staat ook bekend als statisch NAT. Bijvoorbeeld, de IP-adressen 128.1.1.1, 128.1.1.2, en 1281.2..3 behoren toe aan de natd gateway-machine. 128.1.1.1 kan gebruikt worden als het externe IP-adres van de natd gateway-machine, terwijl 128.1.1.2 en 128.1.1.3 terug worden gestuurd naar de LAN-cliënten A en B.

De syntaxis van -redirect_address is als volgt:

In het voorbeeld zou dit argument zijn:

Net zoals -redirect_port worden ook deze argumenten geplaatst in de optie natd_flags="" van /etc/rc.conf, of doorgegeven via een instellingenbestand. Met adresomleiding is het omleiden van poorten niet nodig aangezien alle gegevens die op een bepaald IP-adres worden ontvangen worden omgeleidt.

Het externe IP-adres op de natd machine dient actief en naar een externe interface gealiased te zijn. In rc.conf(5) staat hoe dit te doen.

Er zijn verschillende soorten IPv6-adressen: unicast, anycast, en multicast.

Unicast-adressen zijn de bekende adressen. Een pakket dat naar een unicast-adres wordt verzonden arriveert precies op de interface dat bij dat adres hoort.

Anycast-adressen zijn syntactisch niet van unicast-adressen te onderscheiden maar ze adresseren een groep interfaces. Een pakket dat bestemd is voor een anycast-adres zal bij de dichtstbijzijnde interface arriveren (in router-metrieken). Anycast-adressen mogen alleen door routers worden gebruikt.

Multicast-adressen identificeren een groep interfaces. Een pakket dat bestemd is voor en multicast-adres zal bij alle interfaces die bij de multicast-groep horen arriveren.

De canonieke vorm wordt weergegeven als: x:x:x:x:x:x:x:x, waarbij elke "x" een 16-bits hexadecimale waarde is. Bijvoorbeeld FEBC:A574:382B:23C1:AA49:4592:4EFE:9982

Vaak bevat een adres lange deelstrings van allen nullen, daarom kan per adres één zo’n deelstring worden afgekort als "::". Ook kunnen maximaal drie voorlopende "0"'s per hexadecimaal viertal worden weggelaten. Bijvoorbeeld, fe80::1 komt overeen met de canonieke vorm fe80:0000:0000:0000:0000:0000:0000:0001.

Een derde vorm is het schrijven van de laatste 32 bits in de bekende (decimale) IPv4-stijl met punten "." als scheidingstekens. Bijvoorbeeld, 2002::10.0.0.1 komt overeen met de (hexadecimale) canonieke representatie 2002:0000:0000:0000:0000:0000:0a00:0001 wat weer hetzelfde is als 2002::a00:1.

Op dit punt dient de lezer het volgende te begrijpen:

fe80::200:21ff:fe03:8e1%rl0 is een automatisch ingesteld link-lokaal adres. Het is als deel van de automatische instelling vanuit het MAC-adres aangemaakt.

Kijk voor verdere informatie over de structuur van IPv6-adressen op RFC3513.

Er zijn momenteel vier manieren om met andere IPv6-hosts en -netwerken te verbinden:

Er waren twee soorten DNS-records voor IPv6. De IETF heeft A6-records overbodig verklaard. AAAA-records zijn nu de standaard.

AAAA-records gebruiken gaat rechttoe-rechtaan. Wijs de hostnaam toe aan het nieuwe IPv6-adres dat net ontvangen is door het volgende aan de DNS-bestand voor primaire zones toe te voegen:

Vraag het aan de DNS-provider indien de DNS-zones niet zelf worden geserveerd. De huidige versies van bind (versie 8.3 en 9) en dns/djbdns (met de IPv6-patch) ondersteunen AAAA-records.

Deze sectie helpt bij het instellen van rtadvd(8) om de standaard IPv6-route te adverteren.

Het volgende is nodig in /etc/rc.conf om rtadvd(8) aan te zetten:

Het is belangrijk om de interface te specificeren waarop het IPv6-routerverzoek plaatsvindt. Om bijvoorbeeld rtadvd(8) te vertellen om fxp0 te gebruiken:

Nu dient het instellingenbestand /etc/rtadvd.conf aangemaakt te worden. Hier is een voorbeeld:

Vervang fxp0 door de interface die gebruikt gaat worden.

Vervang vervolgens 2001:471:1f11:246:: met de prefix van uw toewijzing.

Indien een /64 subnet is toegewezen, hoeft er verder niets veranderd te worden. In andere gevallen dient de juiste waarde voor prefixlen# gebruikt te worden.

Klassiek IP over ATM (CLIP) is de eenvoudigste methode om Asynchronous Transfer Mode (ATM) met IP te gebruiken. Het kan met geswitchte verbindingen (SVCs) en met permanente verbindingen (PVCs) gebruikt worden. Deze sectie beschrijft hoe een netwerk gebaseerd op PVCs op te zetten.

Eén gebruik van CARP, zoals boven aangegeven, is serverbeschikbaarheid. Dit voorbeeld geeft failover-ondersteuning voor drie hosts, met allemaal een uniek IP-adres en dezelfde webinhoud. Deze machines zullen samen met een Round Robin DNS configuratie dienst doen. De failover-machine zal twee aanvullende CARP-interfaces hebben, één voor elk van de IP’s van de contentservers. Wanneer er een storing optreedt, zou de failover-server het IP-adres van de falende machine moeten oppikken. Dit betekent dat de storing geheel onmerkbaar zou moeten zijn voor de gebruiker. De failover-server heeft dezelfde inhoud en diensten nodig als de andere contentservers waarvoor het moet invallen.

De twee machines dienen identiek geconfigureerd te worden op de gegeven hostnamen en VHIDs na. Dit voorbeeld noemt deze machines respectievelijk hosta.example.org en hostb.example.org. Ten eerste dienen de benodigde regels voor een CARP-configuratie aan rc.conf te worden toegevoegd. Voor hosta.example.org dient het bestand rc.conf de volgende regels te bevatten:

Op hostb.example.org dienen de volgende regels in rc.conf te staan:

De derde machine, provider.example.org, dient voorbereidt te worden op het afhandelen van failover van beide hosts. Deze machine heeft twee carp apparaten nodig, één om elke host af te handelen. De juiste instelregels voor rc.conf zullen ongeveer gelijk zijn aan de volgende:

Met twee carp apparaten is provider.example.org in staat om het IP-adres van de andere machine op te pikken wanneer de ene niet meer antwoordt.

Op dit moment dient CARP volledig actief en beschikbaar voor testen te zijn. Voor het testen dienen òfwel het netwerken herstart te worden, òf de machines dienen opnieuw opgestart te worden.

Meer informatie is altijd beschikbaar in de hulppagina carp(4)