ডুয়াল-স্ট্যাক VPN পুল: strongSwan-এ উভয় পরিবারকে ঠিকানা দেওয়া

একটি গেটওয়ে রোড ওয়ারিয়রকে একইসাথে IPv4 এবং IPv6 ভার্চুয়াল ঠিকানা দিতে পারে, যদিও বাইরের টানেল এখনও IPv4-এর উপর দিয়ে যায়। এগুলো স্বাধীন সিদ্ধান্ত, আর এগুলোকে একটি হিসেবে ধরে নেওয়াই সেই জায়গা যেখানে ডুয়াল-স্ট্যাক পরিকল্পনা সাধারণত ভেঙে পড়ে। ক্লায়েন্টের ভিতরের পরিবারগুলো, যে সুরক্ষিত প্রিফিক্সগুলোতে সে পৌঁছাতে পারে, এবং যে ট্রান্সপোর্ট এনক্যাপসুলেশন বহন করে — এই তিনটি আলাদা পছন্দ।

বেশিরভাগ বিভ্রান্তি আসে ডুয়াল স্ট্যাক শব্দটি এমন একটি ডিজাইনে প্রয়োগ করা থেকে যা কেবল এক জায়গায় ডুয়াল স্ট্যাক। একটি সার্ভিস ভিতরে ডুয়াল স্ট্যাক, তার বাইরের ঠিকানায় সিঙ্গেল স্ট্যাক হতে পারে, এবং তবুও ক্লায়েন্টদের জন্য পুরোপুরি ভালোভাবে কাজ করতে পারে। যা এটি করতে পারে না তা হলো দুর্ঘটনাক্রমে কাজ করা।

ভিতরে দুই পরিবার, বাইরে এক পথ

বাইরের সংযোগটি UDP-এর উপর IKE, এবং ক্লায়েন্ট যেখানেই থাকুক সেখান থেকে এর একটি নাগালের মধ্যে থাকা ঠিকানা পরিবার দরকার। ভিতরের IPv6 ঠিকানার জন্য IPv6-সক্ষম ISP দরকার হয় না, কারণ ভিতরের প্যাকেটটি বাইরের প্যাকেটের ভিতরের পেলোড। অনেক কার্যকর ডিপ্লয়মেন্ট IPv6 প্রিফিক্স কেবল-IPv4 আপলিংকের মধ্য দিয়ে বহন করে।

বাইরের পথটি যা সীমিত করে তা হলো নাগাল এবং NAT ট্রাভার্সাল। যদি গেটওয়ে কেবল একটি IPv4 ঠিকানা বিজ্ঞাপন করে, তবে কেবল-IPv6 নেটওয়ার্কের একটি ক্লায়েন্ট একেবারেই সংযোগ করতে পারবে না, আপনি যত পুলই কনফিগার করুন না কেন। আপনার ক্লায়েন্ট জনসংখ্যা থেকে বাইরের পরিবার নির্ধারণ করুন, ভিতরের ঠিকানা পরিকল্পনা থেকে নয়।

প্রতিটি পরিবারে ক্লায়েন্টকে একটি ঠিকানা দিন

উভয় পরিবারের জন্য অনুরোধ করা ক্লায়েন্টের দিকে এক লাইনের একটি বিবৃতি, শর্ত হলো গেটওয়ের দেওয়ার মতো কিছু থাকতে হবে। নামযুক্ত পুলগুলো উৎসগুলোকে সার্ভিস নেটওয়ার্ক থেকে আলাদা রাখে, এবং এই বৈশিষ্ট্যটিই ছয় মাস পরে ফায়ারওয়াল নিয়মগুলোকে পাঠযোগ্য রাখে।

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

এই vips মানটি প্রতিটি পরিবারের একটি ঠিকানা চায়, আর পুলের তালিকা নির্ধারণ করে সেই ঠিকানাগুলো কোথা থেকে আসবে।strongSwan-এর ভার্চুয়াল-IP ডকুমেন্টেশন একাধিক অনুরোধ এবং পুল বরাদ্দ কভার করে, যার মধ্যে এই বিষয়টিও আছে যে নির্দিষ্ট ঠিকানা চাওয়া ক্লায়েন্ট কেবল একটি পছন্দ প্রকাশ করে, যা উত্তরদাতা বাতিল করতে পারে। এমন কোনো অ্যাক্সেস নিয়ম তৈরি করবেন না যা ধরে নেয় ক্লায়েন্ট সবসময় একই মান পায়।

নমুনাটি কপি না করে নিজের একটি অনন্য-লোকাল প্রিফিক্স তৈরি করুন। যে দুটি প্রতিষ্ঠান উভয়েই fd42::/16 স্থাপন করে, তারা প্রথমবার পরস্পরের সাথে সংযুক্ত হওয়ার সময় সংঘর্ষটি আবিষ্কার করবে, আর এটি নির্ণয় করা অপ্রীতিকর।

সিলেক্টরগুলো গন্তব্য বর্ণনা করে, উৎস নয়

