Ping till din IPv6-tunnels motpart misslyckas? Kontrollera adressen ::

Den ena änden av din IPv6-tunnel pingar den andra och bara en riktning svarar någonsin. Gränssnittet är uppe, rutten ser rätt ut och inget i loggen förklarar det. Adressen du tilldelade är subnet-router anycast-adressen, som inte alls är en värdadress, och på en länk med två ändpunkter har den exakt ett leveransmål: avsändaren. Inget timeoutvärde reparerar det, eftersom adressen inte gör det du tror att den gör.

Symtomet som pekar på adressen

Varje värd på länken svarar utom den vars gränssnittsidentifierare är enbart nollor. Ett paket som adresseras till den formen levereras per definition till en router i subnätet, så på en punkt-till-punkt-tunnel kommer det tillbaka till maskinen som skickade det. Från fjärränden läses det som en onåbar motpart; från näränden läses det som tystnad. Byt till en annan identifierare från samma prefix och symtomet försvinner utan någon annan ändring, vilket är bekräftelsen du ska skaffa innan du rör rutterna.

Identifieraren med enbart nollor är reserverad som anycast

RFC 4291 behåller gränssnittsidentifieraren med enbart nollor som subnet-router anycast-adressen, så ett /64 som 2001:db8:4a::/64 innehåller ingen användbar värd på 2001:db8:4a::. Reservatet har sin plats: router advertisements och neighbour discovery vänder sig till den formen och en router svarar för det prefix den betjänar. Att tilldela det värdet till en tunnelände ger en routerroll till ett löv, och det är därför inget kommer tillbaka. Vilken annan identifierare som helst i prefixet fungerar som värd, så reparationen är oftast en siffra.

Behandla reservatet som en roll du inte har rätt att inta från en tunnelände, inte som en egenhet att routa runt.

Tilldela värdadresser och dirigera prefixet

Välj ::1 och ::2 för de två ändarna, lägg till en med ip -6 addr add 2001:db8:4a::2/64 dev tun0 och dirigera sedan fjärrprefixet i stället för att försöka adressera det. En rutt för 2001:db8:4a::/64 ut ur tunneln gör fjärrsidan nåbar; adressen ensam gör bara det lokala gränssnittet konfigurerat.

För en full tunnel finns ett tredje steg, en standardrutt för global unicast genom enheten, vilket är IPv6-motsvarigheten till att skicka allt in i tunneln. Hoppar du över det fortsätter IPv6 att använda den fysiska länken medan IPv4 färdas inuti tunneln, så värden läcker precis den trafik du trodde var täckt. Bekräfta med ip -6 route get 2001:4860:4860::8888 och läs vilken enhet den anger i stället för att anta svaret.

Multicast avvisas före routning

Android validerar adresser och rutter för VpnService.Builder genom LinkAddress, och den konstruktorn avvisar multicast direkt. Ge den ett multicastprefix som rutt och resultatet blir ett bad LinkAddress parameters-fel i stället för en rutt, vilket är ett valideringssvar och inte ett nätverkssvar. Avvisandet matchar mediet: en punkt-till-punkt-tun-enhet har ingen link-layer-multicast, så en grupprutt på den har ingen leveransmodell att installera. Gruppadresser skapas och konsumeras av stacken själv i stället för att konfigureras för hand.

IPv6 all-nodes- och solicited-node-adresser faller under samma regel. Gränssnittet bär dem eftersom stacken satte dem där, inte för att någon policy avsåg dem.

Vad en tunnel kan bära i stället

Att flytta multicast-upptäckt genom en tunnel kräver ett lager som förstår gruppmedlemskap: en TAP-brygga som presenterar ett Ethernet-segment, en relay på applikationsnivå eller ett routingprotokoll som uttryckligen får veta vilka parter som ska replikeras till. Inget av det finns i VpnService-modellen, där applikationen läser och skriver paket och inte har något anrop som ansluter en grupp för tunneln. Antingen lägg till komponenten som förstår grupper eller stryk kravet från designen.

Unicast däremot behöver inget extra utöver adresserna och rutterna ovan, vilket är varför tunnlar vanligen förväntas bära det och sedan får skulden när ett upptäcktsprotokoll misslyckas.

Tre kontroller innan du tilldelar något

Bekräfta att adressen inte är anycast-formen, bekräfta att den inte är multicast och bekräfta att prefixet är dirigerat och inte bara tilldelat enheten. Skicka sedan ditt test till ett mål som är en riktig värd, eftersom en ping mot anycast-adressen mäter avsändaren och inte säger något om vägen. Skriv in de tre kontrollerna i ändringsprotokollet så att nästa driftsättning inte upptäcker dem igen.

En rutt som plattformen aldrig installerade kan inte felsökas genom att vänta längre, och en adress som aldrig var en värd kan inte repareras med en bättre ping.