James Bottomley’ s random Pages

en av de senaste erfarenheterna av Linux Plumbers Conference övertygade mig om att om du vill vara en del av en sann Open source WebRTC-baserad peer to peer audio/video-interaktion behöver du en internetadress som inte ligger bakom en NAT. I verkligheten fungerar protokollet fortfarande så länge du kan kontakta en stun-server för att berätta vad din externa adress är och eventuellt en svängserver för att proxy paketen om båda slutpunkterna är NATed men allt detta söker externa servrar tar tid som de av er som klagade över echo-testet hittades. Lösningen på allt detta är att ansluta via IPv6 som har ett adressutrymme som är tillräckligt stort för att stödja varje enhet på planeten som har sin egen adress. Alla moderna Linux-distributioner stöder IPv6 ur lådan så chansen är att du faktiskt av misstag har använt den utan att någonsin märka, vilket är en av skönheterna i IPv6 autokonfiguration (det ska bara fungera).

men jag flyttade nyligen, och så förlorade min fiberinternetanslutning till kabel men kabel som kom med en IPv6-adress, så det här är min historia om att få allt att fungera. Om du inte riktigt bryr dig om protokollets grunder kan du hoppa ner till hur. Den här guiden är också inriktad på en” dual stack ” – konfiguration (en som har både IPv6-och IPv4-adresser). Rena IPv6-konfigurationer är möjliga, men eftersom vissa delar av internet fortfarande bara är IPv4, är de inte kompletta om du inte ställer in en IPv4-inkapslingsbro.

grunderna i IPv6

IPv6 har varit ett moget protokoll länge nu, så jag antog felaktigt att det skulle finnas en massa bra HOWTOs om det. Men efter att ha läst 20 olika beskrivningar av hur IPv6 128 bitars adressutrymme fungerar och inte mycket annat gav jag upp i förtvivlan och läste RFC: erna istället. Jag antar att du har läst minst en av dessa HOWTOS, så jag behöver inte gå in i IPv6-adressprefix, suffix, gränssnitts-ID eller subnät så jag börjar där de flesta HOWTOs slutar.

Hur fungerar IPv6 bara?

i IPv4 finns ett protokoll som heter dynamic host configuration protocol (DHCP) så länge du kan hitta en DHCP-server kan du få all information du behöver för att ansluta (lokal adress, router, DNS-server, tidsserver, etc). Denna tjänst måste dock ställas in av någon och IPv6 är utformad för att konfigurera ett nätverk utan det.

det första antagandet IPv6 statslös adress Autokonfiguration (SLAAC) gör är att det är på en /64 subnät (så varje subnät i IPv6 innehåller 1010 gånger så många adresser som hela IPv4 internet). Detta innebär att, eftersom de flesta verkliga subnät innehåller <100 system, kan de helt enkelt välja en slumpmässig adress och vara mycket osannolikt att kollidera med de befintliga systemen. Faktum är att det finns tre nuvarande sätt att välja en adress i /64:

1. EUI-64 (RFC 4291) baserat på MAC-adressen som i grunden är MAC med en bit vänd och ff:fe placerad i mitten.
2. stabil privat (RFC 7217) som genererar från en hash baserad på en statisk nyckel, gränssnitt, prefix och en räknare (räknaren ökas om det finns en konflikt). Dessa föredras framför EUI-64 som ger bort alla konfigurationer som är associerade med MAC-adressen (till exempel vilken typ av nätverkskort du har)
3. Sekretessförlängningsadresser (RFC 4941) som liknar stabila privata adresser förutom att de ändras över tid med hjälp av IPv6-adressavskrivningsmekanismen och är för klientsystem som vill bevara anonymitet.

nästa problem i Linux är vem konfigurerar gränssnittet? Kärnans IPv6-stack är faktiskt utformad för att göra det, och kommer om inte sagt att inte, men de flesta av de moderna nätverkskontrollerna (som NetworkManager) är kontrollfreaks och stänger av kärnans automatiska konfiguration så att de kan göra det själva. De är också standard för stabil privat adressering med hjälp av en statisk hemlighet som upprätthålls i filsystemet (/var/lib/NetworkManager/secret_key).

nästa sak att förstå om IPv6-adresser är att de är indelade i omfattningar, den viktigaste är link local (unrouteable) adresser som konventionellt alltid har prefixet fe80::/64. Länkens lokala adress konfigureras först med en av ovanstående metoder och används sedan för att sondra nätverket.

