James Bottomleys random Pages

en af de seneste oplevelser fra Linuks Blikkenslagerkonference overbeviste mig om, at hvis du vil være en del af en ægte open source-baseret peer to peer audio/video-interaktion, har du brug for en internetadresse, der ikke ligger bag en NAT. I virkeligheden, protokollen fungerer stadig, så længe du kan kontakte en bedøvelsesserver for at fortælle dig, hvad din eksterne adresse er, og muligvis en drejeserver til at erstatte pakkerne, hvis begge slutpunkter er NATed, men alt dette søger eksterne servere tager tid som de af jer, der klagede over echo-testen fundet. Løsningen på alt dette er at oprette forbindelse via IPv6, som har et adresserum, der er stort nok til at understøtte enhver enhed på planeten, der har sin egen adresse. Alle moderne distributioner understøtter IPv6 ud af boksen, så chancerne er, at du faktisk ved et uheld har brugt det uden nogensinde at bemærke det, hvilket er en af skønhederne ved IPv6 autokonfiguration (det skal bare fungere).

men jeg flyttede for nylig, og så mistede min fiber internetforbindelse til kabel, men kabel, der kom med en IPv6-adresse, så dette er min historie om at få det hele til at fungere. Hvis du ikke rigtig er interesseret i protokollens grundlæggende, kan du springe ned til hvordan. Denne vejledning er også fokuseret på en” dual stack ” – konfiguration (en, der har både IPv6-og IPv4-adresser). Rene IPv6-konfigurationer er mulige, men fordi nogle dele af internettet stadig kun er IPv4, er de ikke komplette, medmindre du opretter en IPv4-indkapslingsbro.

det grundlæggende i IPv6

IPv6 har været en moden protokol i lang tid nu, så jeg antog fejlagtigt, at der ville være en masse gode vejledninger om det. Men efter at have læst 20 forskellige beskrivelser af, hvordan IPv6 128 bit adresserum fungerer og ikke meget andet, gav jeg op i fortvivlelse og læste RFC ‘ erne i stedet. Jeg antager, at du har læst mindst en af disse vejledninger, så jeg behøver ikke at gå ind i IPv6-adressepræfikser, suffikser, interface-id ‘ er eller undernet, så jeg begynder, hvor de fleste af vejledningen slutter.

Hvordan fungerer IPv6 bare?

i IPv4 er der en protokol kaldet dynamic host configuration protocol (DHCP), så længe du kan finde en DHCP-server, kan du få alle de oplysninger, du har brug for for at oprette forbindelse (lokal adresse, router, DNS-server, tidsserver osv.). Denne service skal dog konfigureres af nogen, og IPv6 er designet til at konfigurere et netværk uden det.

den første antagelse IPv6 statsløs adresse Autokonfiguration (SLAAC) gør, at det er på en /64 subnet (så hver subnet i IPv6 indeholder 1010 gange så mange adresser som hele IPv4 internet). Det betyder, at da de fleste reelle undernet indeholder <100 systemer, kan de simpelthen vælge en tilfældig adresse og være meget usandsynligt at kollidere med de eksisterende systemer. Faktisk er der tre nuværende måder at vælge en adresse på i /64:

1. EUI – 64 (RFC 4291) baseret på MAC-adressen, som stort set er MAC med en bit vendt og ff:fe placeret i midten.
2. stabil privat (RFC 7217), der genererer fra en hash baseret på en statisk nøgle, interface, præfiks og en tæller (tælleren øges, hvis der er et sammenstød). Disse foretrækkes frem for EUI – 64-adresserne, der giver væk enhver konfiguration, der er knyttet til MAC-adressen (såsom hvilken type netværkskort du har)
3. Privatlivsudvidelsesadresser (RFC 4941), som meget ligner stabile private adresser, bortset fra at de ændrer sig over tid ved hjælp af IPv6-adressefaldsmekanismen og er til klientsystemer, der ønsker at bevare anonymitet.

