IPv6 трафик VPN-ээр явах уу, шууд явах уу?

Өнгөрсөн сард хоёр хүн надаас эсрэг тэсрэг үр дүн хүссэн: нэг нь IPv6-г VPN хамруулахыг хүссэн, нөгөө нь оффисын принтер үргэлжлүүлэн ажиллахыг хүссэн. Ганц ::/0 маршрут хоёуланг нь дангаараа хангаж чадахгүй. Тухайн маршрут туннелийн дотор байх эсэх нь гурван нөхцлөөс хамаарч, эхний нөхцөл түүнийг ихэнх арилжааны гарцуудад оруулахгүй. Хэрэв гарц IPv6 дамжуулдаггүй бол анхдагч маршрутыг тийш чиглүүлэх нь таны трафикийг явуулах газаргүй туннельд нуудаг.

Хариултыг гурван нөхцөл шийднэ

Анхдагч маршрут нь нэг мөр, ::/0, бөгөөд илүү тодорхой маршрутгүй аливаа IPv6 очих цэгтэй тохирно (RFC 4291). Үүнийг суулгах хялбар. Үүнийг хийх ёстой эсэхийг шийдэх нь гурван нөхцөлд хүрнэ.

Нэгдүгээр нөхцөл: холбогдож буй гарц ажиллаж буй IPv6-тай бөгөөд түүнийг дамжуулахад бэлэн. Хоёрдугаар нөхцөл: таны клиент туннелийн төгсгөлийн цэг рүү зам хадгалж чадна, энэ нь ихэвчлэн таны маршрутлах гэж буй хүрээний дотор байдаг. Гуравдугаар нөхцөл: туннелийн гадна үлдэх ёстой локал IPv6 очих цэгүүдийг нэрлэж чадна.

Нөхцөл бүр өөрийн аргаар бүтэлгүйтдэг тул таамаглах нь бүтэн оройг үрэх юм. Бүтэлгүйтсэн нэгдүгээр нөхцөл танд чимээгүй байдал, зөв харагдах маршрутын хүснэгт өгнө. Бүтэлгүйтсэн хоёрдугаар нөхцөл гар барилтыг эхэлснээс хэдхэн секундын дараа ална. Бүтэлгүйтсэн гуравдугаар нөхцөл ажиллаж буй туннель болон принтерийн дэргэд дургүйцсэн хамт ажилтныг үлдээнэ.

Гарц үнэхээр IPv6 дамжуулж байна уу?

IPv6 хаягтай туннелийн интерфэйс нөгөө талын талаар юу ч батлахгүй. Олон арилжааны профайл дотроо зөвхөн IPv4: сервер танд v4 хаяг өгч, бусад бүгдийг хаядаг. Дээр нь AllowedIPs-аас анхдагч маршрут тавь, тэгвэл цөм IPv6-г хамтрагч нь хэзээ ч хардаггүй интерфэйс руу баяртайгаар илгээнэ.

Туннель босгосон үед клиентээс шалга. ping -6 -c 3 2001:4860:4860::8888 болон ip -6 route get 2001:4860:4860::8888 өөр өөр асуултад хариулна: хариу буцаж ирэх эсэх, цөм аль төхөөрөмжийг сонгосон. Хоёр дахь нь таны туннелийг нэрлэж, эхнийх нь юу ч буцаадаггүй бол асуудал маршрут дээр биш, гарц дээр байна.

Хэрэв та гарцыг өөрөө удирддаг бол клиентийн шалгалт давж, зам байсан ч мухардмал болж болно. Гарц дээр net.ipv6.conf.all.forwarding=1 асаалттай, түүний галт ханын туннельд дамжуулсан пакетуудыг хүлээж авдаг эсэхийг батал. Дамжуулахаас татгалздаг гарц руу зөв маршрутлагдсан пакет клиентийн талаас яг маршрутлалтын алдаа мэт харагдана.

Клиент төгсгөлийн цэг рүү замаа хадгалж чадах уу?

Энэ нь зөвхөн IPv6 WireGuard төгсгөлийн цэгтэй зөөврийн компьютер дээр намайг бариулсан тохиолдол. Төгсгөлийн цэгийн хаяг нь энгийн дэлхийн хаяг тул ::/0 дотор орно. Бүх префиксыг интерфэйс руу маршрутла, тэгвэл гар барилтын пакетууд байгуулах гэж буй туннель руугаа өөрсдийгөө хөөнө. Туннель хэзээ ч босохгүй, клиентийн гаралтад яагаад гэдэг нь ч хэлэгдэхгүй.