Multicast och Neighbor Discovery

till skillnad från IPv4 har IPv6 ingen sändningsförmåga så All upptäckt görs av multicast. Noder som kommer upp i nätverket prenumererar på särskilda multicast-adresser, via speciella paket som avlyssnas av omkopplaren, och kommer inte att få någon multicast som de inte prenumererar på. Konventionellt har alla länklokala multicast-adresser prefixet ff02:: / 64 (för andra typer av multicast-adress se RFC 4291). Alla noder prenumererar på multicast-adressen” alla noder ” ff02::1 och måste också prenumerera på sin egen begärda nod multicast-adress på ff02:: 1: ffXX: XXXX där de sista 24 bitarna motsvarar de lägsta 24 bitarna i nodens IPv6-adress. Det senare är att undvika störningar som brukade inträffa i IPv4 från ARP-sändningar eftersom du nu kan rikta in en specifik delmängd av noder för adressupplösning.

IPV6-adressupplösningsprotokollet kallas Neighbour Solicitation (NS), beskrivet i RFC 4861 och det används med SLAAC som beskrivs i RFC 4862 och görs genom att skicka en multicast till neighbor solicitation-adressen till noden du vill upptäcka som innehåller den fullständiga IPv6-adressen du vill veta, en nod med matchande adress svarar med sin länklager (MAC) – adress i ett Neighbor Advertisement (NA) – paket.

när en nod har valt sin lokala länkadress skickar den först ett NS-paket till sin valda adress för att se om någon svarar och om ingen antar att det är OK att behålla det annars följer det kollisionsundvikande protokollet som är associerat med dess speciella adressform. När den har hittat en unik adress konfigurerar noden den här länkens lokala adress och letar efter en router. Observera att om ett IPv6-nätverk inte finns, stannar upptäckten här, varför de flesta nätverksgränssnitt alltid visar en länk lokal IPv6-adress.

Router Discovery

när noden har sin egen unika länk lokal adress, använder den för att skicka ut Router Solicitation (RS) paket till ”alla routrar” multicast adress ff02::2. Varje router i nätverket svarar med ett Routerannonspaket (RA) som beskriver (bland annat) routerns livslängd, nätverket MTU, en uppsättning av ett eller flera prefix som routern ansvarar för, routerns länkadress och en uppsättning alternativflaggor inklusive flaggan m (Managed) och O (Other Configuration) och eventuellt en uppsättning DNS-servrar.

varje annonserat prefix innehåller prefixet och prefixlängden, en uppsättning flaggor inklusive A (autonom konfiguration) och L (länk lokal) och en uppsättning livstider. Länken lokala prefix berättar vilka globala prefix De lokala nätverksanvändarna (det kan finnas fler än en) och om du får göra SLAAC på det globala prefixet (om A-flaggan är klar måste du be routern om en adress med DHCPv6). Om routern har en livslängd som inte är noll kan du anta att det är en standardrouter för delnätet.

nu när noden har upptäckt en eller flera routrar kan den konfigurera sin egen globala adress (Observera att varje IPv6-routeable-nod har minst två adresser: en länk lokal och en global). Hur det gör detta beror på routern och prefixflaggorna

Global Adresskonfiguration

det första en nod behöver veta är om man ska använda SLAAC för den globala adressen eller DHCPv6. Detta bestäms helt av A-flaggan för ett lokalt länkprefix i RA-paketet. Om A är inställt kan noden använda SLAAC och om A är klart måste noden använda DHCPv6 för att få en adress. Om A är inställd och även m (Managed) flaggan kan noden använda antingen SLAAC eller DHCPv6 (eller båda) för att få en adress och om m-flaggan är klar, men o (Other Config) flaggan är närvarande måste noden använda SLAAC men kan använda DHCPv6 för att få annan information om nätverket (vanligtvis DNS).

när noden har en global adress i nu behöver en standardrutt. Den bildar standardruttlistan från RA-paket som har en routerlivslängd som inte är noll. Alla dessa är konfigurerade som standardvägar till deras lokala länkadress med RA-angivet hoppantal. Slutligen kan noden lägga till specifika prefixvägar från RA-paket med noll routerlivstider men icke-länkade lokala prefix.

