Сайт хоорондын VPN дээгүүр IPv6 префикс дамжуулах: шалгах хуудас
Дамжуулсан IPv6 префиксийг сайт хоорондын VPN дээгүүр чиглүүлэх шалгалтууд: префиксийн зураг, трафикийн селекторууд, дамжуулалт, MTU, буцах зам, дахин дугаарлалт.
Туннелийг өргөх нь хялбар хагас. Сайт хоорондын холбоос хэдэн өдөр тогтвортой байсан ч алслагдсан LAN-ын бүх хост зөвхөн чимээгүй байдал авч байсныг би харсан, учир нь тэр гарцын ард дамжуулсан префикс интерфейс дээр тохируулагдсан боловч хэзээ ч туннельд чиглүүлэгдээгүй. Туннелийн хаягууд бүх цагт ping-д хариулж байсан бөгөөд яг ийм учраас хэн ч префиксийг хараагүй. Дамжуулсан IPv6 префикс сайтын VPN-ээр гарах ёстой үед би шалгадаг дараалал энэ: префиксийн зураг, трафикийн селекторууд, дамжуулалт ба firewall, дараа нь буцах зам.
Туннельд хүрэхээс өмнө префиксийн зургийг бич
Префикс дамжуулалт нь хүссэн чиглүүлэгчид блок өгдөг. Энэ нь хөрш дээр маршрут суулгахгүй, тэр блокийг on-link болгон сунгахгүй, хүсэгч чиглүүлэгчийн ард юу байгааг алслагдсан гарцад хэлэхгүй. Энэ гурвыг та өөрөө тохируулах ёстой бөгөөд аливаа тохиргооны файл өөрчлөгдөхөөс өмнө тэд хаягийн төлөвлөгөөнд багтах ёстой.
Сайт бүрийн хувьд дамжуулсан префикс, LAN дээр бодитоор ашиглаж буй /64, туннелийн хаягууд, маршрут бүрийн эзнийг тэмдэглэ. Үйлчилгээ үзүүлэгч A сайтад 2001:db8:a1::/56-г дамжуулж, тэр өөрийн LAN дээр 2001:db8:a1:10::/64-г үйлчилнэ; B сайт 2001:db8:b2::/64-г хадгална. Хэрэв A сайт зөвхөн тэр нэг /64-г үйлчилбэл хоёр төгсгөл бүх /56 биш 2001:db8:a1:10::/64-г нэрлэх ёстой.
Бараг үргэлж хоёр алдаа гардаг. Нэг нь алслагдсан префиксийг on-link гэж үзэж, гүүрдэх эсвэл туннелийн интерфейс дээр тавих бөгөөд ингэснээр гарц хүрч чадахгүй хостнуудын хөршийн хүсэлтэд хариулдаг. Нөгөө нь зөвхөн нэг /64 тохируулсан үед бүх /56-г сурталчлах: маршрутын хүснэгт блокийг хүрч болох гэж мэдэгдэж, ихэнх хаяг хар нүхэнд унадаг.
Хоёр төгсгөлийн трафикийн селекторуудыг маршрутуудтай тааруул
IKEv2 болон WireGuard хоёулаа тохирохгүй трафикийг татгалздаг бөгөөд туннель эрүүл харагдахын тулд хангалттай чимээгүй.
strongSwan-д селекторууд тодорхой байдаг. A сайтад:
conn a-to-b
left=2001:db8:ff::1
leftsubnet=2001:db8:a1:10::/64
right=2001:db8:ff::2
rightsubnet=2001:db8:b2::/64
auto=startB сайтын conn нь хоёр дэд сүлжээг тусгадаг. Тэд санал нийлэхгүй бол хариулагч CHILD_SA-г TS_UNACCEPTABLE-ээр татгалздаг тул IKE_SA өргөгдсөн ч child SA хэзээ ч өргөгдөхгүй. Хоёр талд тохируулсан дэд сүлжээ нь локал цөм туннель рүү чиглүүлж буйтай тэнцүү байх ёстой.
WireGuard ижил мэдээллийг AllowedIPs-д агуулдаг, нэг онцлогтой: AllowedIPs нь хүлээн авах үеийн эх фильтр бөгөөд илгээх үеийн маршрут. Хэрэв B сайтын A сайт руу чиглэсэн peer бичлэг 2001:db8:a1:10::/64-г орхивол A сайтаас ирсэн пакетууд хүчинтэй handshake-ээр ирж, зөвшөөрөгдөөгүй гэж хаягдана. Ингэснээр handshake байнга шинэчлэгдэж, хариу хэзээ ч гарахгүй танил хэв маяг үүсдэг. Хоёр төгсгөлийг wg show wg0 allowed-ips-ээр харьцуул. Дамжуулалт өөрчлөгдөх бүрт тэр жагсаалтыг дахин шалга; хуучирсан /64 сессийг амьд байлгаж, шинэ префиксийг хүрэхгүй болгодог.
Эхлээд дамжуулалт, firewall, MTU-г үгүйсгэ
Дараагийн лог мөрийг уншихаас өмнө гарцууд ерөнхийдөө дамжуулж байгаа эсэхийг батал. sysctl net.ipv6.conf.all.forwarding хоёуланд нь 1 буцаах ёстой бөгөөд туннель болон LAN интерфейсүүдэд ч хэрэглэнэ. Нэг урхи дагалддаг: дамжуулалт асаалттай болсны дараа accept_ra=1 интерфейс үйлчилгээ үзүүлэгчийн чиглүүлэгчийн зарлалыг хүлээн авахаа болино, ингэснээр төхөөрөмж туннель дотор төгс чиглүүлж байсан ч дээд урсгалын үндсэн маршрутаа алдаж болно. Үйлчилгээ үзүүлэгчийн RA одоо ч хэрэгтэй газар accept_ra=2 тохируул.
Дараа нь firewall дүрмүүд префиксийг хоёр чиглэлд зөвшөөрөх ёстой бөгөөд ICMPv6 амьд үлдэх ёстой: хөрш илрүүлэлт, packet-too-big, destination-unreachable нь заавал байх ёстой. Тэдгээрийг хаявал замын MTU илрүүлэлт эвдэрч, нээгдээд эхний том хариулт дээр гацах холболтууд үүснэ. Хамгийн бага дүрмийн хос ийм харагдана:
nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } acceptMTU үүний ард байдаг. Туннель ашиглах боломжтой MTU-г 1500-аас доош буулгадаг бөгөөд IPv6 холбоос бүр дор хаяж 1280 дамжуулахыг шаарддаг. Жижиг ping өнгөрдөг ч SSH сесс том тэсрэлт дээр хөлдөж, /proc/net/snmp6 хэзээ ч буцаж ирдэггүй packet-too-big мессежүүдийг харуулна. Туннелийн MTU-г тодорхой тохируул эсвэл mangle хүснэгтэд TCP MSS-ийг хязгаарлаж, бага MTU-г мэдээлэх ICMPv6-г буцахыг зөвшөөр.
Туннелийн хаяг биш, буцах замыг шалга
Хамгийн их цаг иддэг гэмтэл нь нэг чиглэлийн чиглүүлэлт юм. Гарц бүр алслагдсан префиксийг туннель рүү чиглүүлдэг ч хостнууд өөрийн үндсэн гарцаар хариулдаг, учир нь тэдний /64 тэнд амьдардаг. Пакетыг зорьсон газарт нь хүргэх нь замын хагас.
| What you see | Likely cause | First check |
|---|---|---|
| Tunnel up, every host silent | remote prefix not routed into the tunnel | ip -6 route get on both gateways |
| Handshake renews, no replies | source prefix missing from selectors or AllowedIPs | ipsec statusall, wg show allowed-ips |
| Small pings pass, transfers stall | MTU or ICMPv6 packet-too-big filtered | /proc/net/snmp6 counters |
| Old prefix still works | stale /64 left in routes or selectors | delegation lease and route table |
Хоёр команд ихэнхийг шийддэг. A сайтад ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 тэр эх сурвалжаас ирэх хариу аль интерфейсийг ашиглахыг харуулна; B сайтад толин шалгалт хий. Дараа нь гарцаас биш хостноос трафик үүсгэж, хоёр төгсгөлийн тоолуурыг харьцуул.
Хэрэв алслагдсан префиксийн хөршийн хүсэлт туннель дээр гарч ирвэл, тэр префикс байх ёсгүй газар on-link байна; маршрутуудыг засахаас өмнө үүнийг зас. Proxy NDP нь гүүрдэх үнэхээр шаардлагатай тохиолдлыг хамардаг бөгөөд маршрутыг орлохгүй.
Префикс чамайг байхад өөрчлөгдөнө гэж төлөвлө
Префикс дамжуулалт нь дамжуулагч болон хүсэгч чиглүүлэгчийн хоорондын түрээс бөгөөд шинэчлэл өөр блок буцааж болно: үйлчилгээ үзүүлэгч шилжсэний дараах өөр /56, эсвэл туннель ажилласан хугацаанаас богино түрээс. Хуучин префиксийг нэрлэсэн бүх газар нэгэн зэрэг хуучирна: маршрутууд, селекторууд, AllowedIPs, firewall дүрмүүд, DNS бичлэгүүд, шууд хаяг кодлосон аливаа хяналт. Мессежийн урсгал RFC 8415-д байна.
Префикс хөдөлнө гэж хүлээж байгаа газарт түүнээс хамааралгүй дотоод хаягийн төлөвлөгөөг хадгалж, хил дээр орчуул. NPTv6 бол төлөвгүй сонголт бөгөөд дотоод бодлогыг уншигдахуйц байлгадаг ч энэ нь префиксийн орчуулга, ид шидийн давхарга биш: /64 хилүүд таарах ёстой, шалгах нийлбэрүүд тохируулагдана, шууд хаяг агуулсан програмууд хэвээр эвдэрнэ. Үйлчилгээ үзүүлэгчийн хаягуудыг эхнээс эцэс хүртэл хадгалбал түрээсийн зан төлөв болон өөрчлөлтийн журмыг хаягийн төлөвлөгөөнд бич.
Цаг хугацааг тэсвэрлэх шалгалтаар дуусга: LAN бүрийн зөвшөөрөгдсөн хост нөгөө LAN-ын үйлчилгээнд хүрч, хариу туннелээр буцаж, туннель дахин эхлүүлэх болон дамжуулалт шинэчлэгдсэний дараа ч мөн тэр хос ажиллана. Хэрэв сүүлийн хэсэг бүтэлгүйтвэл загвар нь долоо хоног тэсэхгүй төлөвөөс хамаарна.