চাইল্ড SA-এর লোকাল ট্রাফিক সিলেক্টর বলে দেয় গেটওয়ের পেছনে কোন সুরক্ষিত নেটওয়ার্কগুলো আছে, আর রিমোট সিলেক্টর বর্ণনা করে ক্লায়েন্ট উৎস হিসেবে কী ব্যবহার করতে পারে। একটি ভার্চুয়াল পুল ঠিকানা সেই নীতির উৎসের দিকে থাকে; এটিকে গন্তব্যের তালিকায় রাখা কনফিগারেশনের একটি সাধারণ ভুল পাঠ।

উভয় পরিবারেরই ফেরত মার্গরুট এবং গেটওয়েতে অনুমোদিত ফরওয়ার্ডিং দরকার। পুলে ফেরার রুট ছাড়া সিলেক্টরে একটি প্রিফিক্স যোগ করলে এমন একটি টানেল তৈরি হয় যা প্রতিষ্ঠিত হয়, এক দিকের ট্রাফিক পার করে, এবং নীরবে উত্তরটি ফেলে দেয়। সিলেক্টর হলো নীতি, রাউটিং নয়।

পুলগুলো এবং সার্ভিস প্রিফিক্সগুলোকে আপনার ঠিকানা পরিকল্পনার আলাদা ব্লকে রাখুন। যখন তারা ওভারল্যাপ করে, একটি সুরক্ষিত হোস্টে পৌঁছানোর কথা থাকা একটি রুট পুলের ঠিকানার সাথে মিলে টানেলের ভিতরে হারিয়ে যেতে পারে।

DNS এবং উত্তর পথই ঠিক করে এটি সম্পূর্ণ মনে হয় কি না

রিজলভারের উত্তরগুলো রিজলভারে পৌঁছাতে ব্যবহৃত ট্রান্সপোর্ট থেকে স্বাধীন। একটি নাম A রেকর্ড, AAAA রেকর্ড বা দুটোই ফেরত দিতে পারে, আর ক্লায়েন্ট নিজের পছন্দের নিয়ম অনুযায়ী বেছে নেয়। যদি কোনো অভ্যন্তরীণ সার্ভিস AAAA রেকর্ড প্রকাশ করে কিন্তু সেই প্রিফিক্সে কিছুই রুট না হয়, ডুয়াল-স্ট্যাক নেটওয়ার্কের ক্লায়েন্টরা প্রথমে IPv6 পথটি চেষ্টা করবে এবং ব্যর্থ না হওয়া পর্যন্ত সেখানেই বসে থাকবে। তখন টানেল কনফিগারেশনে কিছুই ভুল দেখায় না।

তাই প্রতি নামের জন্য ঠিক করুন কোন পরিবারগুলো ব্যবহারযোগ্য হওয়া উচিত, তারপর যাচাই করুন যে সংশ্লিষ্ট প্রিফিক্সটি সিলেক্টরে আছে এবং এর একটি ফেরত রুট আছে। এটি সার্ভিসভিত্তিক সিদ্ধান্ত। উভয় ধরনের রেকর্ড ব্যাপকভাবে প্রকাশ করাই হলো সেই উপায় যাতে একটি কার্যকর কেবল-IPv4 সার্ভিস তার অর্ধেক ব্যবহারকারীর জন্য টাইমআউট হতে শুরু করে।

এটিকে সম্পন্ন বলার আগে উভয় পরিবার যাচাই করুন

যে কনফিগারেশন লোড হয় তা যে কনফিগারেশন কাজ করে তা নয়। ডেমন যে অবস্থা রিপোর্ট করে তা পড়ুন, পুল বরাদ্দ নিশ্চিত করুন, তারপর ক্লায়েন্ট আসলে যে রুটগুলো ইনস্টল করেছে তা দেখুন।

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

প্রথম দুটি কমান্ড প্রতিষ্ঠিত চাইল্ড SA এবং কোন পুলে এখনও ঠিকানা আছে তা দেখায়, ফলে যে পরিকল্পনা প্রথম ক্লায়েন্টের জন্য কাজ করে কিন্তু দশমটির জন্য ব্যর্থ হয় তা দৃশ্যমান হয়। শেষ দুটি দেখায় ক্লায়েন্ট পুল থেকে গ্লোবাল IPv6 ঠিকানা পেয়েছে কি না এবং কোনো সুরক্ষিত প্রিফিক্সে ট্রাফিক আসলে কোথায় যাবে। বরাদ্দ করা ঠিকানাটিকে আপনার কনফিগার করা পুলের সাথে তুলনা করুন, আপনি যে ঠিকানার আশা করেছিলেন তার সাথে নয়। যদি উত্তরদাতা তার নীতির অধীনে ভিন্ন মান বেছে নেয়, রুট এবং ফায়ারওয়াল নিয়মগুলোকে এখনও তার বেছে নেওয়া মানের সাথে মিলতে হবে।

তারপর প্রতিটি পরিবারের জন্য একটি সুরক্ষিত হোস্ট পরীক্ষা করুন, এবং এমন একটি নাম পরীক্ষা করুন যা দুটোতেই রিজলভ হয়। একক-পরিবারের পরীক্ষা আপনার অনুশীলন না করা অর্ধেক পরিকল্পনা সম্পর্কে কিছুই বলে না, আর সেই অর্ধেকেই সাধারণত অনুপস্থিত রুটটি থাকে।