DHCPv6 är ett ganska komplext konfigurationsprotokoll (se RFC 8415) men det kan inte ange antingen prefixlängd (vilket betyder att alla erhållna adresser är konfigurerade som /128) eller rutter (dessa måste erhållas från RA-paket). Detta leder till en subtilitet av utgående adressval genom att det mest specifika alltid föredras, så om du konfigurerar både av SLAAC och DHCPv6, kommer SLAAC-adressen att läggas till som /64 och DHCPv6-adressen som /128 vilket betyder att din utgående IP-adress alltid kommer att vara DHCPv6-adressen (även om en extern enhet känner till din SLAAC-adress, kommer de fortfarande att kunna nå dig på den).

Hur: Konfigurera din egen hemrouter

en av de saker du skulle tro från ovanstående är att IPv6 alltid automatiskt konfigurerar och, även om det är sant att om du bara ansluter din bärbara dator till ethernet-porten på ett kabelmodem, kommer det bara att konfigureras automatiskt, de flesta har en mer komplex heminställning med en router, som behöver lite speciell coaxing innan den fungerar. Det betyder att du måste få ytterligare funktioner från din internetleverantör med hjälp av speciella DHCPv6-förfrågningar.

detta avsnitt är skrivet ur min egen synvinkel: Jag har ett ganska komplext IPv4-nätverk som har ett helt öppet men bandbreddsbegränsat (till otillförlitliga klienter) wifi-nätverk och flera skyddade interna nätverk (en för mitt labb, en för mina telefoner och en för hushållskamerorna), så jag behöver minst 4 subnät för att ge varje enhet i mitt hem en IPv6-adress. Jag använder också OpenWRT som min routerdistribution, så All IPv6-konfigurationsinformation är mycket specifik för den (även om det bör noteras att saker som NetworkManager också kan göra allt detta om du är beredd att gräva i dokumentationen).

Prefixdelegation

eftersom DHCPv6 bara delar ut en /128-adress är det inte tillräckligt eftersom det är routerns IP-adress. För att bli en router måste du begära delegering av en del av IPv6-adressutrymmet via alternativet Identity Association for Prefix Delection (Ia_pd) i DHCPv6. När detta är gjort kommer routerns IP-adress att antas av ISP att vara rutten för alla delegerade prefix. Subtiliteten här är att om du vill ha mer än ett delnät måste du be om det specifikt (klienten måste ange den exakta prefixlängden den Letar efter) och eftersom det är en prefixlängd och ditt standardundernät ska vara /64, om du begär en prefixlängd på 64 har du bara ett delnät. Om du begär 63 har du 2 och så vidare. Problemet är hur vet du hur många subnät ISP är villiga att ge dig? Tyvärr finns det inget sätt att hitta detta (jag var tvungen att göra en internetsökning för att upptäcka min ISP, Comcast, var villig att delegera en prefixlängd på 60, vilket betyder 16 subnät). Om sökning inte berättar hur mycket din Internetleverantör är villig att delegera, kan du försöka börja vid 48 och arbeta dig till 64 i steg om 1 för att se vad den största delegationen du kan komma undan med (det har rapporterats om Internetleverantörer som låser dig vid din första delegerade prefixlängd, så börja inte vid 64). Den slutliga subtiliteten är att prefixet du delegeras kanske inte är samma prefix som adressen din router fick (min nuvarande comcast-konfiguration har min router på 2001:558:600a:… men mitt delegerade prefix är 2601:600:8280:66d0:/60). OBS! Du kan köra odhcp6c manuellt med alternativet-P om du måste söka din Internetleverantör för att ta reda på vilken storlek på prefixet du kan få.

konfigurera routern för Prefixdelegering

i OpenWRT-termer styrs routerns WAN DHCP(v6) – konfiguration av /etc/default/network. Du har redan ett WAN-gränssnitt (sannolikt kallat ’wan’) för DHCPv4, så du lägger helt enkelt till ett extra ’wan6’ – gränssnitt för att få en extra IPv6 och bli dual stack. I min konfiguration ser det ut som

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

den lilla odditeten är ifname: @wan berättar helt enkelt config att använda samma ifname som ’wan’ – gränssnittet. Att namnge det på detta sätt är viktigt om din wan är en bro, men det är ändå bra praxis. Det andra alternativet ’reqprefix’ berättar DHCPv6 att begära en / 60 prefix delegering.