det næste problem er, hvem konfigurerer grænsefladen? Kernen IPv6 stakken er faktisk designet til at gøre det, og vil medmindre fortalt ikke at, men de fleste af de moderne netværk controllere (som Netværksmanager) er kontrol freaks og slukke for kernens auto konfiguration, så de kan gøre det selv. De er også standard til stabil privat adressering ved hjælp af en statisk hemmelighed, der opretholdes i filsystemet (/var/lib/Netværksmanager/secret_key).

den næste ting at forstå om IPv6-adresser er, at de er opdelt i scopes, hvor det vigtigste er link local (unrouteable) adresser, som traditionelt altid har præfikset fe80::/64. Den lokale linkadresse konfigureres først ved hjælp af en af ovenstående metoder og bruges derefter til at undersøge netværket.

Multicast og Neighbor Discovery

i modsætning til IPv4 har IPv6 ingen udsendelsesfunktion, så al opdagelse udføres af multicast. Noder, der kommer op på netværket, abonnerer på bestemte multicast-adresser via specielle pakker, der opfanges af kontakten, og modtager ikke nogen multicast, som de ikke abonnerer på. Konventionelt har alle link lokale multicast-adresser præfikset ff02::/64 (for andre typer multicast-adresse se RFC 4291). Alle noder abonnerer på multicast-adressen “alle noder” ff02::1 og skal også abonnere på deres egen anmodede node multicast-adresse på ff02::1:ffh:hvor de sidste 24 bit svarer til De laveste 24 bit af knudepunktets IPv6-adresse. Sidstnævnte er at undgå den forstyrrelse, der plejede at forekomme i IPv4 fra ARP-udsendelser, fordi du nu kan målrette mod en bestemt delmængde af noder til adresseopløsning.

IPv6-adresseopløsningsprotokollen kaldes Neighbour Solicitation (NS), beskrevet i RFC 4861, og den bruges med SLAAC beskrevet i RFC 4862, og gøres ved at sende en multicast til nabo-anmodningsadressen på den node, du vil opdage, der indeholder den fulde IPv6-adresse, du vil vide, en node med den matchende adressesvar med dens link layer (MAC) – adresse i en Naboannonce (NA) – pakke.

når en node har valgt sin lokale linkadresse, sender den først en NS-pakke til den valgte adresse for at se, om nogen svarer, og hvis ingen gør det, antager det, at det er OK at beholde det, ellers følger den kollisionsundgåelsesprotokollen, der er knyttet til dens særlige adresseform. Når den har fundet en unik adresse, konfigurerer noden denne link lokale adresse og leder efter en router. Bemærk, at hvis et IPv6-netværk ikke er til stede, stopper discovery her, hvorfor de fleste netværksgrænseflader altid viser en link lokal IPv6-adresse.

Router Discovery

når noden har sin egen unikke link lokale adresse, Det bruger det til at sende Router opfordring (RS) pakker til “alle routere” multicast adresse ff02::2. Hver router på netværket reagerer med en Router Advertisement (RA) pakke, der beskriver (blandt andet) routerens levetid, netværket MTU, et sæt af et eller flere præfikser routeren er ansvarlig for, routerens linkadresse og et sæt valgflag inklusive m (administreret) og O (anden konfiguration) flag og muligvis et sæt DNS-servere.

hvert annonceret præfiks indeholder præfiks og præfikslængde, et sæt flag inklusive A (autonom konfiguration) og L (link local) og et sæt levetider. Linket lokale præfikser fortæller dig, hvilke globale præfikser de lokale netværksbrugere (der kan være mere end en), og om du har lov til at gøre SLAAC på det globale præfiks (hvis A-flaget er klart, skal du bede routeren om en adresse ved hjælp af DHCPv6). Hvis routeren har en levetid, der ikke er nul, kan du antage, at det er en standardrouter til undernet.

