0 - en to nb-NO translation catalogue (254 entries)

en: Network
nb-NO: Nettverk

en: Gateway
nb-NO: Innfallsport (gateway)

en: Network Infrastructure
nb-NO: Nettverksinfrastruktur

en: Linux sports the whole Unix heritage for networking, and Debian provides a full set of tools to create and manage them. This chapter reviews these tools.
nb-NO: Linux innehar hele Unix-arven når det gjelder nettverk, og Debian tilbyr hele samlingen av verktøy for å opprette og styre dem. Dette kapittelet går igjennom disse verktøyene.

en: <primary>gateway</primary>
nb-NO: <primary>gateway (innfallsport)</primary>

en: <primary>network</primary><secondary>gateway</secondary>
nb-NO: <primary>nettverk</primary><secondary>gateway</secondary>

en: <primary>router</primary>
nb-NO: <primary>ruter</primary>

en: A gateway is a system linking several networks. This term often refers to a local network's “exit point” on the mandatory path to all external IP addresses. The gateway is connected to each of the networks it links together, and acts as a router to convey IP packets between its various interfaces.
nb-NO: En innfallsport (gateway) er et system som forbinder flere nettverk. Dette begrepet refererer ofte til et lokalt nettverks «utgang» («exit point») på den obligatoriske banen til alle eksterne IP-adresser. Inngangsporten er koblet til hver av de nettverkene den binder sammen, og fungerer som en ruter for å formidle IP-pakker mellom dens ulike grensesnitt.

en: <emphasis>BACK TO BASICS</emphasis> IP packet
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> IP-pakke

en: <primary>packet</primary><secondary>IP</secondary>
nb-NO: <primary>pakke</primary><secondary>IP</secondary>

en: Most networks nowadays use the IP protocol (<emphasis>Internet Protocol</emphasis>). This protocol segments the transmitted data into limited-size packets. Each packet contains, in addition to its payload data, a number of details required for its proper routing.
nb-NO: De fleste nettverk nå for tiden bruker IP-protokollen (<emphasis>Internett-protokoll</emphasis>). Denne protokollen deler opp de overførte dataene i pakker med begrenset størrelse. Hver pakke inneholder, i tillegg til nyttedata, en rekke detaljer som trengs for å sende den riktig vei.

en: <emphasis>BACK TO BASICS</emphasis> TCP/UDP
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> TCP/UDP

en: <primary>protocol</primary><secondary>TCP</secondary>
nb-NO: <primary>protokoll</primary><secondary>TCP</secondary>

en: <primary>protocol</primary><secondary>UDP</secondary>
nb-NO: <primary>protokoll</primary><secondary>UDP</secondary>

en: <primary>Transmission Control Protocol</primary><seealso></seealso>
nb-NO: <primary>Transmission Control Protocol</primary><seealso>TCP</seealso>

en: Many programs do not handle the individual packets themselves, even though the data they transmit does travel over IP; they often use TCP (<emphasis>Transmission Control Protocol</emphasis>). TCP is a layer over IP allowing the establishment of connections dedicated to data streams between two points. The programs then only see an entry point into which data can be fed with the guarantee that the same data exits without loss (and in the same sequence) at the exit point at the other end of the connection. Although many kinds of errors can happen in the lower layers, they are compensated by TCP: lost packets are retransmitted, and packets arriving out of order (for example, if they used different paths) are re-ordered appropriately.
nb-NO: Mange programmer håndterer ikke de enkelte pakker selv, selv om dataene de sender går over IP; bruker de ofte TCP (<emphasis> Transmission Control Protocol</emphasis>). TCP er et lag over IP som tillater etablering av øremerkede forbindelser til datastrømmer mellom to punkter. Programmene ser da bare en inngangsport som data kan mates til med garanti for at de samme dataene kommer ut uten tap (og i samme rekkefølge) ved utgangspunktet i den andre enden av forbindelsen. Selv om mange typer feil kan skje i de lavere lagene, er de kompensert av TCP; tapte pakker er sendt igjen, og pakker som kommer i uorden (for eksempel hvis de bruker ulike baner) er reordnet (omorganisert) på riktig måte.

en: Another protocol relying on IP is UDP (<emphasis>User Datagram Protocol</emphasis>). In contrast to TCP, it is packet-oriented. Its goals are different: the purpose of UDP is only to transmit one packet from an application to another. The protocol does not try to compensate for possible packet loss on the way, nor does it ensure that packets are received in the same order as were sent. The main advantage to this protocol is that the latency is greatly improved, since the loss of a single packet does not delay the receiving of all following packets until the lost one is retransmitted.
nb-NO: En annen protokoll som setter sin lit til IP er UD (<emphasis>User Datagram Protocol</emphasis>). I motsetning til TCP, er den pakkeorientert. Dens mål er forskjellige: Formålet med UDP er bare å sende en pakke fra en applikasjon til en annen. Protokollen prøver ikke å kompensere for mulige pakketap underveis, heller ikke at pakker mottas i samme rekkefølge som de ble sendt. Den viktigste fordelen til denne protokollen er at tidsforsinkelsen er kraftig redusert, fordi tapet av en enkelt pakke ikke forsinker mottaket av alle påfølgende pakker inntil den tapte blir sendt på nytt.

en: TCP and UDP both involve ports, which are “extension numbers” for establishing communication with a given application on a machine. This concept allows keeping several different communications in parallel with the same correspondent, since these communications can be distinguished by the port number.
nb-NO: TCP og UDP involverer begge porter, som er «forlengelse tall» for å etablere kommunikasjon med en gitt applikasjon på en maskin. Dette konseptet gjør det mulig å uføre flere forskjellige overføringer parallelt i samme korrespondanse, siden denne kommunikasjonen kan kjennetegnes av portnummeret.

en: <primary>IP</primary><secondary>masquerading</secondary>
nb-NO: <primary>IP</primary><secondary>maskering</secondary>

en: <primary>network</primary><secondary>masquerading</secondary>
nb-NO: <primary>nettverk</primary><secondary>maskering</secondary>

en: When a local network uses a private address range (not routable on the Internet), the gateway needs to implement <emphasis>address masquerading</emphasis> so that the machines on the network can communicate with the outside world. The masquerading operation is a kind of proxy operating on the network level: each outgoing connection from an internal machine is replaced with a connection from the gateway itself (since the gateway does have an external, routable address), the data going through the masqueraded connection is sent to the new one, and the data coming back in reply is sent through to the masqueraded connection to the internal machine. The gateway uses a range of dedicated TCP ports for this purpose, usually with very high numbers (over 60000). Each connection coming from an internal machine then appears to the outside world as a connection coming from one of these reserved ports.
nb-NO: Når et lokalt nettverk bruker et privat adresseområde (ikke rutbare (tilgjengelig) på Internettet), trenger inngangsporten å gjennomføre <emphasis>address masquerading</emphasis> (adresse maskering) slik at maskinene i nettverket kan kommunisere med omverdenen. Den maskerte operasjonen er en slags mellomtjener som opererer på nettverksnivå: Hver utgående tilkobling fra en intern maskin er erstattet med en forbindelse fra inngangsporten selv (siden porten har en ekstern, rutbar adresse), dataene som går gjennom den maskerte tilkoblingen blir sendt til den nye, og dataene som kommer tilbake som svar sendes gjennom til den maskerte forbindelsen til den interne maskinen. Inngangsporten bruker en rekke øremerkede TCP-porter til dette formål, vanligvis med meget høye tall (over 60 000). Hver tilkobling som kommer fra en intern maskin vises deretter til omverdenen som en forbindelse som kommer fra en av disse reserverte portene.

en: <primary>masquerading</primary>
nb-NO: <primary>maskering</primary>

en: <emphasis>CULTURE</emphasis> Private address range
nb-NO: <emphasis>KULTUR</emphasis> Privat adresseområde

en: <primary>IP</primary><secondary>private address</secondary>
nb-NO: <primary>IP</primary><secondary>privat adresse</secondary>

en: <primary>private IP address</primary>
nb-NO: <primary>privat IP-adresse</primary>

en: RFC 1918 defines three ranges of IPv4 addresses not meant to be routed on the Internet but only used in local networks. The first one, <literal>10.0.0.0/8</literal> (see sidebar <xref linkend="sidebar.networking-basics" />), is a class-A range (with 2<superscript>24</superscript> IP addresses). The second one, <literal>172.16.0.0/12</literal>, gathers 16 class-B ranges (<literal>172.16.0.0/16</literal> to <literal>172.31.0.0/16</literal>), each containing 2<superscript>16</superscript> IP addresses. Finally, <literal>192.168.0.0/16</literal> is a class-B range (grouping 256 class-C ranges, <literal>192.168.0.0/24</literal> to <literal>192.168.255.0/24</literal>, with 256 IP addresses each). <ulink type="block" url="http://www.faqs.org/rfcs/rfc1918.html" />
nb-NO: RFC 1918 definerer tre områder for IPv4-adresser som ikke er ment å bli rutet på Internettet, men bare til bruk i lokale nettverk. Den første, <literal>10.0.0.0/8</literal> (se sidestolpe <xref linkend="sidebar.networking-basics" />), er et A-klasse område (med 2 <superscript>24</superscript> IP-adresser). Den andre, <literal>172.16.0.0/12</literal>, samler 16 B-klasse områder (<literal>172.16.0.0/16</literal> til <literal>172.31.0.0/16</literal>), hver med 2 <superscript>16</superscript> IP-adresser. Til slutt, <literal>192.168.0.0/16</literal> er et B-klasse område (som grupperer 256 C-klasse områder, <literal>192.168.0.0/24</literal> til <literal>192.168.255.0/24</literal>, med 256 IP-adresser hver). <ulink type="block" url="http://www.faqs.org/rfcs/rfc1918.html" />

en: The gateway can also perform two kinds of <emphasis>network address translation</emphasis> (or NAT for short). The first kind, <emphasis>Destination NAT</emphasis> (DNAT) is a technique to alter the destination IP address (and/or the TCP or UDP port) for a (generally) incoming connection. The connection tracking mechanism also alters the following packets in the same connection to ensure continuity in the communication. The second kind of NAT is <emphasis>Source NAT</emphasis> (SNAT), of which <emphasis>masquerading</emphasis> is a particular case; SNAT alters the source IP address (and/or the TCP or UDP port) of a (generally) outgoing connection. As for DNAT, all the packets in the connection are appropriately handled by the connection tracking mechanism. Note that NAT is only relevant for IPv4 and its limited address space; in IPv6, the wide availability of addresses greatly reduces the usefulness of NAT by allowing all “internal” addresses to be directly routable on the Internet (this does not imply that internal machines are accessible, since intermediary firewalls can filter traffic).
nb-NO: Inngangsporten kan også utføre to typer <emphasis>network address translation</emphasis> (eller i korthet NAT). Den første typen, <emphasis>Destination NAT</emphasis> (DNAT) er en teknikk for å endre IP-adressedestinasjonen (og/eller TCP- eller UDP-porten) til en (vanligvis) innkommende tilkobling. Forbindelsens sporingsmekanisme endrer også følgende pakker i samme tilknytning for å sikre kontinuitet i kommunikasjonen. Den andre typen NAT er <emphasis>Source NAT</emphasis> (SNAT), der <emphasis>masquerading</emphasis> er et spesielt tilfelle; SNAT endrer kildens IP-adresse (og/eller TCP- eller UDP-porten) til en (vanligvis) utgående tilkobling. Som for DNAT, er alle pakkene i forbindelsen hensiktsmessig håndtert av forbindelsens sporingsmekanisme. Merk at NAT er kun relevant for IPv4 og dens begrensede adresseområde; i IPv6, reduserer den store tilgjengeligheten av adresser nytten av NAT ved å la alle «interne» adresser være direkte rutbare på Internett (dette betyr ikke at interne maskiner er tilgjengelig, siden mellomliggende brannmurer kan filtrere trafikk).

en: <primary>network</primary><secondary>address translation</secondary><seealso>NAT</seealso>
nb-NO: <primary>nettverk</primary><secondary>adresseoversetting</secondary><seealso>NAT</seealso>

en: <primary>network</primary><secondary>NAT</secondary>
nb-NO: <primary>nettverk</primary><secondary>NAT</secondary>

en: <primary>SNAT</primary><seealso>Source NAT</seealso>
nb-NO: <primary>SNAT</primary><seealso>Kilde-NAT (Source NAT)</seealso>

en: <primary>Source NAT</primary><seealso>SNAT</seealso>
nb-NO: <primary>Kilde-NAT</primary><seealso>SNAT</seealso>

en: <primary>Destination NAT</primary><seealso>DNAT</seealso>
nb-NO: <primary>Mål-NAT</primary><seealso>DNAT</seealso>

en: <emphasis>BACK TO BASICS</emphasis> Port forwarding
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Videresendelse av porter

en: <primary>port forwarding</primary>
nb-NO: <primary>port-videresending (port forwarding)</primary>

en: <primary>network</primary><secondary>port forwarding</secondary>
nb-NO: <primary>nettverk</primary><secondary>port-videresending</secondary>

en: A concrete application of DNAT is <emphasis>port forwarding</emphasis>. Incoming connections to a given port of a machine are forwarded to a port on another machine. Other solutions may exist for achieving a similar effect, though, especially at the application level with <command>ssh</command> (see <xref linkend="sect.ssh-port-forwarding" />) or <command>redir</command>.
nb-NO: En konkret applikasjon hos DNAT er <emphasis>port forwarding</emphasis>. Innkommende tilkoblinger til en gitt port hos en maskin blir videresendt til en port på en annen maskin. Andre løsninger kan oppnå en lignende virkning, men særlig på applikasjonsnivå med <command>ssh</command> (se <xref linkend="sect.ssh-port-forwarding" />) eller <command>redir</command>.