dela ut delegerade prefix

detta visar sig vara anmärkningsvärt enkelt. För det första måste du tilldela ett delegerat prefix till var och en av dina andra gränssnitt på routern, men du kan göra det utan att lägga till ett nytt OpenWRT-gränssnitt för var och en av dem. Mitt interna IPv4-nätverk har alla statiska adresser, så du lägger till tre direktiv till var och en av gränssnitten:

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 att du är ett / n-nätverk (så det här är alltid /64 för mig) och ip6hint ’N’ betyder använd n som ditt subnät id och ip6ifaceid ’s’ betyder använd S som IPv6-suffixet (det här är standard ::1 Så om du är OK med det, utelämna detta direktiv). Så med tanke på att jag har ett 2601:600:8280:66d0:: / 60 prefix, kommer den globala adressen till detta gränssnitt att vara 2601: 600: 8280: 66d1:: ff. Nu syratestet, om du har rätt, bör den här globala adressen vara pingbar var som helst på IPv6-internet (om det inte är det är det troligt en brandväggsproblem, se nedan).

reklam som en Router

att helt enkelt delegera ett delegerat prefix på ett lokalt routergränssnitt är otillräckligt . Nu måste du få din router att svara på Routeransökningar på ff02:: 2 och eventuellt göra DHCPv6. Tyvärr har OpenWRT två mekanismer för att göra detta, vanligtvis båda installerade: odhcpd och dnsmasq. Vad jag hittade var att inget av mina direktiv i / etc/config/dhcp skulle träda i kraft tills jag inaktiverade odhcpd helt

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

och eftersom jag använder dnsmasq i stor utsträckning någon annanstans (split DNS för interna / externa nätverk), passade det mig bra. Jag beskriver först vilka alternativ du behöver i dnsmasq och för det andra hur du kan uppnå detta med hjälp av poster i OpenWRT /etc/config/dhcp-filen (jag tycker att det är användbart eftersom det alltid är klokt att kontrollera vad OpenWRT har lagt i /var/etc/dnsmasq.conf-fil).

det första dnsmasq-alternativet du behöver är ’enable-ra’ som är en global parameter som instruerar dnsmasq att hantera routerannonser. Nästa parameter du behöver är per-interface ’ra-param’ som anger de globala routerns annonsparametrar och måste visas en gång för varje gränssnitt du vill annonsera på. Slutligen tillåter alternativet ’dhcp-range’ mer detaljerad konfiguration av typen av RA-flaggor och valfri DHCPv6.

SLAAC eller DHCPv6 (eller båda)

på många sätt är detta en fråga om personligt val. Om du tillåter SLAAC kan värdar som vill använda sekretessförlängningsadresser (som Android-telefoner) göra det, vilket är bra. Om du också tillåter DHCPv6-adressval kommer du att ha en lista över adresser tilldelade värdar och dnsmasq kommer att göra DNS-upplösning för dem (även om det kan göra DNS för SLAAC-adresser förutsatt att det blir berättat om dem). En särskild tagg ’konstruktör’ finns för alternativet ’dhcp-range’ som säger att den ska konstruera den medföljande adressen (för antingen RA eller DHCPv6) från IPv6 global prefix för det angivna gränssnittet, vilket är hur du skickar ut våra delegerade prefixadresser. Lägena för ’ dhcp-range ’är’ ra-only ’för att inte tillåta DHCPv6 helt,’ slaac ’för att tillåta DHCPv6-adressval och’ ra-statslös ’ för att inte tillåta DHCPv6-adressval men tillåta annan DHCPv6-konfigurationsinformation.

baserat på försök och fel (och slutligen undersöka skriptet i /etc/init.D / dnsmasq) OpenWRT-alternativen som krävs för att uppnå ovanstående dnsmasq-alternativ är

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 nyckelalternativet med ’0’ som betyder SLAAC med DHCPv6-alternativ, ’1’ som betyder SLAAC med full DHCPv6, ’2’ som bara betyder DHCPv6 och ’3’ som bara betyder SLAAC. En annan OpenWRT oddity är att det inte verkar vara ett sätt att ställa in leasingområdet: det är alltid standard för antingen static only eller ::1000 till ::ffff.

brandväggskonfiguration

