একাধিক সাবনেটের IPsec ফেরত ট্রাফিক হারাচ্ছে? reqid গুনুন
একাধিক সাবনেটের টানেলে একমুখী ট্রাফিক সাধারণত নীতি ও reqid-এর অসঙ্গতি, এনক্রিপশন বা রাউটিংয়ের নয়। xfrm ডেটাবেসগুলো ক্রমে পড়ুন।
ট্রাফিক এক সাইট ছেড়ে যায় এবং কখনও ফেরে না, উভয় গেটওয়ে সম্পূর্ণ হওয়া দরকষাকষির প্রতিবেদন করে, এবং একমাত্র সূত্র হলো উত্তরহীন বহির্গামী প্যাকেটের স্তূপ। লিনাক্স এন্ডপয়েন্টে সাধারণ কারণ এনক্রিপশনের শক্তি, MTU বা রাউটিং টেবিল নয়। এটি নীতি এন্ট্রিগুলোর সূক্ষ্মতা এবং যে সংখ্যা প্রতিটি নীতিকে একটি নিরাপত্তা সংযোগের সঙ্গে যুক্ত করে। নিচের পদ্ধতিটি অন্য কিছু স্পর্শ করার আগে ওই দুটি ডেটাবেস পড়ে।
কিছু বদলানোর আগে লক্ষণটি আলাদা করুন
সম্পূর্ণ IKE দরকষাকষিসহ একমুখী ব্যর্থতা সমস্যাটিকে ডেটা পথে সীমিত করে। হয় বহির্গামী নীতি মিলেছিল এবং উত্তর ফেলে দেওয়া হয়েছিল, নয়তো উত্তর কখনও পৌঁছায়নি কারণ অপর পক্ষের পাঠানোর কিছু ছিল না। একটি অ্যাপ্লিকেশন থেকে দুটোই একই রকম দেখায়, এবং xfrm ডেটাবেস তাদের আলাদা করে।
MTU দিয়ে শুরু করবেন না। ভুল MTU থামা ও খণ্ডনের লক্ষণ তৈরি করে, ক্রমবর্ধমান বহির্গামী কাউন্টারসহ পরিচ্ছন্ন দিক বিভাজন নয়।
নীতি ডেটাবেস ও অবস্থা ডেটাবেস পড়ুন
লিনাক্সে এনক্রিপশন নির্ধারণ করে নীতি এন্ট্রি, তাই মিলে যাওয়া নীতি, রুট নয়, প্যাকেটকে টানেলে ঢোকায়। ip xfrm policy চালান যাতে প্রতিটি এন্ট্রির সিলেক্টর, দিক, অগ্রাধিকার ও টেমপ্লেট দেখতে পারেন, এবং ip xfrm state যাতে প্রতিষ্ঠিত সংযোগগুলো তাদের reqid সহ দেখতে পারেন। নীতি ও সংযোগ ওই reqid দ্বারা যুক্ত হয়।
তিনটি দিকই দেখুন। বহির্গামী ও অন্তর্গামী এই হোস্টে ও এখান থেকে ট্রাফিক কভার করে; অগ্রগামী দিক তখন গুরুত্বপূর্ণ যখন হোস্ট অন্যদের জন্য রাউট করে। এক দিকে অনুপস্থিত বা অমিল এন্ট্রি কোনো ক্রিপ্টোগ্রাফিক ত্রুটি ছাড়াই একমুখী ফলাফল ব্যাখ্যা করে।
চিরায়ত অসামঞ্জস্য: একাধিক সাবনেটের জন্য এক reqid
একটি সাধারণ ব্যর্থতা আসে এমন সহকর্মীর কাছ থেকে যে সব দরকষাকষিকৃত সাবনেটের নীতি এক reqid-এর অধীনে স্থাপন করে, যা racoon-এর generate_policy require এর সঙ্গে ঘটে। ট্রাফিক তখন সর্বশেষে প্রতিষ্ঠিত সংযোগ দিয়ে বেরোয়, অপর পক্ষ প্রতিটি সাবনেটের জন্য আলাদা সংযোগ রাখে। উত্তর আসে এমন সংযোগে যার reqid সেই নীতিটি চিহ্নিত করে না যার তাদের গ্রহণ করা উচিত ছিল, এবং কার্নেল ডিক্রিপশনের পর সেগুলো ফেলে দেয়।
সমাধান একটি কনফিগারেশন পরিবর্তন, ফায়ারওয়াল নিয়ম নয়: generate_policy unique; প্রতিটি নীতিকে তার নিজস্ব reqid দেয়, ফলে সহকর্মীর প্রতি-নীতি সংযোগগুলোর মিলে যাওয়া সঙ্গী থাকে। এটি প্রয়োগ করুন, আবার দরকষাকষি করুন, এবং সফলতা ঘোষণার আগে প্রত্যাশিত সাবনেটের আলাদা reqid গুনুন।
যদি দুটি সাবনেট এখনও একটি reqid ভাগ করে আর অপর পক্ষ দুটি প্রত্যাশা করে, আপনি অসামঞ্জস্য খুঁজে পেয়েছেন। ম্যাপিংটি লিখে রাখুন, কারণ এটিই প্রমাণ যে পরের পরিবর্তন তা ঠিক করেছে বা ধরে রেখেছে।
সিলেক্টর আসে দরকষাকষি থেকে, আপনার কনফিগারেশন থেকে নয়
সুরক্ষিত পরিসর হলো যা উভয় প্রান্তে সম্মত হয়েছে, এক পক্ষ যা চেয়েছে তা নয়। যে ক্লায়েন্ট প্রশস্ত দূরবর্তী পরিসরের বিপরীতে হোস্ট-জোড়া প্রস্তাব করে সে গেটওয়ের সংকুচিত সংস্করণ পায়, এবং ক্লায়েন্ট তা প্রশস্ত করতে পারে না। ইনস্টল করা সিলেক্টর পড়ুন, আপনার স্থানীয় ফাইলেরগুলো নয়।
যখন লক্ষ্য বিপরীত, অর্থাৎ একটি গন্তব্যকে টানেলের বাইরে রাখা, তখন কম অগ্রাধিকার সংখ্যার বাইপাস নীতি যোগ করুন যাতে তা স্বয়ংক্রিয়ভাবে ইনস্টল করা এন্ট্রিকে হারিয়ে দেয়। টেমপ্লেটহীন নীতি সাধারণ লেখা অনুমোদন করে, যা এটিকে পরিবর্তন রেকর্ডের জন্য সচেতন ব্যতিক্রম করে তোলে, ডিবাগিং পদক্ষেপ নয়।
এই ক্রমে যাচাই করুন, এবং জানুন কীভাবে পিছিয়ে যেতে হয়
প্রতিটি সাবনেটের জন্য দুই দিকে নীতি তালিকাভুক্ত করুন, হোস্ট রাউট করলে অগ্রগামী দিকসহ। আলাদা reqid গুনুন এবং প্রত্যাশাকারী পক্ষে প্রতি নীতিতে একটি করে নিশ্চিত করুন। ইনস্টল করা সিলেক্টরের সঙ্গে দরকষাকষিকৃতগুলোর তুলনা করুন। কী নবায়নের পর প্রতি-সংযোগ কাউন্টার আবার পড়ুন, কারণ আপনি যে সংযোগ পরীক্ষা করেছেন তা ইতিমধ্যে চলে যেতে পারে। রুট সবার শেষে যাচাই করুন, কারণ দূরবর্তী সাবনেটে অনুপস্থিত রুট পরিচ্ছন্ন নীতি কাউন্টারসহ অনুরূপ একমুখী লক্ষণ তৈরি করে।
সহকর্মী বদলানোর আগে দুই xfrm কমান্ডের বর্তমান আউটপুট সংরক্ষণ করুন। যদি নতুন সেটিং ফেরার দিক পুনরুদ্ধার না করে, ওই আউটপুট পুনরুদ্ধার করা স্মৃতি থেকে টানেল পুনর্নির্মাণের চেয়ে দ্রুত ফেরানো, এবং তুলনাটি সৎ রাখে।