IPv6 tunnel partneri ping ebaõnnestub? Kontrollige aadressi ::

IPv6 tunnel üks ots pingib teist ja vastab alati ainult üks suund. Liides on üleval, marsruut näib õige ja logis ei selgita seda miski. Aadress, mille määrasite, on alamvõrgu ruuteri anycast-aadress, mis ei ole üldse hosti aadress, ja kahe otspunktiga lingil on sellel täpselt üks kohaletoimetamise sihtmärk: saatja. Ükski ajapiiri väärtus ei paranda seda, sest aadress ei tee seda, mida arvate.

Sümptom, mis osutab aadressile

Iga host lingil vastab, välja arvatud see, mille liidese identifikaator on kõik nullid. Sellele vormile adresseeritud pakett toimetatakse definitsiooni järgi alamvõrgu ruuterile, seega punkt-punkt-tunnelis tuleb see tagasi masinale, mis selle saatis. Kaugemast otsast loetakse seda kättesaamatuks partneriks; lähemast otsast vaikuseks. Vahetage sama prefiksi teine identifikaator sisse ja sümptom kaob ilma ühegi muu muudatuseta, ning see on kinnitus, mille peate saama enne marsruutide puudutamist.

Kõigist nullidest identifikaator on reserveeritud anycast'ina

RFC 4291 hoiab kõigist nullidest liidese identifikaatori alamvõrgu ruuteri anycast-aadressina, seega /64 nagu 2001:db8:4a::/64 ei sisalda ühtegi kasutatavat hosti aadressil 2001:db8:4a::. Reserveering väärib oma kohta: ruuteri kuulutused ja naabrite avastamine adresseerivad seda vormi ning ruuter vastab prefiksi eest, mida ta teenindab. Selle väärtuse määramine tunneli otspunktile annab lehele ruuteri rolli ja seetõttu ei tule midagi tagasi. Iga muu identifikaator prefiksis töötab hostina, seega on parandus tavaliselt üks number.

Käsitlege reserveeringut rollina, mida teil ei ole õigust tunneli otspunktist võtta, mitte veidrusena, mille saab marsruudiga mööda minna.

Määrake hosti aadressid ja marsruutige prefiks

Valige ::1 ja ::2 kahe otsa jaoks, lisage üks käsuga ip -6 addr add 2001:db8:4a::2/64 dev tun0, ja seejärel marsruutige kaugem prefiks, selle asemel et proovida seda adresseerida. Marsruut aadressile 2001:db8:4a::/64 läbi tunneli teeb kaugema poole kättesaadavaks; aadress üksi teeb ainult kohaliku liidese seadistatuks.

Täieliku tunneli jaoks on kolmas samm, vaikimisi marsruut globaalse unicast'i jaoks läbi seadme, mis on IPv6 vaste kõige tunnelisse saatmisele. Kui see vahele jätta, jätkab IPv6 füüsilise lingi kasutamist, samal ajal kui IPv4 liigub tunneli sees, nii et host lekitab täpselt seda liiklust, mida arvasite olevat kaetud. Kinnitage käsuga ip -6 route get 2001:4860:4860::8888 ja lugege, millist seadet see nimetab, selle asemel et vastust eeldada.

Multicast lükatakse tagasi enne marsruutimist

Android valideerib VpnService.Builder -rajapinnalle antavad aadressid ja marsruudid LinkAddress kaudu, ja see konstruktor lükkab multicast'i otsekohe tagasi. Kui anda sellele marsruudina multicast-prefiks, on tulemuseks marsruudi asemel halbade LinkAddress-parameetrite tõrge, mis on valideerimise, mitte võrgu vastus. Keeldumine vastab kandjale: punkt-punkt tun-seadmel puudub lingikihi multicast, seega ei ole grupimarsruudil sellel kohaletoimetamise mudelit, mida paigaldada. Grupi aadresse loob ja tarbib stack ise, mitte ei seadistata käsitsi.

IPv6 all-nodes ja solicited-node aadressid kuuluvad sama reegli alla. Liides kannab neid, sest stack pani need sinna, mitte sellepärast, et poliitika neid kavatses.

Mida tunnel selle asemel kanda saab

multicast-tuvastuse tunnelist läbi viimine nõuab kihti, mis mõistab grupiliikmelisust: TAP-sild, mis esitleb Ethernet-segmenti, rakendustasandi relee või marsruutimisprotokoll, millele öeldakse selgesõnaliselt, millistele partneritele dubleerida. VpnService mudelis ei ole midagi sellest olemas, kus rakendus loeb ja kirjutab pakette ega oma ühtegi kutset, mis liituks tunnelil grupiga. Kas lisage komponent, mis gruppe mõistab, või jätke nõue disainist välja.

Unicast seevastu ei vaja midagi lisaks ülaltoodud aadressidele ja marsruutidele, mistõttu tavaliselt eeldatakse, et tunnelid seda kannavad, ja siis süüdistatakse neid, kui avastamisprotokoll ebaõnnestub.

Kolm kontrolli enne millegi määramist

Kinnitage, et aadress ei ole anycast-vorm, kinnitage, et see ei ole multicast, ja kinnitage, et prefiks on marsruuditud, mitte ainult seadmele määratud. Seejärel saatke oma test sihtkohta, mis on tõeline host, sest anycast-aadressile suunatud ping mõõdab saatjat ega ütle tee kohta midagi. Hoidke need kolm kontrolli muudatuste kirjes, et järgmine juurutus neid uuesti ei avastaks.

Marsruuti, mida platvorm kunagi ei paigaldanud, ei saa siluda kauem oodates, ja aadressi, mis kunagi host ei olnud, ei saa parema pingiga parandada.