strongSwan EAP: IKE পরিচয় বনাম প্রত্যাশিত AAA নাম

একটি strongSwan EAP ক্লায়েন্ট দুটি সার্ভার নাম যাচাই করতে পারে। remote.id IKE গেটওয়ে ঢাকে এবং local.aaa_id EAP সার্ভার ঢাকে; এরা একটিমাত্র ফিল্ড নয়।

IKEv2-এর উপর EAP প্রমাণীকরণ একটি সংযোগের মধ্যে দুটি ভিন্ন সার্ভার নাম যাচাই করতে ক্লায়েন্টকে বলতে পারে। যে গেটওয়ে IKE সমাপ্ত করে সে একটি পরিচয় উপস্থাপন করে, আর ভেতরের TLS বিনিময় সমাপ্ত করা EAP ব্যাকএন্ড অন্য একটি পরিচয় উপস্থাপন করতে পারে। strongSwan-এ এরা ভিন্ন কনফিগারেশন ব্লকে থাকে, আর ভুল ব্লকে নাম বসালে এমন ব্যর্থতা হয় যা সার্টিফিকেট সমস্যার মতো দেখায়। কোন যাচাই ব্যর্থ হয়েছে তা পড়াই আপনাকে বলে কোন ব্লক সম্পাদনা করতে হবে।

এক সংযোগ, দুটি সার্ভার পরিচয়

প্রথম পরিচয়টি IKE বিনিময়ের। ক্লায়েন্ট একটি ঠিকানায় ডায়াল করে এবং প্রত্যাশা করে যে প্রতিপক্ষ একটি নির্দিষ্ট পরিচয় প্রমাণ করবে, সাধারণত গেটওয়ে সার্টিফিকেটের নাম।

দ্বিতীয়টি EAP-এর। PEAP বা TTLS-এর সঙ্গে ক্লায়েন্ট IKE SA-এর ভেতরে প্রমাণীকরণ সার্ভারের কাছে একটি TLS টানেল তৈরি করে, এবং সেই ভেতরের সার্ভার নিজের সার্টিফিকেট উপস্থাপন করে। ব্যাকএন্ড আলাদা হোস্ট হলে তার নাম গেটওয়ের নাম থেকে আলাদা হয়। যে ক্লায়েন্ট কেবল প্রথম নামটি দেখে সে দ্বিতীয়টি যা দাবি করে তা-ই গ্রহণ করে। আর দুই জায়গায় একই নাম দিয়ে কনফিগার করা ক্লায়েন্ট দুটি সত্যিই আলাদা হলেই ব্যর্থ হয়।

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

কোন ফিল্ড কোন স্তরের

swanctl-এ ঠিকানা ও IKE পরিচয় আলাদা সেটিং, আর EAP পরিচয় তৃতীয়টি।

রিমোট ঠিকানা ঠিক করে প্যাকেট কোথায় যাবে, আর রিমোট পরিচয় বলে প্রতিপক্ষকে কী প্রমাণ করতে হবে। EAP প্রত্যাশাটি local ব্লকের নিচে লেখা হয়, কারণ এটি প্রতিপক্ষের IKE আচরণ নয়, এই ক্লায়েন্টের EAP বিনিময় বর্ণনা করে। এই স্থাপনাটাই মানুষ ভুল পড়ে। নামটি ক্লায়েন্টের কনফিগারেশনে বসে থেকেও একটি সার্ভার বর্ণনা করে, আর ঠিক এজন্যই এটি ভুল জায়গায় মনে হয়।

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

এই অংশটি পূর্ণ সংযোগ নয়; ট্রাস্ট উপাদান, ক্রেডেনশিয়াল ও চাইল্ড নীতি এখনও থাকতে হবে। এটি হুবহু একটি কার্যকর ফাইলে কপি করলে আপনার এখনও প্রয়োজনীয় সেটিংস প্রতিস্থাপিত হবে।

কেন aaa_id local-এর নিচে থাকে

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

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

মানটি ব্যাকএন্ড সার্টিফিকেট সত্যিই যা দাবি করে তার সঙ্গে অভিন্ন রাখুন, নামের রূপ সহ। শেষে একটি বিন্দু বা হোস্টটি না ঢাকা ওয়াইল্ডকার্ড যাচাই ব্যর্থ হওয়ার জন্য যথেষ্ট।

যে ফ্রন্টএন্ড বিভাজনটি প্রকাশ করতে পারে না

NetworkManager প্রোফাইল swanctl-এর মতো একই কনফিগারেশন ইন্টারফেস নয়। এর পিছনের প্লাগইন পরিচয় নিয়ন্ত্রণের একটি সংকীর্ণ সেট প্রকাশ করে, আর কোনগুলো আছে তা ইনস্টল করা সংস্করণের উপর নির্ভর করে।

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

বিকল্পটি ক্লায়েন্টে উদ্ভাবন করার মতো কিছু নয়। সমর্থিত ব্যবস্থাটি লিখিতভাবে চান, তারপর সেই উত্তরটি প্রোফাইলের সঙ্গে রাখুন।

পরিচয়ের অমিলকে মেয়াদোত্তীর্ণ সার্টিফিকেট থেকে আলাদা করুন

নামের অমিল ও মেয়াদোত্তীর্ণ সার্টিফিকেট ভিন্ন ব্যর্থতা, এবং লগ তাদের আলাদা করে। কোন ফিল্ড বদলাবেন তা ঠিক করার আগে বার্তাটি পড়ুন।

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

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

সম্পর্কিত নিবন্ধ