nu hvor noden har opdaget en eller flere routere, kan den konfigurere sin egen globale adresse (bemærk, at hver IPv6 routeable node har mindst to adresser: et link lokalt og et globalt). Hvordan det gør dette afhænger af routeren og præfiks flag

Global Adressekonfiguration

det første, en node skal vide, er, om man skal bruge SLAAC til den globale adresse eller DHCPv6. Dette bestemmes helt af a-flag for ethvert link lokalt præfiks i RA-pakken. Hvis A er indstillet, kan noden bruge SLAAC, og hvis A er klar, skal noden bruge DHCPv6 for at få en adresse. Hvis A er indstillet og også m (administreret) flag, kan noden bruge enten SLAAC eller DHCPv6 (eller begge dele) for at få en adresse, og hvis M-flaget er klart, men O (anden Config) flag er til stede, skal noden bruge SLAAC, men kan bruge DHCPv6 til at få andre oplysninger om netværket (normalt DNS).

når noden har en global adresse, har den nu brug for en standardrute. Det danner standardrute listen fra RA pakker, der har en ikke-nul router levetid. Alle disse er konfigureret som standardruter til deres link lokale adresse med RA specificeret hop tæller. Endelig kan noden tilføje specifikke præfiksruter fra RA-pakker med nul router levetid, men ikke-link lokale præfikser.

DHCPv6 er en ret kompleks konfigurationsprotokol (se RFC 8415), men den kan ikke angive hverken præfikslængde (hvilket betyder, at alle opnåede adresser er konfigureret som /128) eller ruter (disse skal hentes fra RA-pakker). Dette fører til en subtilitet med valg af udgående adresse, idet den mest specifikke altid foretrækkes, så hvis du konfigurerer både af SLAAC og DHCPv6, tilføjes SLAAC-adressen as /64, og DHCPv6-adressen as /128, hvilket betyder, at din udgående IP-adresse altid vil være DHCPv6 one (selvom hvis en ekstern enhed kender din SLAAC-adresse, vil de stadig være i stand til at nå dig på den).

Hvordan: Konfiguration af din egen hjemmerouter

en af de ting, du skulle tro fra ovenstående, er, at IPv6 altid automatisk konfigurerer, og selvom det er rigtigt, at hvis du blot tilslutter din bærbare computer til ethernet-porten på et kabelmodem, konfigureres det bare automatisk, de fleste mennesker har en mere kompleks hjemmeopsætning, der involverer en router, som har brug for noget specielt lokke, før det fungerer. Det betyder, at du skal hente yderligere funktioner fra din internetudbyder ved hjælp af specielle DHCPv6-anmodninger.

dette afsnit er skrevet fra mit eget synspunkt: Jeg har et ret komplekst IPv4-netværk, der har et helt åbent, men båndbreddebegrænset (til ikke-betroede klienter) trådløst netværk og flere beskyttede interne netværk (et til mit laboratorium, et til mine telefoner og et til husstandens videokameraer), så jeg har brug for mindst 4 undernet for at give hver enhed i mit hjem en IPv6-adresse. Jeg bruger også Openskriv som min routerdistribution, så alle IPv6-konfigurationsoplysninger er meget specifikke for det (selvom det skal bemærkes, at ting som Netværksmanager også kan gøre alt dette, hvis du er parat til at grave i dokumentationen).

Præfiksdelegation

