Muutama päivä jäljellä uuden virtauksen alkamiseen nopeudella OTUS:lta. Tältä osin haluaisimme jakaa kanssasi käännöksen hyödyllisestä materiaalista aiheesta.
Sarja blogikirjoituksia vihjeistä ja temppuista IPv6-ping-ongelmien vianetsintään (ICMPv6 Echo Request/Echo Reply)
Huomaa, että käytän Linuxia (erityisesti Fedora 31:tä), mutta muiden käyttöjärjestelmien ping-komennon syntaksin pitäisi toivottavasti olla hyvin samanlainen.
Ping kaikki kanavan IPv6-solmut
Ensimmäinen ja yksinkertaisin vinkki on pingata kaikki linkin IPv6-solmut.
IPv6 käyttää monilähetysosoitteita kaikentyyppisissä yksi-moneen-viestinnöissä. Ei lähetys- (tai yleislähetys) IPv6-osoitteita. Tämä erottaa IPv6:n IPv4:stä, jossa on useita yleislähetysosoitteita, esimerkiksi "rajoitettu lähetysosoite" 255.255.255.255 [RFC1122].
On kuitenkin olemassa "all-nodes multicast" IPv6-osoite, joten käytämme sitä kaikkien linkin IPv6-solmujen ping-kutsuun. ("Broadcast"-osoite on itse asiassa vain nimetty monilähetysosoite, joka on monilähetysryhmä, joka sisältää kaikki solmut. Huomaa, että esimerkiksi "ryhmä"- tai monilähetysosoitebitti on kytketty päälle Ethernet-lähetysosoitteissa linkkikerroksessa ).
Kanavan kaikkien solmujen monilähetys IPv6-osoite: ff02::1. ff tarkoittaa monilähetys IPv6-osoitetta. Seuraava 0 on lipun osa, jossa on asettamattomia bittejä.
Edelleen 2 määrittää monilähetysryhmän alueen. Toisin kuin monilähetys-IPv4-osoitteilla, monilähetys-IPv6-osoitteilla on laajuus. Aluearvo ilmaisee verkon sen osan, jonka kautta ryhmälähetyspaketti on sallittu edelleenlähettää. Kun paketti saavuttaa määritetyn laajuuden rajan, paketti on hylättävä riippumatta siitä, onko sen Hyppymäärä-kenttä nollasta poikkeava. Tietenkin, jos hyppyjen määrä saavuttaa nollan ennen määritellyn ryhmälähetysryhmän rajan saavuttamista, se myös nollataan välittömästi. Tässä on täydellinen luettelo IPv6-monilähetysalueista.
Lopuksi ::1 määrittää kaikkien solmujen monilähetysryhmän.
Tietoja osoitteesta ff02::1 On huomattava, että se on epäselvä. IPv6-isännässä, jossa on useita liitäntöjä, kuten reititin tai monikotiisäntä, osoite ff02::1 ei ole mitään, missä voit määrittää, mille rajapinnalle ICMPv6-kaikupyynnöt lähetetään tai odotetaan saavansa ICMPv6-kaikuvastauksia niiden saapuessa. ff02::1 on voimassa ja sitä voidaan käyttää missä tahansa moniliittymäsolmuun liitetyssä liitännässä ja kanavassa.
Joten kun pingimme kaikki linkin IPv6-solmut, meidän on jotenkin kerrottava myös apuohjelmalle ping IPv6:lle, mitä käyttöliittymää käytetään.
Liitäntöjen määrittäminen - komentorivivaihtoehto
Kuten olemme jo nähneet, kaikkien solmujen monilähetysosoite, jota haluamme käyttää, on − ff02::1 - ei anna mitään tietoa siitä, mikä rajapinta lähettää ja vastaanottaa ICMPv6-kaikupyyntö- ja kaikuvastauspaketteja.
Joten kuinka määritämme käytettävän rajapinnan monilähetysosoiteavaruuteen tai unicast Link-Local -osoiteavaruuteen?
Ensimmäinen ja ilmeisin tapa on antaa se parametriksi käyttämällemme sovellukselle.
Hyödyllisyyden vuoksi ping tarjoamme sen vaihtoehdon kautta -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Käyttämällä tätä kaikkien solmujen monilähetyspingiä, saimme vastauksia kuudesta IPv6-solmusta. Vastaukset tulivat Link-Local IPv6 -solmuosoitteista etuliitteestä alkaen fe80::/10.
Että ping ei jatka ICMPv6-kaikupyyntöjen lähettämistä loputtomiin, kunnes keskeytämme sen, yleensä määritämme lähetettävien pakettien määrän -c-vaihtoehdon kautta. Tämä kuitenkin estää myös pingiä hyväksymästä ja näyttämästä useampaa kuin yhtä ICMPv6-kaikuvastausta lähetettäessä ryhmälähetys ICMPv6-kaikupyyntöä. Sen sijaan käytimme -w-vaihtoehtoa määrittääksemme, että pingin tulee päättyä 1 sekunnin kuluttua riippumatta siitä, kuinka monta ICMPv6-kaikupyyntöä tai -vastausta lähetettiin tai vastaanotettiin.
Toinen asia johon kannattaa kiinnittää huomiota on (DUP!) tulos toisessa ja sitä seuraavissa vastauksissa. Nämä paketit tunnistetaan kaksoisvastauksiksi, koska niillä on sama ICMP-sekvenssiarvo kuin yksittäisillä alun perin lähetetyillä ICMPv6-kaikupyynnöillä. Ne näkyvät, koska ICMPv6-monilähetyskaikupyyntö johtaa useisiin yksittäisiin yksittäislähetysvastauksiin. Myös kaksoiskappaleiden määrä ilmoitetaan tilastoyhteenvedossa.
Liitäntöjen määrittäminen - vyöhykkeen tunnus
Toinen tapa paljastaa käyttöliittymä on osa IPv6-osoiteparametria.
Näemme esimerkin tästä ping-lähdössä, jossa vastaavien IPv6-isäntien osoitteilla on myös pääte %enp3s2, esimerkiksi:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msTämä rajapintojen määrittelytapa on muodollisesti kuvattu julkaisussa [RFC4007], "IPv6 Defined Address Architecture". Vaikka niitä yleensä kutsutaan käyttöjärjestelmän käyttöliittymiksi, ne määrittelevät itse asiassa jotain yleisempää - "alueen" tai "soveltamisalueen".
Syy yleisempien vyöhykkeiden tai laajuusvyöhykkeiden käyttöön on se, että kuten [RFC4007]:ssä mainitaan, IPv6-solmussa voi olla useita eri IPv6-liitäntöjä yhdistettynä samaan kanavaan. Nämä rajapinnat ovat saman vyöhykkeen jäseniä.
Käyttöjärjestelmän vyöhykkeen sisällä pitäisi olla mahdollista ryhmitellä useita rajapintoja; Tällä hetkellä en tiedä onko tämä mahdollista Linuxissa tai miten se tehdään.
Päätteen käyttäminen %<zone_id>, voimme poistaa komentorivivaihtoehdon -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Linkki-paikallinen osoite vastaukset
Tästä kaikkien solmujen ryhmälähetyspingistä saimme yhteensä 6 ainutlaatuista vastausta.
Nämä vastaukset tulivat unicast Link-Local IPv6-isäntäosoitteista. Esimerkiksi tässä on ensimmäinen vastaus:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6-osoitteet vaaditaan kaikissa IPv6-yhteensopivissa liitännöissä [RFC4291], "IP-version 6 osoitearkkitehtuuri". Syynä tähän on se, että IPv6-solmulla on aina automaattisesti unicast IPv6-osoite, jota se voi ainakin käyttää kommunikoimaan muiden solmujen kanssa suoraan kytketyissä linkeissään. Tämä sisältää yhteydenpidon muiden isäntien sovellusten kanssa Link-Local-isäntäosoitteiden kautta.
Tämä yksinkertaistaa protokollien, kuten IPv6 Neighbor Discovery ja OSPFv3, suunnittelua ja käyttöönottoa. Se mahdollistaa myös isäntien loppukäyttäjien sovellusten kommunikoinnin kanavan kautta ilman, että kanavalla tarvitaan muuta tukevaa IPv6-infrastruktuuria. Suora viestintä kytkettyjen IPv6-isäntien välillä ei vaadi IPv6-reititintä tai DHCPv6-palvelinta yhteydessä.
Link-Local-osoitteet alkavat 10-bittisellä etuliitteellä fe80, jota seuraa 54 nollabittiä ja sitten 64-bittinen rajapintatunniste (IID). Yllä olevassa ensimmäisessä vastauksessa 2392:6213:a15b:66ff on 64-bittinen IID.
Kierretty monilähetys
Oletusarvoisesti monilähetyspaketit palautetaan sisäisesti solmulle, joka lähetti ne. Tämä tapahtuu sekä IPv6- että IPv4-osoitteissa.
Syy tähän oletuskäyttäytymiseen on se, että kun ryhmälähetyspaketteja lähetetään, voi myös olla kuunteleva paikallinen ryhmälähetyssovellus, joka on käynnissä lähettävässä isännässä sekä jossain verkossa. Tämän paikallisen sovelluksen on myös vastaanotettava monilähetyspaketteja.
Näemme tämän monilähetyksen paikallissilmukan ping-ulostulossamme:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...Ensimmäinen ja nopein vaste (0,106 ms verrattuna 0,453 ms) tulee itse käyttöliittymään määritetystä Link-Local-osoitteesta enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Apuohjelma ping tarjoaa tavan vaimentaa paikallista ryhmälähetyspalautetta parametrin avulla -L. Jos lähetämme kaikkien solmujen ryhmälähetyspingin tällä lipulla, vastaukset rajoittuvat etäsolmuihin. Emme saa vastausta lähetysliittymän Link-Local-osoitteesta.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...Ping Link-paikalliset osoitteet
Kuten saatat arvata, unicast Link-Local -osoitteet eivät itsessään myöskään anna tarpeeksi tietoa osoittamaan, mitä käyttöliittymää niihin tavoittaa. Kuten kaikkien solmujen monilähetyspingissä, meidän on myös määritettävä liitäntä komentoriviparametriksi ping tai vyöhyketunnus osoitteella, kun pingaat Link-Local-osoitteita.
Tällä kertaa voimme käyttää -crajoittaa lähetettyjen ja vastaanotettujen pakettien ja vastausten määrää ping, koska suoritamme unicast-pingia.
[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Pingtääkö (kaikki) muut IPv6-osoitteet?
Tässä artikkelissa näimme kuinka pingata kaikki kanavan IPv6-solmut käyttämällä kaikkien solmujen monilähetys IPv6-osoitetta ff02::1. Näimme myös kuinka määritellä, mitä liitäntää käytetään kaikkien solmujen IPv6-ryhmälähetysosoitteen kanssa, koska osoite itse ei voi tarjota näitä tietoja. Käytimme joko komentorivivaihtoehtoa ping, tai määrittänyt käyttöliittymän käyttämällä päätettä %<zone_id>.
Sitten opimme Unicast Link-Local -osoitteista, joita käytetään vastaamaan kaikkien solmujen ryhmälähetysten ICMPv6-kaikupyyntöihin.
Näimme myös kuinka monilähetyspaketit palautetaan oletusarvoisesti lähettävään solmuun ja kuinka tämä poistetaan käytöstä apuohjelmassa ping.
Lopuksi pingimme yhden Link-Local-osoitteen käyttämällä päätettä %<zone_id>, koska Link-Local-osoitteet itsessään eivät myöskään anna tietoa lähtevästä rajapinnasta.
Entä sitten ping kaikkiin muihin solmuihin ja saada niiden globaalit unicast-osoitteet (GUA) (eli niiden julkiset osoitteet Internetissä) tai yksilölliset paikalliset unicast-osoitteet (ULA)? Tarkastellaan tätä seuraavassa blogikirjoituksessa.
Se on kaikki.
Voit lukea lisää kurssistamme osoitteessa.
Lähde: will.com