L2TP/IPsec একটি নেটওয়ার্কে সংযুক্ত হয় আর অন্যটিতে সময় শেষ হয়ে যায়

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

নেটওয়ার্ক তুলনার আগে ক্লায়েন্ট নির্ধারণ করুন

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

প্রথমে ব্যর্থ নেটওয়ার্কে সাধারণ ইন্টারনেট প্রবেশ নিশ্চিত করুন, থাকলে অতিথি পোর্টালসহ। কখনও পূরণ না হওয়া পোর্টাল ফিল্টার করা টানেলের মতো দেখতে সময়-সমাপ্তি তৈরি করে, এবং সেই যাচাই এক মিনিট নেয়।

চার ধাপ, চার ভিন্ন ত্রুটি বার্তা

L2TP/IPsec সংযোগ চার ধাপ অতিক্রম করে, এবং RFC 3193 সেই বিন্যাস বর্ণনা করে যা প্রথম দুটিকে বাঁধে। IKE আলোচনা সেই জায়গা যেখানে ফিল্টার করা পথ নীরব সময়-সমাপ্তি তৈরি করে। IPsec প্রমাণীকরণ সেই জায়গা যেখানে সার্টিফিকেট বা পূর্বে ভাগ করা কী-এর অমিল বরং স্পষ্ট প্রত্যাখ্যান তৈরি করে। L2TP টানেল স্থাপন সেই জায়গা যেখানে আগে থেকেই প্রতিষ্ঠিত নিরাপত্তা সংঘ তবুও কোথাও নিয়ে যেতে পারে না, আর PPP লগইন সেই জায়গা যেখানে ভুল শংসাপত্র অবশেষে দৃশ্যমান ব্যর্থতা তৈরি করে। যে ধাপ থেমেছিল তার লগ পড়ুন, শেষ মুদ্রিত লাইনের নয়।

journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10

strongSwan-এর লগ দেখায় IKE বিনিময় কোনো প্রস্তাবে পৌঁছেছে কি না এবং প্রতিপক্ষ আদৌ উত্তর দিয়েছে কি না, যা নাগালকে নীতি থেকে আলাদা করে। xl2tpd-এর লগ যেখানে IPsec শেষ হয় সেখান থেকে চলতে থাকে, তাই সেই লগে কিছু না থাকা প্রতিষ্ঠিত নিরাপত্তা সংঘ L2TP ধাপের দিকে ইঙ্গিত করে। রুট প্রশ্ন নিশ্চিত করে যে ক্লায়েন্ট আপনার ধারণা করা সার্ভার ঠিকানার দিকে পাঠাচ্ছে, এবং এটি আগের নেটওয়ার্ক থেকে উত্তরাধিকারসূত্রে পাওয়া পুরোনো DNS উত্তর ধরে ফেলে। একসঙ্গে, তিনটি আউটপুট উপসর্গের বদলে ধাপের নাম বলে।

NAT-এর গভীরতা এবং সহায়কের আচরণ তুলনা করুন

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

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

বহির্গামী ক্লায়েন্ট, অন্তর্গামী সার্ভার: দুটি ভিন্ন সমস্যা

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

সমর্থিত পরিবর্তনের পরে একই সংযোগ পুনরাবৃত্তি করুন এবং পৌঁছানো ধাপ লিখে রাখুন। কাজ করা প্রোফাইল এবং ব্যর্থ নেটওয়ার্কের নোট একসঙ্গে রাখুন, আর শংসাপত্র রিসেট করবেন না এবং ক্লায়েন্ট পুনঃস্থাপন করবেন না, কারণ এতে যে প্রমাণের ওপর তুলনা গড়ে উঠেছিল তা ফেলে দেওয়া হয়।