da DHCPv6 kun uddeler en /128-adresse, er dette ikke tilstrækkeligt, fordi det er selve routerens IP-adresse. For at blive en router skal du anmode om delegering af en del af IPv6-adresserummet via Identity Association for prefiks Delection (Ia_pd) mulighed for DHCPv6. Når dette er gjort, antages routerens IP-adresse af internetudbyderen at være ruten for alle de delegerede præfikser. Subtiliteten her er, at hvis du vil have mere end et undernet, skal du bede om det specifikt (klienten skal angive den nøjagtige præfikslængde, den leder efter), og da det er en præfikslængde, og dit standardundernet skal være /64, hvis du anmoder om en præfikslængde på 64, har du kun et undernet. Hvis du anmoder om 63 du har 2 og så videre. Problemet er, hvordan ved du, hvor mange undernet internetudbyderen er villig til at give dig? Desværre er der ingen måde at finde dette på (jeg var nødt til at foretage en internetsøgning for at opdage, at min internetudbyder, Comcast, var villig til at delegere en præfikslængde på 60, hvilket betyder 16 undernet). Hvis søgning ikke fortæller dig, hvor meget din internetudbyder er villig til at delegere, kan du prøve at starte ved 48 og arbejde dig hen til 64 i trin på 1 for at se, hvilken største delegation du kan slippe af sted med (der har været rapporter om internetudbydere, der låser dig ved din første delegerede præfikslængde, så start ikke ved 64). Den endelige subtilitet er, at det præfiks, du er delegeret, muligvis ikke er det samme præfiks som den adresse, din router opnåede (Min nuværende comcast-konfiguration har min router på 2001:558:600a:… men mit delegerede præfiks er 2601:600:8280:66d0:/60). Bemærk Du kan køre odhcp6c manuelt med indstillingen-P, hvis du skal undersøge din internetudbyder for at finde ud af, hvilken størrelse præfiks du kan få.

konfiguration af routeren til Præfiksdelegering

i åbne termer styres routerens konfiguration af DHCP(v6) af /etc/default/netværk. Du har allerede en grænseflade til DHCPv4, så du skal blot tilføje en ekstra grænseflade til IPv6 for at få en ekstra IPv6 og blive dual stack. I min konfiguration ser det ud som

config interface 'wan6' option ifname '@wan' option proto 'dhcpv6' option reqprefix 60

den lille mærkelighed er ifname: det er en af de mest populære måder at gøre dette på. At navngive det på denne måde er vigtigt, hvis din vilje er en bro, men det er alligevel god praksis. Den anden mulighed fortæller DHCPv6 at anmode om en / 60 præfiks delegation.

uddeling af delegerede præfikser

dette viser sig at være bemærkelsesværdigt simpelt. For det første skal du tildele et delegeret præfiks til hver af dine andre grænseflader på routeren, men du kan gøre dette uden at tilføje en ny åben grænseflade til hver af dem. Mit interne IPv4-netværk har alle statiske adresser, så du tilføjer tre direktiver til hver af grænsefladerne:

config interface 'lan' ... interface designation (bridge for me) option proto 'static' ... ipv4 addresses option ip6assign '64' option ip6hint '1' option ip6ifaceid '::ff'

ip6assign ‘ N ‘betyder, at du er A /n-netværk (så dette er altid /64 for mig) og ip6hint’ N ‘betyder brug N som dit subnet-id og ip6ifaceid’ S ‘ betyder brug S som IPv6-suffikset (dette er som standard ::1 så hvis du er OK med det, skal du udelade dette direktiv). Så givet Jeg har en 2601:600:8280: 66d0::/60 præfiks, vil den globale adresse på denne grænseflade være 2601:600:8280: 66d1:: ff. Nu er syretesten, hvis du har det rigtigt, denne globale adresse skal være pingbar fra hvor som helst på IPv6-internettet (hvis det ikke er det, er det sandsynligvis et brandvægsproblem, se nedenfor).

annoncering som Router

det er ikke tilstrækkeligt at få delegeret et delegeret præfiks på en lokal routergrænseflade . Nu skal du få din router til at svare på Routeranmodninger på ff02::2 og eventuelt gøre DHCPv6. Desværre har Openc to mekanismer til at gøre dette, som regel begge installeret: odhcpd og dnsmasks. Hvad jeg fandt var, at ingen af mine direktiver i/etc/config / dhcp ville træde i kraft, indtil jeg deaktiverede odhcpd helt

/etc/init.d/odhcpd stop/etc/init.d/odhcpd disable