en: <primary>filesystem</primary><secondary>virtual</secondary><tertiary><filename>/proc/</filename></tertiary>
nb-NO: <primary>filsystem</primary><secondary>virtuelt</secondary><tertiary><filename>/proc/</filename></tertiary>

en: Enough theory, let's get practical. Turning a Debian system into a gateway is a simple matter of enabling the appropriate option in the Linux kernel, by way of the <filename>/proc/</filename> virtual filesystem:
nb-NO: Nok teori, la oss være praktiske. Å snu et Debian-system til en port er en så enkel sak som å aktivere det aktuelle valget i Linux-kjernen ved hjelp av <filename>/proc/</filename> virtuelle filsystemet:

en: The <filename>/etc/sysctl.conf</filename> file
nb-NO: <filename>/etc/sysctl.conf</filename>-filen

en: The same effect can be obtained for IPv6 by simply replacing <literal>ipv4</literal> with <literal>ipv6</literal> in the manual command and using the <literal>net.ipv6.conf.all.forwarding</literal> line in <filename>/etc/sysctl.conf</filename>.
nb-NO: Den samme effekten kan oppnås for IPv6 ved å bytte <literal>ipv4</literal> med <literal>ipv6</literal> i den manuelle kommandoen, og bruke <literal>net.ipv6.conf.all.forwarding</literal>-linjen i <filename>/etc/sysctl.conf</filename>.

en: Enabling IPv4 masquerading is a slightly more complex operation that involves configuring the <emphasis>netfilter</emphasis> firewall.
nb-NO: Å aktivere IPv4-maskering er en litt mer komplisert operasjon som involverer å sette opp <emphasis>netfilter</emphasis>-brannmuren.

en: Similarly, using NAT (for IPv4) requires configuring <emphasis>netfilter</emphasis>. Since the primary purpose of this component is packet filtering, the details are listed in <xref linkend="security" xrefstyle="select: label quotedtitle nopage" /> (see <xref linkend="sect.firewall-packet-filtering" />).
nb-NO: Tilsvarende, å bruke NAT (for IPv4), krever oppsett av <emphasis>netfilter</emphasis>. Siden det primære formålet med denne komponenten er pakkefiltrering, er detaljene oppført i <xref linkend="security" xrefstyle="select: label quotedtitle nopage" /> (se <xref linkend="sect.firewall-packet-filtering" />).

en: X.509 certificates
nb-NO: X.509-sertifikater

en: <primary>certificate</primary><secondary>X.509</secondary>
nb-NO: <primary>sertifikat</primary><secondary>X.509</secondary>

en: <primary>X.509</primary><secondary>certificates</secondary>
nb-NO: <primary>X.509</primary><secondary>sertifikater</secondary>

en: <primary>CA</primary><seealso>Certificate Authority</seealso>
nb-NO: <primary>CA</primary><seealso>Sertifiseringsmyndighet (Certificate Authority)</seealso>

en: Certificates are an important building block of many network services built on cryptographic protocols, when they need some sort of central authentication.
nb-NO: Sertifikater er en viktig byggestein for mange nettverkstjenester, bygget på kryptografiske protokoller, når de trenger en slags sentral autentisering.

en: Among those protocols, SSL (<emphasis>Secure Socket Layer</emphasis>) was invented by Netscape to secure connections to web servers. It was later standardized by IETF under the acronym TLS (<emphasis>Transport Layer Security</emphasis>). Since then TLS continued to evolve, and nowadays SSL is deprecated due to multiple design flaws that have been discovered.
nb-NO: Blant disse protokollene, ble SSL (<emphasis>Secure Socket Layer</emphasis>) oppfunnet av Netscape for å sikre tilkoblinger til nettjenere. Det ble senere standardisert av IETF under forkortelsen TLS (<emphasis>Transport Layer Security</emphasis>). Siden da har TLS fortsatt å utvikle seg, og i dag er SSL foreldet fordi det er oppdaget en rekke designfeil.

en: The TLS protocol aims primarily to provide privacy and data integrity between two or more communicating computer applications. The most common case on the Internet is the communication between a client (e.g. a web browser) and a server.
nb-NO: TLS-protokollen tar primært sikte på å gi personvern og dataintegritet mellom to eller flere kommuniserende dataprogrammer. Det vanligste tilfellet på Internett er kommunikasjonen mellom en klient (f.eks. en nettleser) og en tjener.

en: <primary>certificate</primary><secondary>root certificate</secondary>
nb-NO: <primary>sertifikat</primary><secondary>rotsertifikat</secondary>

en: You can implement a CA (as described in <xref linkend="sect.easy-rsa" />), but if you intend to use the certificate for a website, you need to rely on a trusted CA. The prices vary significantly, but it is possible to implement great security spending little to no money.
nb-NO: Du kan implementere en CA (som beskrevet i <xref linkend="sect.easy-rsa" />), men hvis du har tenkt å bruke sertifikatet for et nettsted, må du stole på en klarert CA. Prisene varierer betydelig, men det er mulig å implementere god sikkerhet som koster lite eller ingen penger.

en: <primary>certificate</primary><secondary>trusted certificate</secondary>
nb-NO: <primary>sertifikat</primary><secondary>tiltrodd sertifikat</secondary>

en: <primary>certificate</primary><secondary>letsencrypt</secondary><seealso><emphasis role="pkg">certbot</emphasis></seealso>
nb-NO: <primary>sertifikat</primary><secondary>letsencrypt</secondary><seealso><emphasis role="pkg">certbot</emphasis></seealso>

en: The Falcot administrators just want to create a certificate for their website, which runs on Apache. There is a convenient Apache plugin for <emphasis role="pkg">certbot</emphasis> that automatically edits the Apache configuration to serve the obtained certificate, so they make use of it:
nb-NO: Falcot-administratorene vil bare lage et sertifikat for deres nettside, som kjører på Apache. Det finnes et praktisk Apache-programtillegg for <emphasis role="pkg">certbot</emphasis> som automatisk redigerer Apache-oppsettet for å vertstjene det benyttede sertifikatet, slik at de gjør bruk av det:

en: <primary>Apache</primary><secondary>trusted certificates</secondary>
nb-NO: <primary>Apache</primary><secondary>tiltrodde sertifikater</secondary>

en: <emphasis>CULTURE</emphasis> The Let's Encrypt Initiative
nb-NO: <emphasis>KULTUR</emphasis> Let's Encrypt-initiativet

en: The <ulink url="https://letsencrypt.org/">Let's Encrypt</ulink> initiative is a joint effort to create a free, automated, and open certificate authority (CA), run for the public's benefit. It is supported by the <acronym>EFF</acronym> and the Linux Foundation. The initiative provides an automated tool for acquiring and renewing certificates. This reduces the amount of manual effort involved, especially if multiple sites and domains must be managed. The certificates can also be used for SIP, XMPP, WebSockets and TURN servers. Usage of the service requires control over the DNS information of the domain in question (domain validation). <ulink type="block" url="https://letsencrypt.org/how-it-works/" />
nb-NO: <ulink url="https://letsencrypt.org/"> Let's Encrypt</ulink>-initiativet er et felles forsøk på å skape en gratis, automatisert og åpen sertifiseringsinstans (CA), som drives for til fordel for alle. Det støttes av <acronym>EFF</acronym> og Linux Foundation. Initiativet tilbyr et automatisert verktøy for å anskaffe og fornye sertifikater. Dette reduserer mengden manuell innsats, spesielt hvis flere områder og domener må administreres. Sertifikatene kan også brukes for SIP-, XMPP-, WebSockets- og TURN-tjenere. Bruk av tjenesten krever kontroll over DNS-infoen til det aktuelle domenet (domenevalidering). <ulink type="block" url="https://letsencrypt.org/how-it-works/" />

en: If you would rather keep the server running during the certificate creation, you can use the webroot plugin to get the certificate with the arguments <command>certonly</command> and <command>--webroot</command>. You would have to specify a <command>--webroot-path</command> (abbreviated <command>-w</command>), which should contain the files served. The command looks as follows:
nb-NO: Hvis du heller vil holde tjeneren i gang under opprettelsen av sertifikatet, kan du bruke webroot-programtillegget til å hente sertifikatet med argumentene <command>certonly</command> og <command>--webroot</command>. Du må angi en <command>--webroot-bane</command> (forkortet <command>-w</command>), som skal inneholde filene som skal til. Kommandoen ser slik ut:

en: You need to restart all services using the certificates that you have created.
nb-NO: Du må starte alle tjenester på nytt ved hjelp av sertifikatene du har opprettet.

en: The certificates created are so called short-life certificates, which are valid for 90 days and must therefor be renewed every once in three months using the <command>certbot renew</command> command. However, we shouldn't renew every certificate manually, but automatically. A basic cron job is included by <emphasis role="pkg">certbot</emphasis> in <filename>/etc/cron.d/certbot</filename>. To ensure that certificates can be automatically renewed, you can execute <command>certbot renew --dry-run</command>.
nb-NO: Sertifikatene som er opprettet, kalles korttidssertifikater, som er gyldige i 90 dager og må derfor fornyes innenfor en tremånedersperiode ved hjelp av kommandoen <command>certbot renew</command>. Vi bør imidlertid ikke fornye hvert sertifikat manuelt, men automatisk. En grunnleggende cron-jobb er inkludert av <emphasis role="pkg">certbot</emphasis> i <filename>/etc/cron.d/certbot</filename>. For å sikre at sertifikater kan fornyes automatisk, kan du utføre <command>certbot renew --dry-run</command>.

en: Public Key Infrastructure: <emphasis>easy-rsa</emphasis>
nb-NO: Offentlig nøkkel-infrastruktur: <emphasis>easy-rsa</emphasis>

en: <primary>PKI</primary><seealso>Public Key Infrastructure</seealso>
nb-NO: <primary>PKI (Offentlig nøkkel-infrastruktur)</primary><seealso>Public Key Infrastructure</seealso>

en: <primary>Public Key Infrastructure</primary>
nb-NO: <primary>Public Key Infrastructure (Offentlig nøkkel-infrastruktur)</primary>

en: <primary>RSA (algorithm)</primary>
nb-NO: <primary>RSA (algoritme)</primary>

en: <primary>algorithm</primary><secondary>RSA</secondary>
nb-NO: <primary>algoritme</primary><secondary>RSA</secondary>

en: <primary>key pair</primary>
nb-NO: <primary>nøkkelpar</primary>

en: It is also possible to create our own CA, for that we will use the RSA algorithm, widely used in public-key cryptography. It involves a “key pair”, comprised of a private and a public key. The two keys are closely linked to each other, and their mathematical properties are such that a message encrypted with the public key can only be decrypted by someone knowing the private key, which ensures confidentiality. In the opposite direction, a message encrypted with the private key can be decrypted by anyone knowing the public key, which allows authenticating the origin of a message since only someone with access to the private key could generate it. When associated with a digital hash function (MD5, SHA1, or a more recent variant), this leads to a signature mechanism that can be applied to any message.
nb-NO: Det er også mulig å lage vår egen CA. Til det vil vi bruke RSA-algoritmen som er mye brukt i offentlig-nøkkel -kryptografi. Det innebærer et «nøkkelpar», som består av en privat og en offentlig nøkkel. De to nøklene er nært knyttet til hverandre, og deres matematiske egenskaper er slik at en melding som er kryptert med den offentlige nøkkelen, kun kan dekrypteres av en person som kjenner den private, noe som sørger for konfidensialitet. I motsatt retning kan en melding kryptert med den private nøkkelen dekrypteres ved at noen kjenner den offentlige nøkkelen, noe som gjør det mulig å autentisere opprinnelsen til en melding siden bare noen med tilgang til den private nøkkelen kan generere den. Når den er knyttet til en digital nøkkelfunksjon (MD5, SHA-1, eller en nyere variant), fører dette til en signaturmekanisme som kan brukes til en hvilken som helst melding.

en: Since public CAs only emit certificates in exchange for a (hefty) fee, it is also possible to create a private certification authority within the company. The <emphasis role="pkg">easy-rsa</emphasis> package provides tools to serve as an X.509 certification infrastructure, implemented as a set of scripts using the <command>openssl</command> command.
nb-NO: Siden offentlig tilgjengelige CA-er kun utsteder sertifikater i bytte for en (heftig) avgift, er det også mulig å opprette en privat sertifiseringsinstans i selskapet. <emphasis role="pkg">easy-rsa</emphasis>-pakken inneholder verktøy for å tjene som en X.509 infrastruktur for sertifisering, implementert som et skriptsett som bruker <command>openssl</command>-kommandoen.

en: <emphasis>ALTERNATIVE</emphasis> GnuTLS
nb-NO: <emphasis>ALTERNATIV</emphasis> GnuTLS

en: GnuTLS can also be used to generate a CA, and deal with other technologies around the TLS, DTLS and SSL protocols.
nb-NO: GnuTLS kan også brukes til å generere en CA, og håndtere andre teknologier rundt TLS, DTLS og SSL-protokoller.

en: The package <emphasis role="pkg">gnutls-bin</emphasis> contains the command-line utilities. It is also useful to install the <emphasis role="pkg">gnutls-doc</emphasis> package, which includes extensive documentation.
nb-NO: Pakken <emphasis role="pkg">gnutls-bin</emphasis> inneholder kommandolinjeverktøyene. Det er også nyttig å installere <emphasis role="pkg">gnutls-doc</emphasis>-pakken, som inkluderer omfattende dokumentasjon.

