IPv6 туннелийн түнш рүү ping бүтэхгүй байна уу? :: хаягийг шалгана уу

IPv6 туннелийн нэг үзүүр нөгөө рүү ping илгээдэг боловч зөвхөн нэг чиглэл хариулдаг. Интерфейс асаалттай, маршрут зөв харагдаж байна, логт үүнийг тайлбарлах зүйл байхгүй. Таны оноосон хаяг нь дэд сүлжээний маршрутлагчийн anycast хаяг бөгөөд энэ нь огт хост хаяг биш бөгөөд хоёр үзүүртэй холбоос дээр яг нэг хүргэх зорилготой: илгээгч. Ямар ч timeout утга үүнийг засварлахгүй, учир нь хаяг таны бодож байгаа зүйлийг хийхгүй байна.

Хаяг руу заасан шинж тэмдэг

Холбоос дээрх бүх хост хариулдаг, зөвхөн интерфейсийн танигч нь бүх тэг байгаа хост л хариулахгүй. Тухайн хэлбэр рүү хаягласан пакет тодорхойлолтоор дэд сүлжээний маршрутлагч руу хүргэгддэг тул цэгээс цэг рүү туннельд илгээсэн машин руугаа буцаж ирдэг. Алслагдсан үзүүрээс энэ нь хүрэх боломжгүй түнш мэт уншигдана; ойрын үзүүрээс нам гүм мэт. Ижил префиксээс өөр танигч тавьж үзээрэй, өөр ямар ч өөрчлөлтгүйгээр шинж тэмдэг алга болно, маршрутуудад хүрэхээс өмнө авах ёстой баталгаа нь энэ.

Бүх тэгтэй танигч anycast хэлбэрээр нөөцлөгдсөн

RFC 4291 бүх тэгтэй интерфейсийн танигчийг дэд сүлжээний маршрутлагчийн anycast хаяг хэлбэрээр хадгалдаг тул /64 гэх мэт 2001:db8:4a::/64 дотор ашиглах боломжтой хост байхгүй 2001:db8:4a:: хаяг дээр. Энэ нөөцлөлт өөрийн байр суурийг хүртдэг: маршрутлагчийн зарлал, хөршийн илрүүлэлт тухайн хэлбэрийг хаягладаг бөгөөд маршрутлагч өөрөө үйлчилж буй префиксийн төлөө хариулдаг. Тэр утгыг туннелийн үзүүрт оноох нь навчид маршрутлагчийн үүрэг өгөх бөгөөд иймээс юу ч буцаж ирэхгүй. Префикс дэх бусад аль ч танигч хост хэлбэрээр ажилладаг тул засвар нь ихэвчлэн нэг орон.

Нөөцлөлтийг туннелийн үзүүрээс авах эрхгүй үүрэг гэж үзээрэй, маршрутаар тойрч гарах хачирхалтай зүйл гэж биш.

Хост хаягуудыг оноож, префиксийг маршрутлана уу

Хоёр үзүүрт ::1 болон ::2 сонгоод, нэгийг нь дараах командаар нэмнэ үү: ip -6 addr add 2001:db8:4a::2/64 dev tun0, дараа нь алслагдсан префикст хаяг өгөх гэж оролдохын оронд түүнийг маршрутлана уу. 2001:db8:4a::/64 -ийн туннелээр гарах маршрут нь алслагдсан талыг хүртээмжтэй болгоно; зөвхөн хаяг нь локал интерфейсийг тохируулна.

Бүрэн туннельд гурав дахь алхам бий: төхөөрөмжөөр дамжин глобал unicast-ийн анхдагч маршрут, энэ нь бүгдийг туннель руу илгээхийн IPv6 дүйцэл юм. Үүнийг орхивол IPv4 туннель дотор аялах хооронд IPv6 физик холбоосыг ашигласар байх тул хост таны бүрхэгдсэн гэж бодсон урсгалыг яг тэр чигээр нь алддаг. Дараах командаар баталгаажуулна уу: ip -6 route get 2001:4860:4860::8888 мөн хариултыг таамаглахын оронд аль төхөөрөмжийг нэрлэж байгааг уншина уу.

multicast нь маршрутлахаас өмнө татгалзагдана

Android VpnService.Builder -д зориулсан хаяг, маршрутыг LinkAddress-аар баталгаажуулдаг бөгөөд тэр конструктор multicast-ыг шууд татгалздаг. Түүнд маршрут хэлбэрээр multicast префикс өгвөл үр дүн нь маршрут биш, харин муу LinkAddress параметрийн алдаа болно, энэ нь сүлжээний биш, баталгаажуулалтын хариулт юм. Татгалзал нь орчинд тохирно: цэгээс цэг рүү tun төхөөрөмж холбоосын түвшний multicastгүй тул түүн дээрх бүлгийн маршрутад суулгах хүргэх загвар байхгүй. Бүлгийн хаягуудыг гараар тохируулахын оронд стек өөрөө үүсгэж хэрэглэдэг.

IPv6 all-nodes болон solicited-node хаягууд мөн ижил дүрэмд хамаарна. Интерфейс тэдгээрийг стек тэнд тавьсан учраас агуулж байгаа бөгөөд ямар нэг бодлого төлөвлөсөн учраас биш.

Туннель оронд нь юу зөөж болох вэ

туннель дамжуулан multicast илрүүлэлт -ийг зөөхөд бүлгийн гишүүнчлэлийг ойлгодог давхарга хэрэгтэй: Ethernet сегментийг танилцуулах TAP гүүр, програмын түвшний релей, эсвэл аль түншүүд рүү хуулахыг тодорхой хэлсэн маршрутлалтын протокол. VpnService загварт эдгээрийн аль нь ч байхгүй, тэнд програм пакетийг уншиж бичдэг бөгөөд туннелийн төлөө бүлэгт нэгдэх дуудлага байхгүй. Бүлгийг ойлгодог бүрэлдэхүүнийг нэмэх эсвэл загвараас шаардлагыг хасах хэрэгтэй.

Харин unicast нь дээрх хаяг, маршрутаас гадна юу ч нэмж шаарддаггүй тул туннелүүд түүнийг зөөнө гэж хүлээгддэг, дараа нь илрүүлэлтийн протокол бүтэлгүйтэхэд тэднийг буруутгадаг.

Ямар нэг зүйлийг оноохоос өмнөх гурван шалгалт

Хаяг anycast хэлбэр биш, multicast биш, мөн префикс төхөөрөмжид зөвхөн оноогдоогүй харин маршрутлагдсаныг баталгаажуулна уу. Дараа нь туршилтаа жинхэнэ хост болох очих газар руу илгээнэ үү, учир нь anycast хаяг руу чиглэсэн ping илгээгчийг хэмждэг бөгөөд замын талаар юу ч хэлдэггүй. Тэдгээр гурван шалгалтыг өөрчлөлтийн бүртгэлд хадгалж, дараагийн байршуулалт тэдгээрийг дахин нээхгүй байг.

Платформ хэзээ ч суулгаагүй маршрутыг илүү удаан хүлээж дибаг хийх боломжгүй, хэзээ ч хост байгаагүй хаягийг илүү сайн ping-ээр засах боломжгүй.