og da jeg bruger dnsmaska i vid udstrækning andetsteds (split DNS til interne/eksterne netværk), passer det mig fint. Jeg beskriver for det første, hvilke muligheder du har brug for i dnsmaska og for det andet, hvordan du kan opnå dette ved hjælp af poster i filen openskriv /etc/config/dhcp (jeg finder det nyttigt, fordi det altid er klogt at kontrollere, hvad Openskriv har lagt i /var/etc/dnsmaska.conf-fil).

den første dnsmaskeringsmulighed, du har brug for, er ‘enable-ra’, som er en global parameter, der instruerer dnsmaskm til at håndtere routerannoncer. Den næste parameter, du har brug for, er per-interface ‘ra-param’, der specificerer de globale routerannonceparametre og skal vises en gang for hver grænseflade, du vil annoncere på. Endelig giver ‘dhcp-range’ mulighed for mere detaljeret konfiguration af typen af RA-flag og valgfri DHCPv6.

SLAAC eller DHCPv6 (eller begge)

på mange måder er dette et spørgsmål om personligt valg. Hvis du tillader SLAAC, kan værter, der ønsker at bruge adresser til udvidelse af privatlivets fred (som Android-telefoner) gøre det, hvilket er en god ting. Hvis du også tillader DHCPv6-adressevalg, vil du have en liste over adresser tildelt værter, og dnsmaska vil gøre DNS-opløsning for dem (selvom det kan gøre DNS for SLAAC-adresser, forudsat at det bliver fortalt om dem). Der findes et specielt tag ‘constructor’ til indstillingen ‘dhcp-range’, der fortæller det at konstruere den leverede adresse (for enten RA eller DHCPv6) fra IPv6 global præfiks for den specificerede grænseflade, hvilket er, hvordan du videregiver vores delegerede præfiksadresser. Tilstandene for ‘ dhcp-range ‘er’ ra-only ‘for at udelukke DHCPv6 helt,’ slaac ‘for at tillade DHCPv6-adressevalg og’ ra-statsløs ‘ for at afvise DHCPv6-adressevalg, men tillade andre DHCPv6-konfigurationsoplysninger.

baseret på trial and error (og endelig undersøge scripting i /etc/init.d / dnsmasks) de openskrivningsmuligheder, der kræves for at opnå ovenstående dnsmasks muligheder, er

config dhcp lan option interface lan option start 100 option limit 150 option leasetime 1h option dhcpv6 'server' option ra_management '1' option ra 'server'

med ‘ra_management’ som nøgleindstilling med ‘0’, der betyder SLAAC med DHCPv6-indstillinger, ‘1’, der betyder SLAAC med fuld DHCPv6, ‘2’, der kun betyder DHCPv6 og ‘3’, der kun betyder SLAAC. En anden underlighed er, at der ikke synes at være en måde at indstille lejeområdet på: det er altid standard til enten statisk eller ::1000 til ::ffff.

Brandvægskonfiguration

en af de ting, der rejser folk op, er det faktum, at Linuk har to helt separate brandvægge: en til IPv4 og en til IPv6. Hvis du nogensinde har skrevet nogen brugerdefinerede regler for dem, er chancerne for, at du gjorde det i Openskriv /etc/brandvæg.brugerfil, og du brugte kommandoen iptables, hvilket betyder, at du kun tilføjede reglerne til IPv4-brandvæggen. For at tilføje den samme regel for IPv6 skal du duplikere den ved hjælp af kommandoen ip6tables. Et andet væsentligt problem, hvis du bruger en forbindelsessporing til port knock detection som jeg er, er, at sporing af forbindelse har problemer med IPv6 multicast, så pakker, der går ud til en multicast, men kommer tilbage som unicast (som de fleste af opdagelsesprotokollerne gør) får den forkerte conntrack-tilstand. For at løse dette måtte jeg til sidst have en INPUTREGEL, der bare accepterede alle ICMPv6 og DHCPv6 (UDP-porte 546 og 547 ). Der er ingen grund til at NAT (Openskriv kan overtales til at tage sig af dette automatisk, men hvis du duplikerer IPv4-reglerne manuelt, skal du ikke duplikere NAT-reglerne). Den endelige er sandsynligvis mere anvendelig for mig: min trådløse grænseflade er designet til at være en udvidelse af det lokale internet, og alle maskiner, der opretter forbindelse til det, forventes at være i stand til at beskytte sig selv, da de vil migrere til sådanne fjendtlige miljøer som trådløst internet i lufthavnen, så jeg udfører fuldstændig eksponering af trådløse tilsluttede enheder til det generelle internet for alle porte, inklusive portprober. For mine interne enheder har jeg en relateret,etableret regel for at sikre, at de ikke undersøges, da de ikke er designet til at migrere fra det interne netværk.