en: The Falcot Corp administrators use this tool to create the required certificates, both for the server and the clients. This allows the configuration of all clients to be similar since they will only have to be set up so as to trust certificates coming from Falcot's local CA. This CA is the first certificate to create; to this end, the administrators set up a directory with the files required for the CA in an appropriate location, preferably on a machine not connected to the network in order to mitigate the risk of the CA's private key being stolen.
nb-NO: Falcot Corp-administratorene bruker dette verktøyet for å lage de nødvendige sertifikater, både for serveren og klientene. Dette tillater at oppsettet av alle klienter er lik siden de bare må settes opp til å stole på sertifikater fra Falcots lokale CA. Dette CA-et er det første som må lages; til dette formålet, setter administratorene opp en katalog med filene som kreves for CA-et på et passende sted, fortrinnsvis på en maskin som ikke er koblet til nettverket for å redusere risikoen for at CAs private nøkkel blir stjålet.

en: They then store the required parameters into the <filename>vars</filename> file, which can be uncommented and edited:
nb-NO: Deretter lagrer de nødvendige parameterne i filen <filename>vars</filename>, som kan være ukommentert og redigert:

en: The next step is the creation of the CA's key pair itself (the two parts of the key pair will be stored under <filename>pki/ca.crt</filename> and <filename>pki/private/ca.key</filename> during this step). We can add the option <literal>nopass</literal> to avoid entering a password each time the private key is used:
nb-NO: Det neste trinnet er å opprette selve ca-nøkkelparet (de to delene av nøkkelparet vil bli lagret under <filename>pki/ca.crt</filename> og <filename>pki/private/ca.key</filename> i dette trinnet). Vi kan legge til alternativet <literal>nopass</literal> for å unngå å skrive inn et passord hver gang den private nøkkelen brukes:

en: The certificate can now be created, as well as the Diffie-Hellman parameters required for the server side of an SSL/TLS connection. They want to use it for a VPN server (see section <xref linkend="sect.virtual-private-network" />) that is identified by the DNS name <literal>vpn.falcot.com</literal>; this name is re-used for the generated key files (<filename>keys/vpn.falcot.com.crt</filename> for the public certificate, <filename>keys/vpn.falcot.com.key</filename> for the private key):
nb-NO: Sertifikatet kan nå opprettes, samt Diffie-Hellman-parameterne som kreves på tjenersiden av en SSL/TLS-tilkobling. De ønsker å bruke det for en VPN-tjener (se avsnittet <xref linkend="sect.virtual-private-network" />) som er identifisert av DNS-navnet <literal>vpn.falcot.com</literal>; Dette navnet brukes på nytt for de genererte nøkkelfilene (<filename>keys/vpn.falcot.com.crt</filename> for det offentlige sertifikatet, og <filename>keys/vpn.falcot.com.key</filename> for den private nøkkelen):

en: The following step creates certificates for the VPN clients; one certificate is required for each computer or person allowed to use the VPN:
nb-NO: Det neste trinnet oppretter sertifikater for VPN-klienter; ett sertifikat kreves for hver datamaskin eller person som får lov å bruke VPN-en:

en: Virtual Private Network
nb-NO: Privat virtuelt nettverk

en: <primary>network</primary><secondary>virtual private</secondary>
nb-NO: <primary>nettverk</primary><secondary>virtuelt privat</secondary>

en: <primary>virtual private network</primary><seealso>VPN</seealso>
nb-NO: <primary>virtuelt privat nettverk</primary><seealso>VPN</seealso>

en: A <emphasis>Virtual Private Network</emphasis> (VPN for short) is a way to link two different local networks through the Internet by way of a tunnel; the tunnel is usually encrypted for confidentiality. VPNs are often used to integrate a remote machine within a company's local network.
nb-NO: Et virtuelt privat nettverk <emphasis>Virtual Private Network</emphasis> (VPN for kort) er en måte å koble to forskjellige lokale nettverk via Internett ved hjelp av en tunnel; tunnelen er vanligvis kryptert for konfidensialitet. VPN brukes ofte for å integrere en ekstern maskin i et selskaps lokale nettverk.

en: Several tools provide this functionality. OpenVPN is an efficient solution, easy to deploy and maintain, based on SSL/TLS. Another possibility is using IPsec to encrypt IP traffic between two machines; this encryption is transparent, which means that applications running on these hosts need not be modified to take the VPN into account. SSH can also be used to provide a VPN, in addition to its more conventional features. Finally, a VPN can be established using Microsoft's PPTP protocol. Other solutions exist, but are beyond the focus of this book.
nb-NO: Flere verktøy har denne funksjonaliteten. OpenVPN er en effektiv løsning, enkel å implementere og vedlikeholde, basert på SSL/TLS. En annen mulighet er å bruke IPsec for å kryptere IP-trafikk mellom to maskiner; denne krypteringen er transparent, hvilket betyr at programmer som kjører på disse vertene ikke behøver å modifiseres for å ta hensyn til VPN. SSH kan også brukes for å tilveiebringe en VPN, i tillegg til mer konvensjonelle egenskaper. Endelig kan en VPN etableres ved hjelp av Microsofts PPTP-protokoll. Andre løsninger finnes, men er utenfor siktemålet til denne boken.

en: <primary>network</primary><secondary><literal>tun</literal> interface</secondary>
nb-NO: <primary>nettverk</primary><secondary><literal>tun</literal>-grensesnitt</secondary>

en: <primary>network</primary><secondary><literal>tap</literal> interface</secondary>
nb-NO: <primary>nettverk</primary><secondary><literal>tap</literal>-grensesnitt</secondary>

en: OpenVPN is a piece of software dedicated to creating virtual private networks. Its setup involves creating virtual network interfaces on the VPN server and on the client(s); both <literal>tun</literal> (for IP-level tunnels) and <literal>tap</literal> (for Ethernet-level tunnels) interfaces are supported. In practice, <literal>tun</literal> interfaces will most often be used except when the VPN clients are meant to be integrated into the server's local network by way of an Ethernet bridge.
nb-NO: OpenVPN er et stykke programvare med formål å lage virtuelle private nettverk. Oppsettet innebærer å skape virtuelle nettverksgrensesnitt på VPN-tjeneren og på klienten(e); både <literal>tun</literal> (for IP-nivå tunneler) og <literal>tap</literal> (for Ethernet-nivå tunneler) -grensesnitt er støttet. I praksis, skal <literal>tun</literal>-grensesnitt oftest brukes unntatt når VPN-klienter er ment til å bli integrert i tjenerens lokale nettverk ved hjelp av en Ethernet-bro.

en: OpenVPN relies on OpenSSL for all the SSL/TLS cryptography and associated features (confidentiality, authentication, integrity, non-repudiation). It can be configured either with a shared private key or using X.509 certificates based on a public key infrastructure. The latter configuration is strongly preferred since it allows greater flexibility when faced with a growing number of roaming users accessing the VPN.
nb-NO: OpenVPN avhenger av OpenSSL for all SSL/TLS kryptografi og tilhørende funksjoner (konfidensialitet, autentisering, integritet, ikke-fornekting). Den kan settes opp enten med en felles privat nøkkel eller ved hjelp av X.509-sertifikater basert på en infrastruktur med fellesnøkler. Sistnevnte oppsett er sterkt foretrukket fordi den gir større fleksibilitet når den står overfor et økende antall brukere som bruker VPN utenfra.

en: Configuring the OpenVPN Server
nb-NO: Oppsett av OpenVPN-tjeneren

en: <primary>OpenVPN</primary><secondary>server</secondary>
nb-NO: <primary>OpenVPN</primary><secondary>tjener</secondary>

en: After all certificates have been created (follow the instructions from <xref linkend="sect.easy-rsa" />), they need to be copied where appropriate: the root certificate's public key (<filename>pki/ca.crt</filename>) will be stored on all machines (both server and clients) as <filename>/etc/ssl/certs/Falcot_CA.crt</filename>. The server's certificate is installed only on the server (<filename>pki/issued/vpn.falcot.com.crt</filename> goes to <filename>/etc/ssl/certs/vpn.falcot.com.crt</filename>, and <filename>pki/private/vpn.falcot.com.key</filename> goes to <filename>/etc/ssl/private/vpn.falcot.com.key</filename> with restricted permissions so that only the administrator can read it), with the corresponding Diffie-Hellman parameters (<filename>pki/dh.pem</filename>) installed to <filename>/etc/openvpn/dh.pem</filename>. Client certificates are installed on the corresponding VPN client in a similar fashion.
nb-NO: Etter at alle sertifikater er opprettet (følg instruksjonene fra <xref linkend="sect.easy-rsa" />), må de kopieres der det er hensiktsmessig: rotsertifikatets fellesnøkkel (<filename>pki/ca.crt</filename>) vil bli lagret på alle maskiner (både tjener og klienter) som <filename>/etc/ssl/certs/Falcot_CA.crt</filename>. Tjenerens sertifikat er bare installert på tjeneren (<filename>pki/issued/vpn.falcot.com.crt</filename> går til <filename>/etc/ssl/certs/vpn.falcot.com.crt</filename>, og <filename>pki/private/vpn.falcot.com.key</filename> går til <filename>/etc/ssl/private/vpn.falcot.com.key</filename> med begrensede tillatelser slik at bare administratoren kan lese den), med de tilsvarende Diffie-Hellman-parametrene (<filename>pki/dh.pem</filename>) installert til <filename>/etc/openvpn/dh.pem</filename>. Klientsertifikater er installert på den tilsvarende VPN-klienten på en tilsvarende måte.