wg-quick үүнийг Linux дээр шийднэ. Энэ нь AllowedIPs-аас маршрутуудыг гаргаж, өөрийн хүснэгтэд суулгаж, төгсгөлийн цэг рүү трафикийг эхлээд үндсэн хүснэгтээр шийдэх бодлогын дүрэм нэмнэ: suppress_prefixlength 0 дүрэм, үүнийг ip -6 rule-аас олно. Тиймээс wg-quick up гар аргаар бичсэн ip -6 route add default dev wg0 таныг таслах газарт амжилттай болно.

Туннель босгохоос өмнө болон дараа нь хоёр төлөвийг ip -6 route get <endpoint-v6>-ээр шалга. Хариулт таны туннелийн төхөөрөмж рүү өөрчлөгдвөл та туннельд хэрэгтэй замыг устгасан байна. Маршрутуудыг өөрөө бичихдээ төгсгөлийн цэг рүү анхны гарцаар дамжуулан хост маршрут нэм, эсвэл IPv4-ээр төгсгөлийн цэгт холбогдож, IPv6-г ачаалалд үлдээ.

Туннелийн гадна юу үлдэх ёстой вэ?

Илүү тодорхой маршрутууд анхдагчийг ялдаг тул холбоос дээрх префикс эсвэл өөрийн маршруттай ULA хүрээ нэмэлт хүчин чармайлтгүйгээр ажилласаар байна. Энэ нь олон бүрэн туннельт IPv4 тохиргоо амьд үлддэгийн тайван шалтгаан: LAN префиксүүд анхдагчаас илүү тодорхой бөгөөд туннельд хэзээ ч ордоггүй.

Локал төхөөрөмж дэлхийн хаягаар хүрэх боломжтой үед энэ нурна, энэ нь ижил чиглүүлэгчээс нийтийн префикс авсан принтер, NAS эсвэл телевизорын хувьд хэвийн. Тэдгээр хаягууд ::/0-тай л тохирч, өөр юутай ч тохирохгүй тул бусад бүхний хамт туннельд шилжиж алга болно.

Протоколоор биш, очих цэгээр шийд. Хоёр, гурав локал хост чухал бол тэдгээрийн префиксүүдэд физик интерфэйсээр гарах маршрут өг, эсвэл тохиролцсон багцаас хас. Жагсаалт үргэлжлүүлэн өсвөл шударга хариулт нь бичгээр гаргасан үл хамаарах жагсаалттай IPv6-ийн хуваагдсан туннель, таны байнга засварлаж байдаг анхдагч биш.

Хариулт үгүй бол түүнийг хаа

IPv6-г маршрутгүй орхих нь түүнийг ганцааранг нь орхихтой ижил биш. Ажиллаж буй IPv6 анхдагчтай хост туннель IPv4 дамжуулж байх хооронд ч үүнийг ашигласаар байна, тиймээс трафик VPN-ийн хажуугаар гарна бөгөөд IPv6-г илүүд үздэг бүх үйлчилгээ таны жинхэнэ хаягийг харна. Энэ нь алдагдал, хуваагдсан туннель биш.

Нэгийг сонгоод аль нэгийг сонгосноо бич. Анхдагчийг маршрутлаж дээрх буултуудыг хүлээж ав, эсвэл туннель үргэлжлэх хугацаанд IPv6-г идэвхгүй болго. Префиксыг AllowedIPs-аас орхих нь дангаараа хангалтгүй, учир нь үйлдлийн систем өөрийн анхдагчийг хадгалдаг. Linux дээр бүдүүлэг хувилбар нь sysctl -w net.ipv6.conf.all.disable_ipv6=1; нарийн хувилбар нь галт ханын дүрмээр IPv6-г туннелийн гадна унагана. Утасны клиентүүдэд ижил ажил хийдэг тодорхой IPv6 хаах унтраалга байдаг.

Алдагдлын адил шалга

Туннелийг босгож, унтраалгад итгэхийн оронд төлөвийг унш. ip -6 route show default нэг анхдагч харуулах ёстой, LAN-аас гадна очих цэгийн хувьд ip -6 route get туннелийн төхөөрөмжийг нэрлэх ёстой. Салгасны дараа хоёуланг нь давта: туннелиас урт насалсан анхдагч бол чиний хайж байсан алдаа.

Дараа нь эсрэг чиглэлийг шалга. Локал сүлжээн дэх хостноос клиент рүү түүний локал IPv6 хаягаар хүр. Хэрэв энэ ажиллахаа боливол гуравдугаар нөхцөл хэзээ ч биелээгүй, тухайн үед маршрутын хүснэгт юу гэж байсан ч.

Үр дүнг дараагийн хүн олох газарт бич: ямар префиксүүд локал үлдэх, яагаад, салгасны дараа клиент юу хийдэг. Runbook дахь хоёр мөр дараагийн инженерт шөнө дунд төгсгөлийн цэгийн давталтыг дахин нээхээс хамгаална.