টানেল চালু, ইন্টারনেট নেই: ফরওয়ার্ডিং কোথায় থামে

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

যাচাই করুন ইন্টারনেট নির্গমন আদৌ নকশা ছিল কি না

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

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

একটি সার্বজনীন অনুরোধ অনুসরণ করুন

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

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

গেটওয়ে যদি প্যাকেট কখনো না দেখে, তবে ক্লায়েন্ট রুট বা টানেল নির্বাচন ভুল। যদি প্যাকেট এসে না বেরোয়, সমস্যা গেটওয়েতে, এবং বাকি তিনটি পরীক্ষা প্রযোজ্য।

ফরওয়ার্ডিং, রুট ও অনুবাদ পরীক্ষা করুন

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

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

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

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

উত্তর পথ ও রিজলভার দুটি ভিন্ন উত্তর

শুধু অনুরোধ নয়, উত্তরের দিকেও নজর রাখুন। যদি অনুরোধ অনূদিত হয়ে বেরোয় এবং উত্তর অনূদিত প্রবাহে ফেরে, তবে ফরওয়ার্ডিং কাজ করে এমনকি অ্যাপটি তখনো ব্যর্থ হলেও, এবং পরবর্তী তদন্ত অ্যাপ বা DNS-এর।

যে সাইট HTTP ত্রুটি ফেরায় তা প্রমাণ যে ইন্টারনেটে ফরওয়ার্ডিং কাজ করে। যে নাম সমাধান হয় না অথচ ঠিকানা দিয়ে প্রবেশ কাজ করে, তা রিজলভারের সমস্যা, NAT-এর নয়।

সুনির্দিষ্ট সংশোধনের পর ক্লায়েন্ট এবং ইচ্ছাকৃতভাবে সীমিত যেকোনো ব্যক্তিগত সম্পদ আবার পরীক্ষা করুন। ইন্টারনেট প্রবেশাধিকার দেওয়া গেটওয়েতে যুক্ত প্রতিটি নেটওয়ার্কে প্রবেশাধিকার নিঃশব্দে বাড়ানো উচিত নয়।