en av de saker som trippar upp människor är det faktum att Linux har två helt separata brandväggar: en för IPv4 och en för IPv6. Om du någonsin har skrivit några anpassade regler för dem är chansen att du gjorde det i OpenWRT /etc/firewall.användarfil och du använde kommandot iptables, vilket innebär att du bara lagt till reglerna i IPv4-brandväggen. För att lägga till samma regel för IPv6 måste du duplicera den med kommandot ip6tables. Ett annat viktigt problem, om du använder en anslutningsspårning för port knock detection som jag är, är att Linux-anslutningsspårning har svårt med IPv6 multicast, så paket som går ut till en multicast men kommer tillbaka som unicast (som de flesta upptäcktsprotokoll gör) får fel conntrack-tillstånd. För att åtgärda detta måste jag så småningom ha en INGÅNGSREGEL som bara accepterar alla ICMPv6 och DHCPv6 (udp-portar 546 och 547 ). De andra brandväggshänsyn är att nu alla har sin egen IP-adress, Det finns inget behov av att NAT (OpenWRT kan övertalas att ta hand om detta automatiskt, men om du duplicerar IPv4-reglerna manuellt, duplicera inte nat-reglerna). Den sista är sannolikt mer tillämplig på mig: mitt wifi-gränssnitt är utformat för att vara en förlängning av det lokala internet och alla maskiner som ansluter till det förväntas kunna skydda sig eftersom de kommer att migrera till sådana fientliga miljöer som airport wifi, så jag gör fullständig exponering av wifi-anslutna enheter till det allmänna internet för alla portar, inklusive portprober. För mina interna enheter har jag en relaterad,etablerad regel för att se till att de inte är probed eftersom de inte är utformade för att migrera från det interna nätverket.

nu problemen med OpenWRT: eftersom du vill ha NAT på IPv4 men inte på IPv6 måste du ha två separata Wan –zoner för dem: om du försöker kombinera dem (som jag först gjorde), kommer OpenWRT att lägga till en IPv6-ctstate ogiltig regel som förhindrar att Grannupptäckten fungerar på grund av conntrack-problemen med IPv6 multicast, så mina wan-zoner är (det här är en lögn eftersom min brandvägg nu är handgjord, men det här är vad jag kollade fungerade innan jag satte den handgjorda brandväggen på):

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

och routningsreglerna för lan-zonen (fullt tillgänglig) är

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

sätta ihop den: Få klienterna IPv6 anslutna

nu när du har konfigurerat din router ska allt bara fungera. Om det gjorde det, bör ditt bärbara wifi-Gränssnitt nu ha en global IPv6-adress

ip -6 address show dev wlan0

om det kommer tillbaka tomt måste du aktivera IPv6 på din distribution. Om den bara har en link local (fe80:: prefix) – adress är IPv6 aktiverad men din router annonserar inte (misstänker brandväggsproblem med discovery-paket eller dnsmasq-felkonfiguration). Om du ser en global adress är du klar. Nu ska du kunna gå till https://testv6.com och säkra en 10/10 poäng.

den sista pusselbiten föredrar din nya IPv6-anslutning när DNS erbjuder ett urval av IPv4-eller IPv6-adresser. Alla moderna Linux-klienter bör föredra IPv6 när de är tillgängliga om de är anslutna till ett dual stack-nätverk, så försök … om du pingar, säg, www.google.com och se en IPv6-adress du är klar. Om inte, måste du komma in i den skumma världen av IPv6-adressmärkning (RFC 6724) och gai.conf.

slutsats

att lägga till IPv6 till och befintlig IPv4-inställning är för närvarande inte en enkel plug in and go-operation. Men förutsatt att du förstår en handfull skillnader mellan de två protokollen är det inte heller ett oöverstigligt problem. Jag har också glansat över många av de problem du kan stöta på med din ISP. Vissa människor har rapporterat att deras Internetleverantörer bara delar ut en IPv6-adress utan prefixdelegation, i vilket fall Jag tror att hitta en ny ISP skulle vara klokast. Andra rapporterar att ISP endast kommer att delegera ett /64-prefix så ditt val här är antingen att bara köra ett subnät (sannolikt tillräckligt för många hemnätverk) eller subnät vid större än /64 och förbjuda SLAAC, vilket definitivt inte är en rekommenderad konfiguration. Men förutsatt att din Internetleverantör är rimlig bör det här blogginlägget åtminstone hjälpa dig att komma igång.