nu problemerne med Openskriv: da du vil have NAT på IPv4, men ikke på IPv6, skal du have to separate van-områder til dem: hvis du forsøger at kombinere dem (som jeg først gjorde), vil Openvrt tilføje en IPv6 –ctstate ugyldig regel, som forhindrer Naboopdagelse i at fungere på grund af conntrack-problemerne med IPv6 multicast, så mine van-områder er (godt, det er en løgn, fordi min brandmur nu er håndlavet, men det er det, jeg kontrollerede arbejdet, før jeg satte den håndlavede brandmur på plads):

config zone option name 'wan' option network 'wan' option masq '1' ...config zone option name 'wan6' option network 'wan6' ...

og routingreglerne for lan-området (fuldt tilgængeligt) er

config forwarding option src 'lan' option dest 'wan'config forwarding option src 'lan' option dest 'wan6'config forwarding option src 'wan6' option dest 'lan'

at sætte det sammen: At få klienterne IPv6 tilsluttet

nu hvor du har konfigureret din router, skal alt bare fungere. Hvis det gjorde det, skal din bærbare trådløse grænseflade nu have en global IPv6-adresse

ip -6 address show dev wlan0

hvis det kommer tomt tilbage, skal du aktivere IPv6 på din distribution. Hvis den kun har en link lokal (fe80:: præfiks) adresse, er IPv6 aktiveret, men din router annoncerer ikke (mistanke om problemer med discovery-pakker eller forkert konfiguration af dnsmasks). Hvis du ser en global adresse, er du færdig. Nu skal du være i stand til at gå til https://testv6.com og sikre en 10/10 score.

det sidste stykke af puslespillet foretrækker din nye IPv6-forbindelse, når DNS tilbyder et valg af IPv4-eller IPv6-adresser. Alle moderne klienter bør foretrække IPv6, når de er tilgængelige, hvis de er tilsluttet et dual stack-netværk, så prøv … hvis du pinger, siger, www.google.com og se en IPv6-adresse, du er færdig. Hvis ikke, skal du komme ind i den skumle verden af IPv6-adressemærkning (RFC 6724) og gai.conf.

konklusion

tilføjelse af IPv6 til og eksisterende IPv4-opsætning er i øjeblikket ikke en simpel plug in and go-operation. Men forudsat at du forstår en håndfuld forskelle mellem de to protokoller, er det heller ikke et uoverstigeligt problem. Jeg har også glanset over mange af de problemer, du måtte støde på med din internetudbyder. Nogle mennesker har rapporteret, at deres internetudbydere kun uddeler en IPv6-adresse uden præfiksdelegation, i hvilket tilfælde Jeg tror at finde en ny internetudbyder ville være klogest. Andre rapporterer, at internetudbyderen kun vil delegere et /64-præfiks, så dit valg her er enten at kun køre et undernet (sandsynligvis tilstrækkeligt til mange hjemmenetværk) eller undernet på større end /64 og forbyde SLAAC, hvilket bestemt ikke er en anbefalet konfiguration. Imidlertid, forudsat at din internetudbyder er rimelig, dette blogindlæg skal i det mindste hjælpe dig i gang.