د سایټ-تر-سایټ VPN له لارې د IPv6 مختصرې ډیلیګیشن: د چیک لیست

تاله پورته کول اسانه نیمایي ده۔ ما یوه سایټ-تر-سایټ اړیکه لیدلې چې ورځې په همدې حال کې پاتې وه، خو د لېرې LAN هر کوربه یوازې چوپتیا ترلاسه کوله، ځکه چې د دې ګیټوې شاته ډیلیګیټ شوې مختصره په یوه انټرفیس کې تنظیم شوې وه خو هیڅکله تالې ته ورنګړل شوې نه وه۔ د تالې پتې ټول وخت د پنګ ځواب ورکاوه، او همدې لامل وه چې هیڅوک مختصرې ته نه کتل۔ دا هغه ترتیب دی چې زه یې ګورم کله چې ډیلیګیټ شوې IPv6 مختصره باید د سایټ VPN څخه تېره شي: د مختصرې نقشه، د ترافیک ټاکونکي، فوروارډینګ او فایر وال، او بیا د بیرته راستنېدو لار۔

له تالې سره د لاس وهلو مخکې د مختصرې نقشه ولیکه

د مختصرې ډیلیګیشن هغه روتېر ته یوه بلاک ورکوي چې غوښتنه یې کړې ده۔ دا په پیر کې روت نه نصبوي، هغه بلاک on-link نه پراخوي، او لېرې ګیټوې ته نه وایي چې د غوښتونکي روتېر شاته څه دي۔ دا درې شیان تاسو پخپله تنظیموئ، او باید د هر کانفګ فایل له بدلېدو مخکې په پتې پلان کې وي۔

د هر سایټ لپاره ډیلیګیټ شوې مختصره، هغه /64 چې په LAN کې واقعاً کارول کیږي، د تالې پتې او د هر روت مالک ولیکئ۔ چمتو کوونکی سایټ A ته 2001:db8:a1::/56 ډیلیګیټ کوي، چې په خپل LAN کې 2001:db8:a1:10::/64 برابروي؛ سایټ B 2001:db8:b2::/64 ساتي۔ که سایټ A یوازې همغه یوه /64 برابروي، دواړه څنډې باید 2001:db8:a1:10::/64 ونوموي نه ټوله /56۔

نږدې هر وخت دوه تېروتنې ښکاري۔ یوه دا چې لېره مختصره on-link وګڼل شي، بریج شي یا د تالې انټرفیس ته کېښودل شي، نو ګیټوې د هغو کوربه لپاره د ګاونډي غوښتنې ځواب ورکوي چې ورته نه رسیږي۔ بله دا چې ټوله /56 اعلان شي کله چې یوازې یوه /64 تنظیم شوې وي: روت جدول ادعا کوي چې بلاک د لاسرسي وړ دی او ډېری پتې په توره سوري کې لویږي۔

د دواړو څنډو د ترافیک ټاکونکي له روټونو سره سمون کړه

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=start

د سایټ B conn دواړه فرعي شبکې ښیي۔ کله چې سره سمون نه لري، ځواب ورکوونکی CHILD_SA له TS_UNACCEPTABLE سره ردوي، نو child SA هیڅکله نه پورته کیږي که څه هم IKE_SA پورته شو۔ په دواړو خواوو کې تنظیم شوې فرعي شبکه باید هغه څه سره برابره وي چې سیمه ییز کرنل تالې ته ورنګړي۔

WireGuard هماغه معلومات په AllowedIPs کې وړي، له یوې څرخې سره: AllowedIPs د ترلاسه کولو پر مهال د سرچینې فلټر او د لېږلو پر مهال روت دی۔ که د سایټ B د سایټ A لپاره peer ننوتنه 2001:db8:a1:10::/64 پرېږدي، د سایټ A پاکټونه په سم handshake راځي او د اجازې نشتوالي له امله غورځول کیږي۔ له دې څخه پیژندل شوی بڼه جوړیږي: handshake دوامداره نویږي خو ځواب هیڅکله نه وځي۔ دواړه څنډې له wg show wg0 allowed-ips سره پرتله کړه۔ هر وخت چې ډیلیګیشن بدلیږي هغه لیست بیا وګوره؛ زوړ /64 غونډه ژوندې ساتي او نوې مختصره نه لاسرسي وړ کوي۔

لومړی فوروارډینګ، فایر وال او MTU وباسه