en: By default, the OpenVPN initialization script tries starting all virtual private networks defined in <filename>/etc/openvpn/*.conf</filename>. Setting up a VPN server is therefore a matter of storing a corresponding configuration file in this directory. A good starting point is <filename>/usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz</filename>, which leads to a rather standard server. Of course, some parameters need to be adapted: <literal>ca</literal>, <literal>cert</literal>, <literal>key</literal> and <literal>dh</literal> need to describe the selected locations (respectively, <literal>/etc/ssl/certs/Falcot_CA.crt</literal>, <literal>/etc/ssl/vpn.falcot.com.crt</literal>, <literal>/etc/ssl/private/vpn.falcot.com.key</literal> and <literal>/etc/openvpn/dh.pem</literal>). The <literal>server 10.8.0.0 255.255.255.0</literal> directive defines the subnet to be used by the VPN; the server uses the first IP address in that range (<literal>10.8.0.1</literal>) and the rest of the addresses are allocated to clients.
nb-NO: Som forvalg forsøker OpenVPN-initialiseringskriptet å starte alle virtuelle private nettverk som er definert i <filename>/etc/openvpn/*.conf</filename>. Å sette opp en VPN-tjener er derfor et spørsmål om å lagre en tilsvarende oppsettsfil i denne katalogen. Et godt utgangspunkt er <filename>/usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz</filename>, som leder til en temmelig vanlig oppsatt tjener. Selvfølgelig må noen parametere tilpasses: <literal>ca</literal>, <literal>cert</literal>, <literal>key</literal> og <literal>dh</literal> må beskrive de valgte stedene (henholdsvis <literal>/etc/ssl/certs/Falcot_CA.crt</literal>, <literal>/etc/ssl/vpn.falcot.com.crt</literal>, <literal>/etc/ssl/private/vpn.falcot.com.key</literal> og <literal>/etc/openvpn/dh.pem</literal>). <literal>server 10.8.0.0 255.255.255.0</literal>-direktivet definerer subnettet som skal brukes av VPN; tjeneren bruker den første IP-adressen i dette området (<literal>10.8.0.1</literal>), og resten av adressene er reservert for klienter.

en: <primary>network</primary><secondary>virtual interface</secondary>
nb-NO: <primary>nettverk</primary><secondary>virtuelt grensesnitt</secondary>

en: With this configuration, starting OpenVPN creates the virtual network interface, usually under the <literal>tun0</literal> name. However, firewalls are often configured at the same time as the real network interfaces, which happens before OpenVPN starts. Good practice therefore recommends creating a persistent virtual network interface, and configuring OpenVPN to use this pre-existing interface. This further allows choosing the name for this interface. To this end, <command>openvpn --mktun --dev vpn --dev-type tun</command> creates a virtual network interface named <literal>vpn</literal> with type <literal>tun</literal>; this command can easily be integrated in the firewall configuration script, or in an <literal>up</literal> directive of the <filename>/etc/network/interfaces</filename> file, or a <emphasis role="package">udev</emphasis> rule can be added to that end. The OpenVPN configuration file must also be updated accordingly, with the <literal>dev vpn</literal> and <literal>dev-type tun</literal> directives.
nb-NO: Med dette oppsettet lager oppstarten av OpenVPN det virtuelle nettverksgrensesnittet, vanligvis med <literal>tun0</literal>-navnet. Imidlertid er brannmurer ofte satt opp på samme tid som det virkelige nettverksgrensesnittet, og skjer før OpenVPN starter. En god praksis er derfor å lage et varig virtuelt nettverksgrensesnitt, og sette opp OpenVPN til å bruke dette varige grensesnittet. Dette tillater videre å velge navnet til dette grensesnittet. For dette formål lager <command>openvpn --mktun --dev vpn --dev-type tun</command> et virtuelt nettverksbrukergrensesnitt med navnet <literal>vpn</literal> med type <literal>tun</literal>; denne kommandoen kan enkelt legges inn i brannmuroppsettets skript, eller i et <literal>up</literal>-direktiv i <filename>/etc/network/interfaces</filename>-filen, eller en <emphasis role="package">udev</emphasis> regel kan bli lagt til den enden. OpenVPN-oppsettfilen må også oppdateres tilsvarende, med <literal>dev vpn</literal> og <literal>dev-type tun</literal>-direktiver.

en: Barring further action, VPN clients can only access the VPN server itself by way of the <literal>10.8.0.1</literal> address. Granting the clients access to the local network (192.168.0.0/24), requires adding a <literal>push route 192.168.0.0 255.255.255.0</literal> directive to the OpenVPN configuration so that VPN clients automatically get a network route telling them that this network is reachable by way of the VPN. Furthermore, machines on the local network also need to be informed that the route to the VPN goes through the VPN server (this automatically works when the VPN server is installed on the gateway). Alternatively, the VPN server can be configured to perform IP masquerading so that connections coming from VPN clients appear as if they are coming from the VPN server instead (see <xref linkend="sect.gateway" />).
nb-NO: For å sperre ytterligere virksomhet kan VPN-klienter kun få tilgang til selve VPN-tjeneren ved hjelp av <literal>10.8.0.1</literal>-adressen. Å gi klientene tilgang til det lokale nettverket (192.168.0.0/24), krever at en legger til et <literal>push route 192.168.0.0 255.255.255.0</literal>-direktiv til OpenVPN-oppsettet slik at VPN-klienter automatisk får en nettverksrute som forteller dem at dette nettverket kan nås ved hjelp av VPN. Videre, maskiner på det lokale nettverket må også informeres om at ruten til VPN går gjennom VPN-tjeneren (dette fungerer automatisk når VPN-tjeneren er installert i porten). Alternativt kan VPN-tjeneren settes opp til å utføre IP-maskering, slik at tilkoblinger fra VPN-klienter ser ut som om de kommer fra VPN-tjeneren i stedet (se <xref linkend="sect.gateway" />).

en: Configuring the OpenVPN Client
nb-NO: Oppsett av OpenVPN-klienten

en: Setting up an OpenVPN client also requires creating a configuration file in <filename>/etc/openvpn/</filename>. A standard configuration can be obtained by using <filename>/usr/share/doc/openvpn/examples/sample-config-files/client.conf</filename> as a starting point. The <literal>remote vpn.falcot.com 1194</literal> directive describes the address and port of the OpenVPN server; the <literal>ca</literal>, <literal>cert</literal> and <literal>key</literal> also need to be adapted to describe the locations of the key files.
nb-NO: Å sette opp en OpenVPN-klient krever også at en lager en oppsettsfil <filename>/etc/openvpn/</filename>. Et standardoppsett kan fås ved å bruke <filename>/usr/share/doc/openvpn/examples/sample-config-files/client.conf</filename> som et startpunkt. <literal>remote vpn.falcot.com 1194</literal>-direktivet beskriver adressen og porten til OpenVPN-tjeneren; <literal>ca</literal>, <literal>cert</literal> og <literal>key</literal> må også tilpasses til å beskrive plasseringen av de viktigste filene.

en: If the VPN should not be started automatically on boot, set the <literal>AUTOSTART</literal> directive to <literal>none</literal> in the <filename>/etc/default/openvpn</filename> file. Starting or stopping a given VPN connection is always possible with the commands <command>systemctl start openvpn@<replaceable>name</replaceable></command> and <command>systemctl stop openvpn@<replaceable>name</replaceable></command> (where the connection <replaceable>name</replaceable> matches the one defined in <filename>/etc/openvpn/<replaceable>name</replaceable>.conf</filename>).
nb-NO: Hvis VPN ikke skal startes automatisk ved oppstart, sett <literal>AUTOSTART</literal>-direktivet til <literal>none</literal> i <filename>/etc/default/openvpn</filename>-filen. Å starte eller stoppe en gitt VPN-forbindelse er alltid mulig med kommandoene <command>systemctl start openvpn@<replaceable>name</replaceable> start</command> og <command>systemctl stop openvpn@<replaceable>name</replaceable> stop</command> (der forbindelsen <replaceable>name</replaceable> sammenfaller med den som er definert i <filename>/etc/openvpn/<replaceable>name</replaceable>.conf</filename>).

en: Virtual Private Network with SSH
nb-NO: Virtuelt privat nettverk med SSH

en: There are actually two ways of creating a virtual private network with SSH. The historic one involves establishing a PPP layer over the SSH link. This method is described in a HOWTO document: <ulink type="block" url="https://www.tldp.org/HOWTO/ppp-ssh/" />
nb-NO: Det er faktisk to måter å lage et virtuelt privat nettverk ved hjelp av SSH. Den historiske innebærer å etablere et PPP-lag over SSH-linken. Denne metoden er beskrevet i et HOWTO-dokument: <ulink type="block" url="https://www.tldp.org/HOWTO/ppp-ssh/" />

en: The second method is more recent, and was introduced with OpenSSH 4.3; it is now possible for OpenSSH to create virtual network interfaces (<literal>tun*</literal>) on both sides of an SSH connection, and these virtual interfaces can be configured exactly as if they were physical interfaces. The tunneling system must first be enabled by setting <literal>PermitTunnel</literal> to “yes” in the SSH server configuration file (<filename>/etc/ssh/sshd_config</filename>). When establishing the SSH connection, the creation of a tunnel must be explicitly requested with the <literal>-w any:any</literal> option (<literal>any</literal> can be replaced with the desired <literal>tun</literal> device number). This requires the user to have administrator privilege on both sides, so as to be able to create the network device (in other words, the connection must be established as root).
nb-NO: Den andre metoden er av nyere dato, og ble introdusert med OpenSSH 4.3: Det er nå mulig for OpenSSH å opprette virtuelle nettverksgrensesnitt (<literal>tun*</literal>) på begge sider av en SSH-tilkobling, og disse virtuelle grensesnitt kan settes opp akkurat som om de var fysiske grensesnitt. Tunnelsystemet må først aktiveres ved å sette <literal>PermitTunnel</literal> til «yes» i SSH-tjenerens oppsettsfil (<filename>/etc/ssh/sshd_config</filename>). Når SSH-tilkoblingen etableres, må det eksplisitt bes om at det lages en tunnel med <literal>-w any:any</literal> valget/alternativet (<literal>any</literal> kan erstattes med det ønskede <literal>tun</literal> enhetsnummeret). Dette krever at brukeren har administratorprivilegium på begge sider, for å kunne lage nettverksenheten (med andre ord, må forbindelsen etableres som rot).

en: Both methods for creating a virtual private network over SSH are quite straightforward. However, the VPN they provide is not the most efficient available; in particular, it does not handle high levels of traffic very well.
nb-NO: Begge måter for å opprette et virtuelt privat nettverk over SSH er ganske greie. Men VPN-en er ikke den mest effektivt tilgjengelige; særlig håndterer den ikke høye trafikknivåer godt.

en: The explanation is that when a TCP/IP stack is encapsulated within a TCP/IP connection (for SSH), the TCP protocol is used twice, once for the SSH connection and once within the tunnel. This leads to problems, especially due to the way TCP adapts to network conditions by altering timeout delays. The following site describes the problem in more detail: <ulink type="block" url="http://sites.inka.de/sites/bigred/devel/tcp-tcp.html" />
nb-NO: Forklaringen er at når en TCP/IP-stakk er innkapslet innenfor en TCP/IP-tilkobling (for SSH), er TCP-protokollen brukt to ganger, en gang for SSH-tilkoblingen og en gang inne i tunnelen. Dette fører til problemer, særlig på grunn av måten TCP tilpasser seg til nettverksforholdene ved å endre forsinkelser ved tidsavbrudd. Følgende nettsted beskriver problemet i mer detalj: <ulink type="block" url="http://sites.inka.de/sites/bigred/devel/tcp-tcp.html" />

en: VPNs over SSH should therefore be restricted to one-off tunnels with no performance constraints.
nb-NO: VPN over SSH bør derfor begrenses til engangstunneler uten ytelsesbegrensninger.

en: First, we install the <emphasis role="pkg">libreswan</emphasis> package. In concrete terms, each host's <filename>/etc/ipsec.conf</filename> contains the parameters for <emphasis>IPsec tunnels</emphasis> (or <emphasis>Security Associations</emphasis>, in the IPsec terminology) that the host is concerned with. There are many configuration examples in <filename>/usr/share/doc/libreswan/</filename>, but Libreswan's online documentation has more examples with explanations: <ulink type="block" url="https://libreswan.org/wiki/" />
nb-NO: Først installerer vi <emphasis role="pkg">libreswan</emphasis> pakken. Konkrete termer inneholder hver verts <filename>/etc/ipsec.conf</filename> inneholder parameterne for <emphasis>IPsec-tunnels</emphasis> (eller <emphasis>Security Associations</emphasis>, i IPsec-terminologien) som gjelder verten. Det finnes mange oppsetteksempler i <filename>/usr/share/doc/libreswan/</filename>, og Libreswans elektroniske dokumentasjon har flere eksempler med forklaringer: <ulink type="block" url="https://libreswan.org/wiki/" />

en: The IPsec service can be controlled with <command>systemctl</command>; for example, <command>systemctl start ipsec</command> will start the IPsec service.
nb-NO: IPsec-tjenesten kan kontrolleres med <command>systemctl</command>; for eksempel vil <command>systemctl start ipsec</command> starte IPsec-tjenesten.

en: In spite of its status as the reference, the complexity of setting up IPsec restricts its usage in practice. OpenVPN-based solutions will generally be preferred when the required tunnels are neither too many nor too dynamic.
nb-NO: På tross av sin status som referanse; kompleksiteten ved å sette opp IPsec begrenser bruken i praksis. OpenVPN-baserte løsninger vil vanligvis bli foretrukket når de nødvendige tunnelene verken er for mange eller for dynamiske.

en: <emphasis>CAUTION</emphasis> IPsec and NAT
nb-NO: <emphasis>VÆR VARSOM</emphasis> IPsec og NAT

en: NATing firewalls and IPsec do not work well together: since IPsec signs the packets, any change on these packets that the firewall might perform will void the signature, and the packets will be rejected at their destination. Various IPsec implementations now include the <emphasis>NAT-T</emphasis> technique (for <emphasis>NAT Traversal</emphasis>), which basically encapsulates the IPsec packet within a standard UDP packet.
nb-NO: NAT brannmurer og IPsec fungerer ikke godt sammen: Ettersom IPsec signerer pakker, vil eventuelle forandringer for disse pakkene som brannmuren måtte utføre, oppheve signaturen, og pakkene vil bli avvist ved bestemmelsesstedet. Ulike IPsec-implementasjoner inkluderer nå <emphasis>NAT-T</emphasis>-teknikk (for <emphasis>NAT Traversal</emphasis>), som i utgangspunktet innkapsler IPsec-pakken innenfor en standard UDP-pakke.

en: <emphasis>SECURITY</emphasis> IPsec and firewalls
nb-NO: <emphasis>SIKKERHET</emphasis> IPsec og brannmurer

en: <primary>ESP, protocol</primary>
nb-NO: <primary>ESP, protokoll</primary>

en: <primary>AH, protocol</primary>
nb-NO: <primary>AH,protokoll</primary>

en: <primary>protocol</primary><secondary>AH</secondary>
nb-NO: <primary>protokoll</primary><secondary>AH</secondary>

en: <primary>protocol</primary><secondary>ESP</secondary>
nb-NO: <primary>protokoll</primary><secondary>ESP</secondary>

en: The standard mode of operation of IPsec involves data exchanges on UDP port 500 for key exchanges (also on UDP port 4500 in the case that NAT-T is in use). Moreover, IPsec packets use two dedicated IP protocols that the firewall must let through; reception of these packets is based on their protocol numbers, 50 (ESP) and 51 (AH).
nb-NO: Standardmoduset for drift av IPsec innebærer datautveksling på UDP-port 500 for nøkkelutveksling (også på UDP-port 4500 i tilfelle NAT-T er i bruk). Videre, bruker IPsec-pakker to øremerkede IP-protokoller som brannmuren må slippe igjennom; mottakelse av disse pakkene er basert på protokollnummeret deres, 50 (ESP) og 51 (AH).

en: <primary>GRE, protocol</primary>
nb-NO: <primary>GRE, protokolll</primary>

en: <primary>protocol</primary><secondary>GRE</secondary>
nb-NO: <primary>protokoll</primary><secondary>GRE</secondary>

en: PPTP (for <emphasis>Point-to-Point Tunneling Protocol</emphasis>) uses two communication channels, one for control data and one for payload data; the latter uses the GRE protocol (<emphasis>Generic Routing Encapsulation</emphasis>). A standard PPP link is then set up over the data exchange channel.
nb-NO: PPTP (som betyr punkt-til-punkt tunnelingsprotokoll, på engelsk <emphasis>Point-to-Point Tunneling Protocol</emphasis>) bruker to kommunikasjonskanaler, en for styringsdata og en for nyttelastdata; sistnevnte bruker GRE-protokollen (som betyr generisk ruting innkapsling, på engelsk <emphasis>Generic Routing Encapsulation</emphasis>). En standard PPP-forbindelse blir da satt opp over datautvekslingskanalen.

en: Configuring the Client
nb-NO: Oppsett av klienten

en: The <emphasis role="pkg">pptp-linux</emphasis> package contains an easily-configured PPTP client for Linux. The following instructions take their inspiration from the official documentation: <ulink type="block" url="http://pptpclient.sourceforge.net/howto-debian.phtml" />
nb-NO: Pakken <emphasis role="pkg">pptp-linux</emphasis> inneholder en lett oppsettbar PPTP-klient for Linux. Følgende instruksjoner er inspirert fra den offisielle dokumentasjonen: <ulink type="block" url="http://pptpclient.sourceforge.net/howto-debian.phtml" />

en: The Falcot administrators created several files: <filename>/etc/ppp/options.pptp</filename>, <filename>/etc/ppp/peers/falcot</filename>, <filename>/etc/ppp/ip-up.d/falcot</filename>, and <filename>/etc/ppp/ip-down.d/falcot</filename>.
nb-NO: Falcot-administratorene laget flere filer: <filename>/etc/ppp/options.pptp</filename>, <filename>/etc/ppp/peers/falcot</filename>, <filename>/etc/ppp/ip-up.d/falcot</filename>, og <filename>/etc/ppp/ip-down.d/falcot</filename>.

en: The <filename>/etc/ppp/options.pptp</filename> file
nb-NO: Filen <filename>/etc/ppp/options.pptp</filename>

en: 
    # PPP options used for a PPTP connection
    lock
    noauth
    nobsdcomp
    nodeflate
nb-NO: 
    # PPP-valg brukt med en PPTP-forbindelse
    lock
    noauth
    nobsdcomp
    nodeflate

en: The <filename>/etc/ppp/peers/falcot</filename> file
nb-NO: Filen <filename>/etc/ppp/peers/falcot</filename>

en: 
    # vpn.falcot.com is the PPTP server
    pty "pptp vpn.falcot.com --nolaunchpppd"
    # the connection will identify as the "vpn" user
    user vpn
    remotename pptp
    # encryption is needed
    require-mppe-128
    file /etc/ppp/options.pptp
    ipparam falcot
nb-NO: 
    # vpn.falcot.com er PPTP-tjeneren
    pty "pptp vpn.falcot.com --nolaunchpppd"
    # forbindelsen vil identifisere seg som "vpn"-brukeren
    user vpn
    remotename pptp
    # kryptering trengs
    require-mppe-128
    file /etc/ppp/options.pptp
    ipparam falcot

en: The <filename>/etc/ppp/ip-up.d/falcot</filename> file
nb-NO: Filen <filename>/etc/ppp/ip-up.d/falcot</filename>

en: The <filename>/etc/ppp/ip-down.d/falcot</filename> file
nb-NO: Filen <filename>/etc/ppp/ip-down.d/falcot</filename>

en: <emphasis>SECURITY</emphasis> MPPE
nb-NO: <emphasis>SIKKERHET</emphasis> MPPE

en: Securing PPTP involves using the MPPE feature (<emphasis>Microsoft Point-to-Point Encryption</emphasis>), which is available in official Debian kernels as a module.
nb-NO: Å sikre PPTP innebærer å bruke MPPE-funksjonen (Microsoft punkt-til-punkt kryptering: <emphasis>Microsoft Point-to-Point Encryption</emphasis>), som er tilgjengelig som en modul i offisielle Debian-kjerner.

en: Configuring the Server
nb-NO: Oppsett av tjenermaskinen

en: <emphasis>CAUTION</emphasis> PPTP and firewalls
nb-NO: <emphasis>VÆR VARSOM</emphasis> PPTP og brannmurer

en: Intermediate firewalls need to be configured to let through IP packets using protocol 47 (GRE). Moreover, the PPTP server's port 1723 needs to be open so that the communication channel can happen.
nb-NO: Mellomliggende brannmurer må settes opp til å slippe gjennom IP-pakker som bruker protokollen 47 (GRE). Videre må PPTP-tjenerport 1723 være åpen, slik at kommunikasjonskanalen virker.

en: <command>pptpd</command> is the PPTP server for Linux. Its main configuration file, <filename>/etc/pptpd.conf</filename>, requires very few changes: <emphasis>localip</emphasis> (local IP address) and <emphasis>remoteip</emphasis> (remote IP address). In the example below, the PPTP server always uses the <literal>192.168.0.199</literal> address, and PPTP clients receive IP addresses from <literal>192.168.0.200</literal> to <literal>192.168.0.250</literal>.
nb-NO: <command>pptpd</command> er PPTP-tjeneren for Linux. Hovedoppsettsfilen, <filename>/etc/pptpd.conf</filename>, krever svært få endringer: <emphasis>localip</emphasis> (lokal IP-adresse), og <emphasis>remoteip</emphasis> (ekstern IP-adresse). I eksempelet nedenfor bruker PPTP-tjeneren alltid <literal>192.168.0.199</literal>-adressen, og PPTP-klienter mottar IP-adresser fra <literal>192.168.0.200</literal> til <literal>192.168.0.250</literal>.

en: The <filename>/etc/pptpd.conf</filename> file
nb-NO: Filen <filename>/etc/pptpd.conf</filename>

en: The PPP configuration used by the PPTP server also requires a few changes in <filename>/etc/ppp/pptpd-options</filename>. The important parameters are the server name (<literal>pptp</literal>), the domain name (<literal>falcot.com</literal>), and the IP addresses for DNS and WINS servers.
nb-NO: PPP-oppsettet som brukes av PPTP-tjeneren krever også noen endringer i <filename>/etc/ppp/pptpd-options</filename>. De viktige parametre er tjenernavnet (<literal>pptp</literal>), domenenavnet (<literal>falcot.com</literal>), og IP-adressene for DNS- og WINS-tjenere.

en: The <filename>/etc/ppp/pptpd-options</filename> file
nb-NO: Filen <filename>/etc/ppp/pptpd-options</filename>

en: The last step involves registering the <literal>vpn</literal> user (and the associated password) in the <filename>/etc/ppp/chap-secrets</filename> file. Contrary to other instances where an asterisk (<literal>*</literal>) would work, the server name must be filled explicitly here. Furthermore, Windows PPTP clients identify themselves under the <literal><replaceable>DOMAIN</replaceable>\\<replaceable>USER</replaceable></literal> form, instead of only providing a user name. This explains why the file also mentions the <literal>FALCOT\\vpn</literal> user. It is also possible to specify individual IP addresses for users; an asterisk in this field specifies that dynamic addressing should be used.
nb-NO: Det siste trinnet innebærer registrering av <literal>vpn</literal>-brukeren (og tilhørende passord) i <filename>/etc/ppp/chap-secrets</filename>-filen. I motsetning til andre tilfeller hvor en asterisk (<literal>*</literal>) ville fungere, må tjenernavnet fylles inn eksplisitt her. Videre identifiserer Windows PPTP-klienter seg med <literal><replaceable>DOMENE</replaceable>\\<replaceable>BRUKER</replaceable></literal>-formen, i stedet for bare å gi et brukernavn. Dette forklarer hvorfor filen også nevner <literal>FALCOT\\vpn</literal>-brukeren. Det er også mulig å spesifisere individuelle IP-adresser for brukere; en stjerne i dette feltet angir at dynamisk adressering skal brukes.

en: The <filename>/etc/ppp/chap-secrets</filename> file
nb-NO: Filen <filename>/etc/ppp/chap-secrets</filename>

en: 
    # Secrets for authentication using CHAP
    # client        server  secret      IP addresses
    vpn             pptp    f@Lc3au     *
    FALCOT\\vpn     pptp    f@Lc3au     *
nb-NO: 
    # Hemmeligheter for autentisering vha. CHAP
    # klient        tjener  hemmelighet      IP-adresser
    vpn             pptp    f@Lc3au     *
    FALCOT\\vpn     pptp    f@Lc3au     *

en: <emphasis>SECURITY</emphasis> PPTP vulnerabilities
nb-NO: <emphasis>SIKKERHET</emphasis> PPTP-sårbarheter

en: Microsoft's first PPTP implementation drew severe criticism because it had many security vulnerabilities; most have since then been fixed in more recent versions. The configuration documented in this section uses the latest version of the protocol. Be aware though that removing some options (such as <literal>require-mppe-128</literal> and <literal>require-mschap-v2</literal>) would make the service vulnerable again.
nb-NO: Microsofts første PPTP-implementering fikk sterk kritikk fordi den hadde mange sikkerhetsproblemer; siden er de fleste fikset i og med nyere versjoner. Oppsettet som er dokumentert i denne seksjonen bruker den nyeste versjonen av protokollen. Vær klar over at å fjerne noen av alternativene (for eksempel <literal>require-mppe-128</literal> og <literal>require-mschap-v2</literal>) vil gjøre tjenesten sårbar igjen.

en: Quality of Service
nb-NO: Tjenestekvalitet

en: Principle and Mechanism
nb-NO: Prinsipp og mekanisme

en: <emphasis>Quality of Service</emphasis> (or <emphasis>QoS</emphasis> for short) refers to a set of techniques that guarantee or improve the quality of the service provided to applications. The most popular such technique involves classifying the network traffic into categories, and differentiating the handling of traffic according to which category it belongs to. The main application of this differentiated services concept is <emphasis>traffic shaping</emphasis>, which limits the data transmission rates for connections related to some services and/or hosts so as not to saturate the available bandwidth and starve important other services. Traffic shaping is a particularly good fit for TCP traffic, since this protocol automatically adapts to available bandwidth.
nb-NO: <emphasis>Quality of Service</emphasis> (eller i kortform <emphasis>QoS</emphasis>) refererer til et sett av teknikker som garanterer eller forbedrer kvaliteten på tjenesten som leveres til programmer. Den mest populære teknikken innebærer å klassifisere nettverkstrafikk i kategorier, og differensiere håndtering av trafikken etter hvilken kategori den tilhører. Den viktigste anvendelsen av dette differensierte tjenesteopplegget er <emphasis>traffic shaping</emphasis>, som begrenser dataoverføringshastigheten for forbindelser knyttet til enkelte tjenester og/eller verter for ikke å mette den tilgjengelige båndbredden og sulte/bremse viktige andre tjenester. «Traffic shaping» er spesielt god egnet for TCP-trafikk, siden denne protokollen automatisk tilpasser seg til tilgjengelig båndbredde.

en: <emphasis>CULTURE</emphasis> Net neutrality and QoS
nb-NO: <emphasis>KULTUR</emphasis> Nettnøytralitet og tjenestekvalitet

en: Network neutrality is achieved when Internet service providers treat all Internet communications equally, that is, without any access limitation based on content, user, website, destination address, etc.
nb-NO: Nettverksnøytralitet oppnås når Internett-leverandører behandler all Internett-kommunikasjon likt, det vil si uten tilgangsbegrensning basert på innhold, bruker, nettsted, destinasjonsadresse, etc.

en: Quality of service can be implemented in a net neutral Internet, but only if Internet service providers can't charge a special fee for a higher-quality service.
nb-NO: Kvaliteten på tjenesten kan implementeres på et nettnøytralt Internett, men bare hvis Internett-leverandører ikke kan belaste en spesiell avgift for en tjeneste av høyere kvalitet.

en: It is also possible to alter the priorities on traffic, which allows prioritizing packets related to interactive services (such as <command>ssh</command> and <command>telnet</command>) or to services that only deal with small blocks of data.
nb-NO: Det er også mulig å endre trafikkprioriteringene, slik at de tillater prioritering av pakker knyttet til interaktive tjenester (som for eksempel <command>ssh</command> og <command>telnet</command>), eller av tjenester som kun omfatter små blokker av data.

en: The Debian kernels include the features required for QoS along with their associated modules. These modules are many, and each of them provides a different service, most notably by way of special schedulers for the queues of IP packets; the wide range of available scheduler behaviors spans the whole range of possible requirements.
nb-NO: Debian-kjerner inkluderer funksjonene som kreves for QoS og sammen med de modulene som hører til. Disse modulene er mange, og hver av dem gir en annen tjeneste, særlig i form av spesielle planleggere for køer av IP-pakker; det brede utvalget av oppgaver for de tilgjengelige planleggere spenner over hele spekteret av mulige krav.

en: <emphasis>CULTURE</emphasis> LARTC — <emphasis>Linux Advanced Routing &amp; Traffic Control</emphasis>
nb-NO: <emphasis>KULTUR</emphasis> LARTC — <emphasis>Linux Advanced Routing &amp; Traffic Control</emphasis>

en: <primary>routing</primary><secondary>advanced</secondary>
nb-NO: <primary>ruting</primary><secondary>avansert</secondary>

en: <primary>traffic</primary><secondary>control</secondary>
nb-NO: <primary>trafikk</primary><secondary>kontroll</secondary>

en: <primary>control of traffic</primary>
nb-NO: <primary>kontroll av trafikk</primary>

en: The <emphasis>Linux Advanced Routing &amp; Traffic Control</emphasis> HOWTO is the reference document covering everything there is to know about network quality of service. <ulink type="block" url="https://www.lartc.org/howto/" />
nb-NO: <emphasis>Linux Advanced Routing &amp; Traffic Control</emphasis>-oppskriften er referansedokumentet som dekker alt det er å vite om nett-tjenestekvalitet. <ulink type="block" url="https://www.lartc.org/howto/" />

en: Configuring and Implementing
nb-NO: Oppsett og implementering

en: QoS parameters are set through the <command>tc</command> command (provided by the <emphasis role="pkg">iproute</emphasis> package). Since its interface is quite complex, using higher-level tools is recommended.
nb-NO: QoS-parametrene settes med <command>tc</command>-kommandoen (gitt av <emphasis role="pkg">iproute</emphasis>-pakken). Siden grensesnittet er ganske komplisert, anbefales det å bruke et høyere-nivå verktøy.

en: Reducing Latencies: <command>wondershaper</command>
nb-NO: Redusere ventetider : <command>wondershaper</command>

en: <primary>limitation of traffic</primary>
nb-NO: <primary>begrensning av datatrafikken</primary>

en: <primary>traffic</primary><secondary>limitation</secondary>
nb-NO: <primary>trafikk</primary><secondary>begrensning</secondary>

en: The main purpose of <command>wondershaper</command> (in the similarly-named package) is to minimize latencies independent of network load. This is achieved by limiting total traffic to a value that falls just short of the link saturation value.
nb-NO: Hovedformålet til <command>wondershaper</command> (i pakken med tilsvarende navn) er å minimalisere ventetider uavhengig av nettverksbelastning. Dette oppnås ved å begrense den totale trafikken til en verdi som faller like under lenkens metningsverdi.

en: Changes in the <filename>/etc/network/interfaces</filename> file
nb-NO: Forandringer i <filename>/etc/network/interfaces</filename>-filen

en: <emphasis>GOING FURTHER</emphasis> Optimal configuration
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Optimalt oppsett

en: The <filename>/usr/share/doc/wondershaper/README.Debian.gz</filename> file describes, in some detail, the configuration method recommended by the package maintainer. In particular, it advises measuring the download and upload speeds so as to best evaluate real limits.
nb-NO: Filen <filename>/usr/share/doc/wondershaper/README.Debian.gz</filename> beskriver i detalj pakkeutviklerens anbefalte oppsettsmetode. Spesielt rådes det til å måle nedlastings- og opplastingshastigheter for best å kunne bedømme reelle grenser.

en: Standard Configuration
nb-NO: Standardoppsett

en: The DSCP field can be set by applications that generate IP packets, or modified on the fly by <emphasis>netfilter</emphasis>. The following rules are sufficient to increase responsiveness for a server's SSH service, note that the DSCP field must be set in hexadecimal:
nb-NO: DSCP-feltet kan angis av programmer som genererer IP-pakker, eller endres i farten med <emphasis>netfilter</emphasis>. Følgende regler er tilstrekkelige til å øke responsen for en tjeners SSH-tjeneste, vær oppmerksom på at DSCP-feltet må angis i heksadesimal:

en: Dynamic Routing
nb-NO: Dynamisk ruting

en: <emphasis>BACK TO BASICS</emphasis> Dynamic routing
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Dynamisk ruting

en: Dynamic routing allows routers to adjust, in real time, the paths used for transmitting IP packets. Each protocol involves its own method of defining routes (shortest path, use routes advertised by peers, and so on).
nb-NO: Dynamisk ruting tillater rutere å justere, i sanntid, de banene som brukes til overføring av IP-pakker. Hver protokoll involverer sin egen metode til å definere ruter (korteste veien, bruke ruter varslet av andre brukere/tjenere, og så videre).

en: In the Linux kernel, a route links a network device to a set of machines that can be reached through this device. The <command>ip</command> command, when <literal>route</literal> is used as the first argument, defines new routes and displays existing ones. The <command>route</command> command was used for that purpose, but it is deprecated in favor of <command>ip</command>.
nb-NO: I Linux-kjernen kobler en rute en nettverksenhet til et sett med maskiner som kan nås via denne enheten. <command>ip</command>-kommandoen, når <literal>rute</literal> brukes som det første argumentet, definerer nye ruter og viser eksisterende. <command>route</command>-kommandoen ble brukt til dette formålet, men den er avskrevet til fordel for <command>ip</command>.

en: <emphasis>IN PRACTICE</emphasis> OSPF, BGP or RIP?
nb-NO: <emphasis>I PRAKSIS</emphasis> OSPF, BGP eller RIP?

en: <acronym>OSPF</acronym> (Open Shortest Path First) is generally the best protocol to use for dynamic routing on private networks, but <acronym>BGP</acronym> (Border Gateway Protocol) is more common for Internet-wide routing. <acronym>RIP</acronym> (Routing Information Protocol) is rather ancient, and hardly used anymore.
nb-NO: <acronym>OSPF</acronym> (Open Shortest Path First) er vanligvis den beste protokollen å brukes for dynamisk ruting på private nettverk, men <acronym>BGP</acronym> (Border Gateway Protocol) er mer vanlig for Internett-ruting. <acronym>RIP</acronym> (Routing Information Protocol) er ganske forhistorisk, og knapt brukt lenger.

en: Debian kernels include IPv6 handling in the core kernel (with the exception of some architectures that have it compiled as a module named <literal>ipv6</literal>). Basic tools such as <command>ping</command> and <command>traceroute</command> have their IPv6 equivalents in <command>ping6</command> and <command>traceroute6</command>, available respectively in the <emphasis role="pkg">iputils-ping</emphasis> and <emphasis role="pkg">iputils-tracepath</emphasis> packages.
nb-NO: Debian kjerner inkluderer IPv6-håndtering i kjernen (med unntak av noen arkitekturer som har den samlet som en modul som heter <literal>ipv6</literal>). Basisverktøy som <command>ping</command> og <command>traceroute</command> har sine IPv6-ekvivalenter i <command>ping6</command> og <command>traceroute6</command>, respektivt tilgjengelig i <emphasis role="pkg">iputils-ping</emphasis>- og <emphasis role="pkg">iputils-tracepath</emphasis>-pakkene.

en: The IPv6 network is configured similarly to IPv4, in <filename>/etc/network/interfaces</filename>. But if you want that network to be globally available, you must ensure that you have an IPv6-capable router relaying traffic to the global IPv6 network.
nb-NO: IPv6-nettverket er satt opp på samme måte som IPv4, i <filename>/etc/network/interfaces</filename>. Men vil du at nettverket skal være globalt tilgjengelig, må du sørge for at du har en IPv6-kompatibel ruter som videresender trafikk til det globale IPv6-nettverket.

en: Example of IPv6 configuration
nb-NO: Eksempel på IPv6-oppsett

en: <primary>Stateless Address Autoconfiguration</primary><see>SLAAC</see>
nb-NO: <primary>Tilstandsløs adresse-autooppsett</primary><see>SLAAC</see>

en: IPv6 subnets usually have a netmask of 64 bits. This means that 2<superscript>64</superscript> distinct addresses exist within the subnet. This allows Stateless Address Autoconfiguration (<acronym>SLAAC</acronym>) to pick an address based on the network interface's MAC address. By default, if <acronym>SLAAC</acronym> is activated in your network and IPv6 on your computer, the kernel will automatically find IPv6 routers and configure the network interfaces.
nb-NO: IPv6 subnett har vanligvis en nettmaske på 64 bit. Dette betyr at 2<superscript>64</superscript> distinkte adresser eksisterer innenfor subnettet. Dette tillater Stateless Address Autoconfigurasjon (<acronym>SLAAC</acronym>) å velge en adresse basert på nettverksgrensesnittets MAC-adresse. Som standard, dersom <acronym>SLAAC</acronym> er aktivert i nettverket, og IPv6 på din datamaskin, vil kjernen automatisk finne IPv6 rutere og sette opp nettverksgrensesnittet.

en: IPv6 privacy extensions
nb-NO: IPv6-personvernutvidelser

en: <emphasis>TIP</emphasis> Programs built with IPv6
nb-NO: <emphasis>TIPS</emphasis> Programmer bygd med IPv6

en: Many pieces of software need to be adapted to handle IPv6. Most of the packages in Debian have been adapted already, but not all. If your favorite package does not work with IPv6 yet, you can ask for help on the <emphasis>debian-ipv6</emphasis> mailing-list. They might know about an IPv6-aware replacement and could file a bug to get the issue properly tracked. <ulink type="block" url="https://lists.debian.org/debian-ipv6/" />
nb-NO: Mange deler av programvaren må tilpasses for å håndtere IPv6. De fleste av pakkene i Debian er tilpasset allerede, men ikke alle. Hvis din favorittpakke ikke fungerer med IPv6 ennå, kan du be om hjelp på <emphasis>debian-ipv6</emphasis> postliste. Kanskje vet de om en IPv6-klar erstatning, og kan sende inn en feilmelding og få spørsmålet ordentlig sporet. <ulink type="block" url="https://lists.debian.org/debian-ipv6/" />

en: <primary>firewall</primary><secondary>IPv6</secondary>
nb-NO: <primary>brannmur</primary><secondary>IPv6</secondary>

en: IPv6 connections can be restricted, in the same fashion as for IPv4. <command>nft</command> can be used to create firewall rules for IPv4 and IPv6 (see <xref linkend="sect.nftables" />).
nb-NO: IPv6-tilkoblinger kan begrenses, på samme måte som for IPv4. <command>nft</command> kan brukes til å opprette brannmurregler for IPv4 og IPv6 (se <xref linkend="sect.nftables" />).

en: Tunneling
nb-NO: Tunnellering

en: <emphasis>CAUTION</emphasis> IPv6 tunneling and firewalls
nb-NO: <emphasis>VÆR VARSOM</emphasis> IPv6-tunneling og brannmurer

en: IPv6 tunneling over IPv4 (as opposed to native IPv6) requires the firewall to accept the traffic, which uses IPv4 protocol number 41.
nb-NO: IPv6-tunneling over IPv4 (i motsetning til den innebygde IPv6) krever brannmuren til å godta trafikk som bruker IPv4-protokoll nummer 41.

en: If a native IPv6 connection is not available, the fallback method is to use a tunnel over IPv4. Hurricane Electric is one (free) provider of such tunnels: <ulink type="block" url="https://tunnelbroker.net" />
nb-NO: Hvis en lokal IPv6-tilkobling ikke er tilgjengelig, er den alternative metoden å bruke en tunnel over IPv4. Hurricane Electric er en (gratis) leverandør av slike tunneler: <ulink type="block" url="https://tunnelbroker.net" />

en: <primary>tunnel broker</primary>
nb-NO: <primary>tunnelmegler</primary>

en: To use a Hurricane Electric tunnel, you need to register an account, login, select a free tunnel and edit the file <filename>/etc/network/interfaces</filename> with the generated code.
nb-NO: For å bruke en Hurricane Electric-tunnel må du registrere en konto, logge inn, velge en gratis tunnel og redigere filen <filename>/etc/network/interfaces</filename> med den genererte koden.

en: You can install and configure the <command>radvd</command> daemon (from the similarly-named package) if you want to use the configured computer as a router for a local network. This IPv6 configuration daemon has a role similar to <command>dhcpd</command> in the IPv4 world.
nb-NO: Du kan installere og sette opp <command>radvd</command> bakgrunnsprosessen (fra pakken med samme navn) hvis du vil bruke den oppsatte datamaskinen som ruter for et lokalt nettverk. Denne IPv6-oppsettsbakgrunnsprosessen har en rolle som ligner på <command>dhcpd</command> i IPv4-verdenen.

en: The <filename>/etc/radvd.conf</filename> configuration file must then be created (see <filename>/usr/share/doc/radvd/examples/simple-radvd.conf</filename> as a starting point). In our case, the only required change is the prefix, which needs to be replaced with the one provided by Hurricane Electric; it can be found in the output of the <command>ip a</command> command, in the block concerning the <literal>he-ipv6</literal> interface.
nb-NO: <filename>/etc/radvd.conf</filename>-oppsettsfilen må så lages (se <filename>/usr/share/doc/radvd/examples/simple-radvd.conf</filename> som et startpunkt). I vårt tilfelle er det bare nødvendig å endre prefikset, som må erstattes med det som leveres av Hurricane Electric; det finnes i utdata fra <command>ip a</command>-kommandoen, i blokken som gjelder <literal>he-ipv6</literal>-brukergrensesnittet.

en: Then run <command>systemctl start radvd</command>. The IPv6 network should now work.
nb-NO: Kjør så <command>systemctl start radvd</command>. IPv6-nettverket skal nå virke.

en: Domain Name Servers (DNS)
nb-NO: Domenenavntjenere (DNS)

en: <primary>server</primary><secondary>name</secondary>
nb-NO: <primary>tjener</primary><secondary>navn</secondary>

en: DNS records are organized in zones; each zone matches either a domain (or a subdomain) or an IP address range (since IP addresses are generally allocated in consecutive ranges). A primary server is authoritative on the contents of a zone; secondary servers, usually hosted on separate machines, provide regularly refreshed copies of the primary zone.
nb-NO: DNS-oppføringer er organisert i soner; hver sone svarer enten til et domene (eller et underdomene), eller et IP-adresseområde (siden IP-adresser generelt tildeles fortløpende i rekkefølge). En primærtjener er autoritativ når det gjelder innholdet i en sone; sekundære tjenere, som vanligvis ligger på separate maskiner, gir jevnlig oppdaterte kopier av primærsonen.

en: <primary>zone</primary><secondary>DNS</secondary>
nb-NO: <primary>sone</primary><secondary>DNS</secondary>

en: <primary>DNS</primary><secondary>zone</secondary>
nb-NO: <primary>DNS</primary><secondary>sone</secondary>

en: Each zone can contain records of various kinds (<emphasis>Resource Records</emphasis>), these are some of the most common:
nb-NO: Hver sone kan inneholde registreringer av ulike slag (<emphasis>Resource Records</emphasis>): her er noen av de mest vanlige:

en: <literal>A</literal> (<emphasis>address record</emphasis>): IPv4 address. This is the most common form to point a domain to an IPv4 address.
nb-NO: <literal>A</literal> (<emphasis>adresseoppføring</emphasis>): IPv4-adresse. Dette er den vanligste måten å peke et domene til en IPv4-adresse.

en: <literal>AAAA</literal> (<emphasis>IPv6 address record</emphasis>): IPv6 address.
nb-NO: <literal>AAAA</literal> (<emphasis>IPv6-adresseoppføring</emphasis>): IPv6 address.

en: Furthermore, Bind supports the DNSSEC standard for signing (and therefore authenticating) DNS records, which allows blocking any spoofing of this data during man-in-the-middle attacks.
nb-NO: Videre støtter Bind DNSSEC-standarden for signering (og dermed autentisering) av DNS-opptak, som tillater blokkering av all forfalskning av data under man-in-the-middle angrep.

en: <emphasis>CULTURE</emphasis> DNSSEC
nb-NO: <emphasis>KULTUR</emphasis> DNSSEC

en: The DNSSEC norm is quite complex; this partly explains why it is not in widespread usage yet (even if it perfectly coexists with DNS servers unaware of DNSSEC). To understand all the ins and outs, you should check the following article. <ulink type="block" url="https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions" />
nb-NO: DNSSEC-normen er ganske komplisert: Det forklarer hvorfor den ikke er i utbredt bruk ennå (selv om den sameksisterer helt perfekt med DNS-tjenere som ikke er oppmerksomme på DNSSEC). For å forstå alle inn- og ut-detaljene, bør du sjekke følgende artikkel: <ulink type="block" url="https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions" />

en: Configuring bind
nb-NO: Oppsett av bind

en: Configuration files for <command>bind</command>, irrespective of version, have the same structure.
nb-NO: Oppsettsfiler for <command>bind</command>, uavhengig av versjon, har den samme strukturen.

en: The Falcot administrators created a primary <literal>falcot.com</literal> zone to store information related to this domain, and a <literal>168.192.in-addr.arpa</literal> zone for reverse mapping of IP addresses in the local networks.
nb-NO: Falcots administratorer opprettet en primær <literal>falcot.com</literal>-sone for å lagre informasjon relatert til dette domenet, og en <literal>168.192.in-addr.arpa</literal>-sone for reversert kartlegging av IP-adresser i de lokale nettverkene.

en: <emphasis>CAUTION</emphasis> Names of reverse zones
nb-NO: <emphasis>VÆR VARSOM</emphasis> Navn på revers-soner (omvendte soner)

en: <primary>zone</primary><secondary>reverse</secondary>
nb-NO: <primary>sone</primary><secondary>revers</secondary>

en: <primary>reverse zone</primary>
nb-NO: <primary>revers sone</primary>

en: <primary>nibble format</primary>
nb-NO: <primary>nibble-format</primary>

en: Reverse zones have a particular name. The zone covering the <literal>192.168.0.0/16</literal> network needs to be named <literal>168.192.in-addr.arpa</literal>: the IP address components are reversed, and followed by the <literal>in-addr.arpa</literal> suffix.
nb-NO: Reversersoner har litt sære navn. Sonen som omfatter <literal>192.168.0.0/16</literal>-nettet navngis som <literal>168.192.in-addr.arpa</literal>: Komponentene til IP-adressen er omvendt rekkefølge, og etterfulgt av <literal>in-addr.arpa</literal>-suffikset.

en: For IPv6 networks, the suffix is <literal>ip6.arpa</literal> and the IP address components which are reversed are each character in the full hexadecimal representation of the IP address. As such, the <literal>2001:0bc8:31a0::/48</literal> network would use a zone named <literal>0.a.1.3.8.c.b.0.1.0.0.2.ip6.arpa</literal>.
nb-NO: For IPv6-nettverk er suffikset <literal>ip6.arpa</literal> og IP-adressen komponenter som er reversert, er hvert tegn i full heksadesimal presentasjon av IP-adressen. Som sådan vil <literal>2001:0bc8:31a0::/48</literal>-nettverket bruke en sone med navnet <literal>0.a.1.3.8.c.b.0.1.0.0.2.ip6.arpa</literal>.

en: <emphasis>TIP</emphasis> Testing the DNS server
nb-NO: <emphasis>TIPS</emphasis> Å teste DNS-tjeneren

en: The <command>host</command> command (in the <emphasis role="pkg">bind9-host</emphasis> package) queries a DNS server, and can be used to test the server configuration. For example, <command>host machine.falcot.com localhost</command> checks the local server's reply for the <literal>machine.falcot.com</literal> query. <command>host <replaceable>ipaddress</replaceable> localhost</command> tests the reverse resolution.
nb-NO: Kommandoen <command>host</command> (i pakken <emphasis role="pkg">bind9-host</emphasis>) forespør en DNS-tjener, og kan bli brukt til å teste tjeneroppsettet. For eksempel sjekker <command>host machine.falcot.com localhost</command> den lokale tjenerens svar på forespørselen <literal>machine.falcot.com</literal>. <command>host <replaceable>ip-adresse</replaceable> localhost</command> tester reversoppslaget.

en: The following configuration excerpts, taken from the Falcot files, can serve as starting points to configure a DNS server:
nb-NO: Det følgende oppsettsutdraget, hentet fra Falcot-filene, kan tjene som utgangspunkt for å sette opp en DNS-server:

en: Excerpt of <filename>/etc/bind/named.conf.local</filename>
nb-NO: Utdag av <filename>/etc/bind/named.conf.local</filename>

en: Excerpt of <filename>/etc/bind/db.falcot.com</filename>
nb-NO: Utdrag av <filename>/etc/bind/db.falcot.com</filename>

en: ; falcot.com Zone 
    ; admin.falcot.com. =&gt; zone contact: admin@falcot.com
    $TTL    604800
    @       IN      SOA     falcot.com. admin.falcot.com. (
                            20040121        ; Serial
                             604800         ; Refresh
                              86400         ; Retry
                            2419200         ; Expire
                             604800 )       ; Negative Cache TTL
    ;
    ; The @ refers to the zone name ("falcot.com" here)
    ; or to $ORIGIN if that directive has been used
    ;
    @       IN      NS      ns
    @       IN      NS      ns0.xname.org.
    
    internal IN      NS      192.168.0.2
    
    @       IN      A       212.94.201.10
    @       IN      MX      5 mail
    @       IN      MX      10 mail2
    
    ns      IN      A       212.94.201.10
    mail    IN      A       212.94.201.10
    mail2   IN      A       212.94.201.11
    www     IN      A       212.94.201.11
    
    dns     IN      CNAME   ns
nb-NO: ; falcot.com-sonen
    ; admin.falcot.com. =&gt; zone contact: admin@falcot.com
    $TTL    604800
    @       IN      SOA     falcot.com. admin.falcot.com. (
                            20040121        ; Seriellnummer
                             604800         ; Fornying
                              86400         ; Nytt forsøk
                            2419200         ; Utløp
                             604800 )       ; Negativ mellomglagrings-TTL
    ;
    ; @ refererer til sonenavnet ("falcot.com" her)
    ; eller til $ORIGIN hvis det uttrykket har vært brukt
    ;
    @       IN      NS      ns
    @       IN      NS      ns0.xname.org.
    
    internal IN      NS      192.168.0.2
    
    @       IN      A       212.94.201.10
    @       IN      MX      5 mail
    @       IN      MX      10 mail2
    
    ns      IN      A       212.94.201.10
    mail    IN      A       212.94.201.10
    mail2   IN      A       212.94.201.11
    www     IN      A       212.94.201.11
    
    dns     IN      CNAME   ns

en: <emphasis>CAUTION</emphasis> Syntax of a name
nb-NO: <emphasis>VÆR VARSOM</emphasis> Navnesyntaks

en: The syntax of machine names follows strict rules. For instance, <literal>machine</literal> implies <literal>machine.<replaceable>domain</replaceable></literal>. If the domain name should not be appended to a name, said name must be written as <literal>machine.</literal> (with a dot as suffix). Indicating a DNS name outside the current domain therefore requires a syntax such as <literal>machine.otherdomain.com.</literal> (with the final dot).
nb-NO: Syntaksen til maskinnavnene følger strikte regler. For eksempel, <literal>maskin</literal> impliserer <literal>maskin.<replaceable>domene</replaceable></literal>. Hvis domenenavnet ikke skal tilføyes et navn, må navnet skrives som <literal>maskin.</literal> (med et punktum som suffiks). Hvis du vil vise et DNS-navn utenfor det gjeldende domenet, er derfor en syntaks som <literal>maskin.annetdomene.com.</literal> nødvendig (med et avsluttende punktum).

en: Excerpt of <filename>/etc/bind/db.192.168</filename>
nb-NO: Utdrag fra <filename>/etc/bind/db.192.168</filename>

en: ; Reverse zone for 192.168.0.0/16
    ; admin.falcot.com. =&gt; zone contact: admin@falcot.com
    $TTL    604800
    @       IN      SOA     ns.internal.falcot.com. admin.falcot.com. (
                            20040121        ; Serial
                             604800         ; Refresh
                              86400         ; Retry
                            2419200         ; Expire
                             604800 )       ; Negative Cache TTL
    
            IN      NS      ns.internal.falcot.com.
    
    ; 192.168.0.1 -&gt; arrakis
    1.0     IN      PTR     arrakis.internal.falcot.com.
    ; 192.168.0.2 -&gt; neptune
    2.0     IN      PTR     neptune.internal.falcot.com.
    
    ; 192.168.3.1 -&gt; pau
    1.3     IN      PTR     pau.internal.falcot.com.
nb-NO: ; Reverssone for 192.168.0.0/16
    ; admin.falcot.com. =&gt; zone contact: admin@falcot.com
    $TTL    604800
    @       IN      SOA     ns.internal.falcot.com. admin.falcot.com. (
                            20040121        ; Seriellnummer
                             604800         ; Fornying
                              86400         ; Nytt forsøk
                            2419200         ; Utløp
                             604800 )       ; Negativ mellomlagrings-TTL
    
            IN      NS      ns.internal.falcot.com.
    
    ; 192.168.0.1 -&gt; arrakis
    1.0     IN      PTR     arrakis.internal.falcot.com.
    ; 192.168.0.2 -&gt; neptune
    2.0     IN      PTR     neptune.internal.falcot.com.
    
    ; 192.168.3.1 -&gt; pau
    1.3     IN      PTR     pau.internal.falcot.com.

en: <primary>network</primary><secondary>DHCP configuration</secondary>
nb-NO: <primary>nettverk</primary><secondary>DHCP-oppsett</secondary>

en: DHCP (for <emphasis>Dynamic Host Configuration Protocol</emphasis>) is a protocol by which a machine can automatically get its network configuration when it boots. This allows centralizing the management of network configurations, and ensuring that all desktop machines get similar settings.
nb-NO: DHCP (for <emphasis>Dynamic Host Configuration Protocol</emphasis>) er en protokoll der en maskin automatisk kan få sitt nettverksoppsett når den starter. Dette gjør det mulig å sentralisere håndteringen av nettverksoppsett, og sikre at alle stasjonære maskiner får lignende innstillinger.

en: A DHCP server provides many network-related parameters. The most common of these is an IP address and the network where the machine belongs, but it can also provide other information, such as DNS servers, WINS servers, NTP servers, and so on.
nb-NO: En DHCP-tjener gir mange nettverksrelaterte parametere. Den vanligste av disse er en IP-adresse og nettverket der maskinen hører til, men den kan også gi andre opplysninger, som for eksempel om DNS-tjenere, WINS-tjenere, NTP-tjenere, og så videre.

en: The Internet Software Consortium (also involved in developing <command>bind</command>) is the main author of the DHCP server. The matching Debian package is <emphasis role="pkg">isc-dhcp-server</emphasis>.
nb-NO: Internet Software Consortium (også involvert i å utvikle <command>bind</command>) er hovedforfatter av DHCP-tjeneren. Den tilsvarende Debian-pakken er <emphasis role="pkg">isc-dhcp-server</emphasis>.

en: Configuring
nb-NO: Oppsett

en: The first elements that need to be edited in the DHCP server configuration files (<filename>/etc/dhcp/dhcpd.conf</filename>, and <filename>/etc/dhcp/dhcpd6.conf</filename> for IPv6) are the domain name and the DNS servers. If this server is alone on the local network (as defined by the broadcast propagation), the <literal>authoritative</literal> directive must also be enabled (or uncommented). One also needs to create a <literal>subnet</literal> section describing the local network and the configuration information to be provided. The following example fits a <literal>192.168.0.0/24</literal> local network with a router at <literal>192.168.0.1</literal> serving as the gateway. Available IP addresses are in the range <literal>192.168.0.128</literal> to <literal>192.168.0.254</literal>.
nb-NO: De første elementene som må redigeres i DHCP-tjenerens oppsettsfiler (<filename>/etc/dhcp/dhcpd.conf</filename>, og <filename>/etc/dhcp/dhcpd6.conf</filename> for IPv6) er domenenavnet og DNS-tjenerne. Hvis denne tjeneren er alene på det lokale nettverket, må (som definert av den kringkastede utsendelsen) <literal>authoritative</literal>-direktivet også aktiveres (eller være ukommentert). Man trenger også å lage en <literal>subnet</literal>-seksjon som beskriver det lokale nettverket og oppsettsopplysningene som skal gis. Følgende eksempel passer et <literal>192.168.0.0/24</literal> lokalt nettverk med en ruter på <literal>192.168.0.1</literal> som tjener som port. Tilgjengelige IP-adresser er i området fra <literal>192.168.0.128</literal> til <literal>192.168.0.254</literal>.

en: Excerpt of <filename>/etc/dhcp/dhcpd.conf</filename>
nb-NO: Utdrag fra <filename>/etc/dhcp/dhcpd.conf</filename>

en: DHCP and DNS
nb-NO: DHCP og DNS

en: <primary>DNS</primary><secondary>automated updates</secondary>
nb-NO: <primary>DNS</primary><secondary>automatiske oppdateringer</secondary>

en: A nice feature is the automated registering of DHCP clients in the DNS zone, so that each machine gets a significant name (rather than something impersonal such as <literal>machine-192-168-0-131.internal.falcot.com</literal>). Using this feature requires configuring the DNS server to accept updates to the <literal>internal.falcot.com</literal> DNS zone from the DHCP server, and configuring the latter to submit updates for each registration.
nb-NO: En fin egenskap er automatisk registrering av DHCP-klienter i DNS-sonen, slik at hver maskin får et eget navn (heller enn noe upersonlig som <literal>maskin-192-168-0-131.internal.falcot.com</literal>). Å bruke denne funksjonen krever oppsett av DNS-tjeneren til å kunne godta oppdateringer til <literal>internal.falcot.com</literal>-DNS-sonen fra DHCP-tjeneren, og sette opp den sistnevnte til å sende oppdateringer for hver registrering.

en: In the <command>bind</command> case (see <xref linkend="sect.dns-software" />), the <literal>allow-update</literal> directive needs to be added to each of the zones that the DHCP server is to edit (the one for the <literal>internal.falcot.com</literal> domain, and the reverse zone). This directive lists the IP addresses allowed to perform these updates; it should therefore contain the possible addresses of the DHCP server (both the local address and the public address, if appropriate).
nb-NO: I tilfellet med <command>bind</command> (se <xref linkend="sect.dns-software" />) må <literal>allow-update</literal>-direktivet legges til hver av de soner som DHCP-tjeneren skal redigere (den ene for <literal>internal.falcot.com</literal>-domenet og den reverserte sonen). Dette direktivet lister IP-adressene som har lov til å utføre disse oppdateringene; det skal derfor inneholde de mulige adressene til DHCP-tjeneren (både lokal adresse og offentlige adresse, hvis det er aktuelt).

en: Beware! A zone that can be modified <emphasis>will</emphasis> be changed by <command>bind</command>, and the latter will overwrite its configuration files at regular intervals. Since this automated procedure produces files that are less human-readable than manually-written ones, the Falcot administrators handle the <literal>internal.falcot.com</literal> domain with a delegated DNS server; this means the <literal>falcot.com</literal> zone file stays firmly under their manual control.
nb-NO: Pass opp! En sone som kan endres, <emphasis>vil</emphasis> bli endret av <command>bind</command>, og sistnevnte vil overskrive oppsettsfilene med jevne mellomrom. Siden denne automatiserte prosedyre produserer filer som er mindre lesbare enn manuelt skrevne, håndterer Falcot administratorer <literal>internal.falcot.com</literal>-domenet med en delegert DNS-tjener; dette betyr at sonefilen <literal>falcot.com</literal> forblir stående under deres manuelle kontroll.

en: The DHCP server configuration excerpt above already includes the directives required for DNS zone updates: they are the <literal>ddns-update-style interim;</literal> and <literal>ddns-domain-name "internal.falcot.com";</literal> lines.
nb-NO: DHCP-tjeneroppsettets utdrag ovenfor inneholder allerede direktivene som kreves for oppdatering av DNS-soner; de er <literal>ddns-update-style interim;</literal>, og <literal>ddns-domain-name "internal.falcot.com";</literal>-linjene.

en: Network Diagnosis Tools
nb-NO: Diagnoseverktøy for nettverk

en: <primary>network</primary><secondary>diagnosis</secondary>
nb-NO: <primary>nettverk</primary><secondary>diagnostikk</secondary>

en: Local Diagnosis: <command>netstat</command>
nb-NO: Lokale diagnoser: <command>netstat</command>

en: Let's first mention the <command>netstat</command> command (in the <emphasis role="pkg">net-tools</emphasis> package); it displays an instant summary of a machine's network activity. When invoked with no argument, this command lists all open connections; this list can be very verbose since it includes many Unix-domain sockets (widely used by daemons) which do not involve the network at all (for example, <literal>dbus</literal> communication, <literal>X11</literal> traffic, and communications between virtual filesystems and the desktop).
nb-NO: La oss først nevne <command>netstat</command>-kommandoen (i <emphasis role="pkg">net-tools</emphasis>-pakken); den viser en umiddelbar oppsummering av maskinens nettverksaktivitet. Når det blir kjørt uten argument, lister denne kommandoen opp alle åpne tilkoblinger; denne listen kan være svært detaljert, siden det inneholder mange Unix-domene-socketer (mye brukt av bakgrunnsprosesser) som ikke involverer nettverket i det hele tatt (for eksempel <literal>dbus</literal>-kommunikasjon, <literal>X11</literal>-trafikk, og kommunikasjon mellom virtuelle filsystemer og skrivebordet).

en: Common invocations therefore use options that alter <command>netstat</command>'s behavior. The most frequently used options include:
nb-NO: Vanlige oppkallinger bruker derfor alternativer som endrer hvordan <command>netstat</command> virker. De vanligst brukte valgene omfatter:

en: <literal>-t</literal>, which filters the results to only include TCP connections;
nb-NO: <literal>-t</literal>, som filtrerer resultatene til å bare inkludere TCP-forbindelser;

en: <literal>-u</literal>, which works similarly for UDP connections; these options are not mutually exclusive, and one of them is enough to stop displaying Unix-domain connections;
nb-NO: <literal>-u</literal>, som fungerer på samme måte for UDP-tilkoblinger; disse alternativene er ikke gjensidig ekskluderende, og en av dem er nok til å stoppe visning av Unix sine domenetilkoblinger;

en: <literal>-a</literal>, to also list listening sockets (waiting for incoming connections);
nb-NO: <literal>-a</literal>, for også å liste sockets (som venter på innkommende forbindelser);

en: <literal>-n</literal>, to display the results numerically: IP addresses (no DNS resolution), port numbers (no aliases as defined in <filename>/etc/services</filename>) and user ids (no login names);
nb-NO: <literal>-n</literal>, for å vise resultatene numerisk: IP-adresser (ingen DNS-løsning), portnumre (ingen aliaser som definert i <filename>/etc/services</filename>) og bruker-ID-er (ingen påloggingsnavn);

en: <literal>-p</literal>, to list the processes involved; this option is only useful when <command>netstat</command> is run as root, since normal users will only see their own processes;
nb-NO: <literal>-p</literal>, for å liste opp de prosessene som er involvert, er dette alternativet bare nyttig når <command>netstat</command> kjøres som rot, siden vanlige brukere bare vil se sine egne prosesser;

en: <literal>-c</literal>, to continuously refresh the list of connections.
nb-NO: <literal>-c</literal>, for å kontinuerlig oppdatere listen med tilkoblinger.

en: Other options, documented in the <citerefentry><refentrytitle>netstat</refentrytitle> <manvolnum>8</manvolnum></citerefentry> manual page, provide an even finer control over the displayed results. In practice, the first five options are so often used together that systems and network administrators practically acquired <command>netstat -tupan</command> as a reflex. Typical results, on a lightly loaded machine, may look like the following:
nb-NO: Andre alternativer, dokumentert på manualsiden <citerefentry><refentrytitle>netstat</refentrytitle> <manvolnum>8</manvolnum></citerefentry>, gir en enda bedre kontroll over resultatene som vises. I praksis blir de første fem alternativene så ofte brukt sammen at systemer og nettverksadministratorer praktisk talt skaffet <command>netstat -tupan</command> som en refleks. Typiske resultater på en lett lastet maskin, kan se ut som følger:

en: As expected, this lists established connections, two SSH connections in this case, and applications waiting for incoming connections (listed as <literal>LISTEN</literal>), notably the Exim4 email server listening on port 25.
nb-NO: Som forventet, dette lister etablerte tilkoblinger, i dette tilfelle to SSH-forbindelser, og programmer som venter på innkommende forbindelser (listet som <literal>LISTEN</literal>), særlig Exim4 e-posttjeneren som lytter på port 25.

en: Remote Diagnosis: <command>nmap</command>
nb-NO: Fjerndiagnostikk: <command>nmap</command>

en: <command>nmap</command> (in the similarly-named package) is, in a way, the remote equivalent for <command>netstat</command>. It can scan a set of “well-known” ports for one or several remote servers, and list the ports where an application is found to answer to incoming connections. Furthermore, <command>nmap</command> is able to identify some of these applications, sometimes even their version number. The counterpart of this tool is that, since it runs remotely, it cannot provide information on processes or users; however, it can operate on several targets at once.
nb-NO: <command>nmap</command> (i pakken med tilsvarende navn) er, på en måte, ekstern-motstykket som tilsvarer til <command>netstat</command>. Den kan skanne et sett med «kjente» porter for en eller flere eksterne tjenere, og liste portene der det er funnet et program som svarer på innkommende tilkoblinger. Videre kan <command>nmap</command> identifisere noen av disse programmene, noen ganger til og med versjonsnummeret. Motstykket til dette verktøyet er at, siden det kjører eksternt, kan det ikke gi informasjon om prosesser eller brukere. Det kan imidlertid operere med flere mål samtidig.

en: A typical <command>nmap</command> invocation only uses the <literal>-A</literal> option (so that <command>nmap</command> attempts to identify the versions of the server software it finds) followed by one or more IP addresses or DNS names of machines to scan. Again, many more options exist to finely control the behavior of <command>nmap</command>; please refer to the documentation in the <citerefentry> <refentrytitle>nmap</refentrytitle> <manvolnum>1</manvolnum> </citerefentry> manual page.
nb-NO: En typisk <command>nmap</command>-påkalling bruker bare <literal>-A</literal>-valget (slik at <command>nmap</command> forsøker å identifisere versjoner av tjenerprogramvaren den finner) etterfulgt av én eller flere IP-adresser eller DNS-navn på maskiner som skal skannes. Igjen, det finnes mange muligheter til finkontroll av hvordan <command>nmap</command> kjøres. Referer gjerne til dokumentasjonen i <citerefentry> <refentrytitle>nmap</refentrytitle> <manvolnum>1</manvolnum> </citerefentry> manualside.

en: Sniffers: <command>tcpdump</command> and <command>wireshark</command>
nb-NO: Sniffers: <command>tcpdump</command> og <command>wireshark</command>

en: Sometimes, one needs to look at what actually goes on the wire, packet by packet. These cases call for a “frame analyzer”, more widely known as a <emphasis>sniffer</emphasis>. Such a tool observes all the packets that reach a given network interface, and displays them in a user-friendly way.
nb-NO: Noen ganger må man se på hva som faktisk er i ledningen, pakke for pakke. Disse tilfellene ber om en «rammeanalysator», mer kjent som <emphasis>sniffer</emphasis>. Et slikt verktøy observerer alle pakkene som når et gitt nettverksgrensesnitt, og viser dem på en brukervennlig måte.

en: The venerable tool in this domain is <command>tcpdump</command>, available as a standard tool on a wide range of platforms. It allows many kinds of network traffic capture, but the representation of this traffic stays rather obscure. We will therefore not describe it in further detail.
nb-NO: Det respekterte verktøyet i dette domenet er <command>tcpdump</command>, og tilgjengelig som et standard verktøy på et bredt spekter av plattformer. Det gjør at mange typer nettverkstrafikk kan fanges opp, men gjengivelsen av denne trafikken er temmelig dunkel (obskur). Vi vil derfor ikke beskrive det nærmere.

en: A more recent (and more modern) tool, <command>wireshark</command> (in the <emphasis role="pkg">wireshark</emphasis> package), has become the new reference in network traffic analysis due to its many decoding modules that allow for a simplified analysis of the captured packets. The packets are displayed graphically with an organization based on the protocol layers. This allows a user to visualize all protocols involved in a packet. For example, given a packet containing an HTTP request, <command>wireshark</command> displays, separately, the information concerning the physical layer, the Ethernet layer, the IP packet information, the TCP connection parameters, and finally the HTTP request itself.
nb-NO: Et nyere (og mer moderne) verktøy, <command>wireshark</command> (i <emphasis role="pkg">wireshark</emphasis>-pakken), har blitt den nye referansen i analyse av nettverkstrafikk på grunn av sine mange dekodingsmoduler med mulighet for en forenklet analyse av de pakkene som er fanget opp. Pakkene vises grafisk organisert etter protokollagene. Dette gjør det mulig for en bruker å visualisere alle protokoller som er involvert i en pakke. For eksempel, gitt en pakke som inneholder en HTTP-forespørsel, <command>wireshark</command> viser, hver for seg, den informasjonen om det fysiske laget, Ethernet laget, IP-pakkeinformasjon, TCP-tilkoblingsparametere, og til slutt HTTP-forespørselen selv.

en: The <command>wireshark</command> network traffic analyzer
nb-NO: <command>wireshark</command> til analyse av nettverkstrafikk

en: In our example, the packets traveling over SSH are filtered out (with the <literal>!tcp.port == 22</literal> filter). The packet currently displayed was developed at the transport layer of the SSHv2 protocol.
nb-NO: I vårt eksempel filtreres pakkene som reiser over SSH ut (med <literal>!tcp.port == 22</literal>-filteret). Pakken som vises for øyeblikket ble utviklet på overføringslaget til SSHv2-protokollen.

en: <emphasis>TIP</emphasis> <command>wireshark</command> with no graphical interface: <command>tshark</command>
nb-NO: <emphasis>TIPS</emphasis> <command>wireshark </command>uten grafisk grensesnitt: <command>tshark</command>

en: When one cannot run a graphical interface, or does not wish to do so for whatever reason, a text-only version of <command>wireshark</command> also exists under the name <command>tshark</command> (in a separate <emphasis role="pkg">tshark</emphasis> package). Most of the capture and decoding features are still available, but the lack of a graphical interface necessarily limits the interactions with the program (filtering packets after they've been captured, tracking of a given TCP connection, and so on). It can still be used as a first approach. If further manipulations are intended and require the graphical interface, the packets can be saved to a file and this file can be loaded into a graphical <command>wireshark</command> running on another machine.
nb-NO: Når man ikke kan kjøre et grafisk grensesnitt, eller ikke ønsker å gjøre det uansett grunn, er det også en tekstversjon av <command>wireshark</command> med navnet <command>tshark</command> (i en separat <emphasis role="pkg">tshark</emphasis>-pakke). De fleste av fangst- og dekodingsfunksjonene er fortsatt tilgjengelige, men mangelen på et grafisk grensesnitt begrenser nødvendigvis samhandlingen med programmet (filtreringspakker etter at de har blitt fanget, sporing av en gitt TCP-tilkobling, og så videre). Det kan likevel brukes som en første tilnærming. Hvis ytterligere håndtering er hensikten, og det krever det grafiske grensesnittet, kan pakkene lagres til en fil, og den filen kan lastes inn i en grafisk <command>wireshark</command> som kjører på en annen maskin.
