হোম রাউটারে IPsec পাস-থ্রু: এটি আসলে যা করে
সুইচটি একটি প্রোটোকলকে ঠিকানা অনুবাদের মধ্য দিয়ে এগিয়ে দেয়; এটি রাউটারকে ক্লায়েন্ট হিসেবে নথিভুক্ত করে না। বিনিময়টি ধারণ করুন, অ্যাসোসিয়েশনগুলো পড়ুন, তারপর সিদ্ধান্ত নিন।
রাউটারের পাস-থ্রু সুইচগুলো তাদের পেছনের একটি ডিভাইসের জন্য ফরোয়ার্ডিং ছাড়, VPN সেবা নয়। এগুলো রাউটারকে ক্লায়েন্ট হিসেবে নথিভুক্ত করে না, প্রমাণপত্র ধরে রাখে না, আর বাড়ির প্রতিটি যন্ত্রকে দূরবর্তী প্রস্থান দিয়ে পাঠায় না। এগুলো যা করে তা হলো, একটি প্রোটোকল কীভাবে ঠিকানা অনুবাদ ও ফিল্টার অতিক্রম করে তা নির্ধারণ করে। এটি স্পষ্ট হলে সুইচটি পরীক্ষা করাও সহজ, বন্ধ রাখাও সহজ।
রাউটার আসলে যা করছে
রাউটারটি একটি ক্লায়েন্ট ও একটি IPsec সহকর্মীর মাঝে বসে থাকে এবং এমন প্যাকেট ফরোয়ার্ড করে যা বোঝার জন্য এটি কখনোই তৈরি হয়নি। প্রস্তুতকারকেরা বৈশিষ্ট্যটি অন্তত তিনভাবে বাস্তবায়ন করে: একটি প্রোটোকল হেল্পার যা অবস্থা অনুসরণ বা পুনর্লিখন করে, একটি ফিল্টার ব্যতিক্রম যা ESP বাদ দেওয়া থামায়, অথবা পুরোনো ক্লায়েন্টের জন্য একটি সামঞ্জস্য মোড। ওয়েব ইন্টারফেসের লেবেল খুব কমই বলে আপনার কাছে তিনটির কোনটি আছে। কেবল ফার্মওয়্যার নোট বা প্যাকেট ক্যাপচারই তা বলবে।
হেল্পার বিষয়টি আরও খারাপও করতে পারে। পুরোনো প্রবাহের জন্য লেখা সহায়তা কখনো এমন ক্লায়েন্টের সাথে হস্তক্ষেপ করে যা ইতিমধ্যে অনুবাদ সঠিকভাবে সামলায়। যখন একটি আধুনিক ক্লায়েন্ট অপশন বন্ধ রেখে কাজ করে, তখন এটি বন্ধ রাখাই ভালো কনফিগারেশন।
পাস-থ্রু কখনো রাউটারকে সহকর্মীদের চাবি দেয় না। এটি এখনও বাইরের ঠিকানা ও পোর্ট দেখে, এবং এখনও সেগুলোর উপর নিজের ফরোয়ার্ডিং নীতি প্রয়োগ করে।
NAT আর NAT-T পথ নির্ধারণ করে
IPsec ঠিকানা অনুবাদ টিকিয়ে রাখার জন্য তৈরি হয়নি, তাই মানগুলো একটি মোড়ক যোগ করেছে। NAT ট্রাভার্সাল ESP-কে UDP-এর ভেতরে আবদ্ধ করে, যাতে একটি সাধারণ NAT টেবিল প্রবাহ বহন করতে পারে, এবং আলোচনা IKE-এর সময় সেই পরিবর্তনে সম্মত হয় (RFC 3948)। IKE নিজেই UDP 500 ব্যবহার করে, আর আবদ্ধ পথ সাধারণত UDP 4500 ব্যবহার করে।
তাই কেবল প্রোটোকল 50 অনুমোদনকারী ফায়ারওয়াল নিয়ম অনূদিত পথে যথেষ্ট নয়। 4500 ব্লক করলে যে ক্ষেত্রটির জন্য মোড়কটি আছে সেটি ভেঙে যায়, আর 500 ব্লক করলে কোনো টানেল গড়ার আগেই আলোচনা থেমে যায়। দুই দিকই গুরুত্বপূর্ণ, কারণ অবস্থা-সচেতন রাউটার সাধারণত অনুরোধ দেখার পরেই উত্তর অনুমোদন করে। একটি পোর্টে পৌঁছানো মানে প্রমাণীকরণ শেষ করা নয়, আর সুরক্ষিত ট্রাফিক ফরোয়ার্ড করাও নয়।
পুরোনো ব্যবস্থাগুলো যথেষ্ট আলাদা, তাই সেগুলোর জন্য লেখা নির্দেশিকা বিভ্রান্ত করতে পারে। যখন একটি ক্লায়েন্ট দুই মোডই অফার করে, তখন বেশি সার্চ ফলাফলওয়ালাটি নয়, আপনার সহকর্মী যে মোডটি নথিভুক্ত করেছে সেটিই পরীক্ষা করুন।
ব্যর্থ ধাপটি খুঁজুন
সমস্যাটিকে আলোচনা, প্রমাণীকরণ, চাইল্ড সুরক্ষা ও ভেতরের ফরোয়ার্ডিংয়ে ভাগ করুন, তারপর একবারে একটি ধাপের প্রমাণ সংগ্রহ করুন। যে রিবুট ফলাফল সাময়িকভাবে বদলে দেয়, তা কেবল প্রমাণ করে কিছু অবস্থা জড়িত ছিল।
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
ip xfrm state list
ip xfrm policy list
ক্যাপচার দেখায় বিনিময়টি সহকর্মীর কাছে পৌঁছায় কি না এবং উত্তর ফিরে আসে কি না, যা ফিল্টার সমস্যাকে প্রমাণপত্র সমস্যা থেকে আলাদা করে। অবস্থার তালিকা প্রতিষ্ঠিত নিরাপত্তা অ্যাসোসিয়েশন দেখায়, তাই চেষ্টার পর খালি তালিকা রাউটিংয়ের বদলে আলোচনার দিকে ইঙ্গিত করে। নীতির তালিকা দেখায় কোন সিলেক্টরগুলো ইনস্টল করা আছে, আর ঠিক সেখানেই সাবনেটের বাইরের গন্তব্য বাদ পড়ে। রাউটার স্পর্শ করার আগে xfrm-এর দুই আউটপুটই পড়ুন, কারণ তারা রাউটার কী অনুমোদন করে তা নয়, হোস্ট কী মনে করে তা বর্ণনা করে।
যদি প্যাকেট বেরিয়ে যায় আর কিছু ফিরে না আসে, ক্যাপচারটি রাউটারের WAN দিকে সরান। দুই ক্যাপচার তুলনা করলে অনুমান ছাড়াই ফেলে দেওয়ার জায়গাটি চিহ্নিত হয়।
যেটি দরকার নেই সেটি বন্ধ করুন
একটি কাজ করা ল্যাপটপ প্রমাণ করে না যে রাউটার একসাথে কয়েকটি ক্লায়েন্ট সামলায়। প্রতিটি ক্লায়েন্ট নিজের অনুবাদ অবস্থা ও নিজের আলোচনা তৈরি করে, আর কিছু হেল্পার কেবল একটি প্রবাহ অনুসরণ করে। আপনি সত্যিই যে নেটওয়ার্ক ব্যবহার করেন সেগুলো থেকে, আপনার সত্যিই যে সংখ্যক একসাথে সেশন দরকার সেটি পরীক্ষা করুন। যদি দ্বিতীয় ক্লায়েন্ট ব্যর্থ হয় আর প্রথমটি ভালো চলে, সেটাই ফলাফল, কোনো অস্থির টানেল নয়।
ক্যাপচার দেখালে তবেই অপশনটি চালু রাখুন যে এটি দরকার। ফলাফলের পাশে ফার্মওয়্যার সংস্করণ লিখে রাখুন, কারণ এই আচরণগুলো রিলিজের মধ্যে বদলায়। লক্ষ্য হলো আপনি যাচাই করা একটি ক্লায়েন্ট টানেল, আশা নিয়ে চালু করা একটি সুইচ নয়।