له بله لاګ کرښې لوستلو مخکې تایید کړه چې ګیټوې په بشپړ ډول فوروارډ کوي۔ sysctl net.ipv6.conf.all.forwarding باید په دواړو کې 1 بیرته راوړي، په تالې او LAN انټرفیسونو هم پلي شي۔ یوه تله هم ملتیا کوي: کله چې فوروارډینګ فعال شي، accept_ra=1 لرونکی انټرفیس له چمتو کوونکي د روتېر اعلانونو منل بندوي، نو ماشین کېدای شي په تالې کې بشپړ روت کولو سره هم خپله پورتنۍ ډیفالټ لار له لاسه ورکړي۔ چېرې چې د چمتو کوونکي RA لا هم اړین دی هلته accept_ra=2 تنظیم کړه۔

بیا باید د فایر وال قواعد مختصره په دواړو لورو اجازه کړي، او 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 } accept

MTU د دې شاته دی۔ تاله د کارېدونکي MTU 1500 څخه ښکته کوي، او IPv6 غواړي چې هر لینک لږترلږه 1280 ووړي۔ وړوکي پنګ تېریږي، SSH غونډه په لویه چاودنه کې کنګلیږي، او /proc/net/snmp6 هغه packet-too-big پیغامونه ښیي چې هیڅکله نه راستنیږي۔ د تالې MTU په ښکاره ډول تنظیم کړه، یا په mangle جدول کې TCP MSS محدود کړه، او هغه ICMPv6 چې کوچنۍ MTU خبروي بیرته راتلو ته پرېږده۔

د تالې پته نه، د بیرته راستنېدو لار وآزمایه

تر ټولو ډېر وخت لګوي یو اړخیز روت دی۔ هر ګیټوې لېره مختصره تالې ته روت کوي، خو کوربه د خپل ډیفالټ ګیټوې له لارې ځواب ورکوي ځکه چې د هغوی /64 هم هلته دی۔ پاکټ هدف ته رسول د لارې نیمایي ده۔

دوه کمانډونه ډېره برخه حل کوي۔ په سایټ A کې ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 ښیي چې له هغې سرچینې ځواب کوم انټرفیس کاروي؛ په سایټ B کې آینې ته ورته وګوره۔ بیا له ګیټوې نه بلکې له کوربه څخه ترافیک جوړ کړه او د دواړو څنډو شمېرنې پرتله کړه۔

که د لېرې مختصرې لپاره ګاونډي غوښتنه په تالې ښکاره شي، هغه مختصره په یو ځای کې on-link ده چې نه باید وي؛ دا د روتونو د سمون مخکې سم کړه۔ Proxy NDP هغه حالات رانغاړي چې بریج ورته واقعاً اړین دی، د روت بدیل نه دی۔

د مختصرې د بدلېدو پلان ولره

د مختصرې ډیلیګیشن د ډیلیګیټ کوونکي او غوښتونکي روتېر ترمنځ کرایه ده، او نوی کول کېدای شي بل بلاک بیرته راوړي: د چمتو کوونکي له لېږد وروسته بله /56، یا له هغې مودې کمه کرایه چې تاله پورته ده۔ هره هغه ځای چې زړه مختصره نوموي یوځای زوړ کیږي: روټونه، ټاکونکي، AllowedIPs، د فایر وال قواعد، DNS ریکارډونه او هره هغه څارنه چې لفظي پتې هارډکوډ کوي۔ د پیغامونو بهیر په RFC 8415 کې دی۔

چېرې چې د مختصرې د خوځېدو تمه وي، یو داخلي پتې پلان وساته چې پرې تړلی نه وي او په پوله یې ژباړه کړه۔ NPTv6 بې حالته انتخاب دی او داخلي پالیسي لوستلو وړ ساتي، خو دا د مختصرې ژباړه ده، جادویي پوړ نه: /64 پولې باید سره سمون ولري، چک سامونه سمون کیږي، او هغه اپلیکیشنونه چې لفظي پتې لري لا هم ماتېږي۔ که د چمتو کوونکي پتې له سره تر سره وساتې، د کرایې چلند او د بدلون پروسه په پتې پلان کې ولیکه۔

د وخت سره مقاومت کوونکې ازموینې سره پای ته ورسوه: په هر LAN کې اجازه لرونکی کوربه بل LAN کې خدمت ته رسیږي، ځواب د تالې له لارې راستنیږي، او همغه جوړه د تالې له بیا پیل او ډیلیګیشن له نوي کېدو وروسته هم کار کوي۔ که وروستۍ برخه ناکامه شي، ډیزاین په هغه حالت تړلی دی چې اونۍ به ژوندی نه پاتې شي۔