VPN ক্লায়েন্ট সংযোগ করে কিন্তু ইন্টারনেট নেই: তিনটি অনুপস্থিত অংশ

ক্লায়েন্ট একটি ঠিকানা পায়, সার্ভার ping-এর উত্তর দেয়, তবুও প্রতিটি পৃষ্ঠা সময় শেষে ব্যর্থ হয়। অধিকাংশ মানুষ এই পর্যায়ে ক্লায়েন্ট প্রোফাইল সম্পাদনা শুরু করে, যা সাধারণত বৃথা পরিশ্রম: টানেল চালু হয়ে গেলে সার্ভারকে রাউটারের মতো আচরণ করতে হয়। প্যাকেট বেরিয়ে উত্তর ফিরে আসার আগে তিনটি শর্ত একসঙ্গে পূরণ হতে হবে, আর কোনটি অনুপস্থিত থাকলেও লক্ষণ একই।

কেন কাজ করা টানেলেরও বাইরে যাওয়ার পথ থাকে না

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

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

তাই ক্লায়েন্ট নয়, তিনটি স্তর পরীক্ষা করুন এবং ফলাফলের অর্থ থাকার জন্য একবারে একটি বদলান।

ফরওয়ার্ডিং একটি কার্নেল সুইচ যা টিকিয়ে রাখতে হবে

পরিবর্তনের আগে বর্তমান মান দেখুন, তারপর সেট করুন এবং পরিবর্তন কার্যকর হয়েছে তা নিশ্চিত করুন।

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

প্রথম কমান্ড বর্তমান মান জানায়, দ্বিতীয়টি রানটাইমে সেট করে, আর তৃতীয়টি প্রমাণ করে লেখা কাজ করেছে। রানটাইম মান পরের রিবুটে হারিয়ে যায়, তাই কোনো কনফিগারেশন পরিবর্তন ছাড়াই রক্ষণাবেক্ষণের পরে কাজ করা সেশন ভেঙে যেতে পারে।

এটি /etc/sysctl.d/-এর অধীনে একটি ফাইলে স্থায়ী করুন, তারপর জানার জন্য রিবুট না করে সেই ফাইলটি প্রয়োগ করুন। FreeBSD-তে সমতুল্য হলো net.inet.ip.forwarding, স্থায়িত্বের জন্য rc.conf-এ gateway_enable=YES। যে ডিভাইস ফরওয়ার্ডিং বন্ধ বলে জানায়, সেটি «প্যাকেট আসে কিন্তু কিছুই ফেরে না» ধরনের পুরো এক শ্রেণির প্রতিবেদন ব্যাখ্যা করে। প্রতিটি আপগ্রেডের পরেও সেটিং দেখুন, কারণ নতুন করে বানানো কার্নেল বা বদলে দেওয়া ডিভাইস ইমেজ কাউকে না বলে এটি রিসেট করতে পারে।

masquerade বা একটি নির্দিষ্ট অনুবাদ ঠিকানা বেছে নিন

গতিশীল বাইরের ঠিকানা থাকলে masquerading সবচেয়ে সহজ সঠিক রূপ। টানেল সাবনেটকে উৎস আর বাইরের ইন্টারফেসকে প্রস্থান হিসেবে নাম দিন।

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

স্থির পাবলিক ঠিকানা থাকলে ঠিক সেই ঠিকানায় উৎস অনুবাদ বেশি অনুমানযোগ্য এবং নিরীক্ষা করা সহজ।

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

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

ফিল্টার টেবিল তৃতীয় দরজা

ফরওয়ার্ডিং ও অনুবাদ দুটোই ঠিক থাকতে পারে, তবুও প্যাকেট ফিল্টার টেবিলে মরে। ufw প্রায়ই দোষী: এর ফরওয়ার্ড নীতি DROP হিসেবে আসে, আর বাকি সেটআপ পুরোপুরি ঠিক দেখাতে পারে যদিও ওই একটি সেটিং ট্রাফিক মেরে ফেলে। এটি বাড়ানো চেকবক্স নয়, সচেতন নিরাপত্তা সিদ্ধান্ত।

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

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

পৃষ্ঠা কখনো লোড না হলে কোথায় দেখবেন

টানেল আছে প্রমাণ করতে সার্ভারের টানেল ঠিকানায় ping করুন। তারপর ক্লায়েন্ট থেকে পাবলিক ঠিকানায় traceroute চালিয়ে দেখুন কোথায় থামে: সার্ভারে প্যাকেট পৌঁছায় কিন্তু ফরওয়ার্ড বা অনুবাদ হয় না; সার্ভারের ওপারে সমস্যা আপস্ট্রিমে এবং আপনার হাতের বাইরে।

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

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

সার্ভারে ক্লায়েন্ট পৃষ্ঠা লোড করার সময় বাইরের ইন্টারফেস দেখুন। ব্যক্তিগত উৎস ঠিকানা নিয়ে বেরোনো ট্রাফিক মানে অনুবাদ অনুপস্থিত, আর কোনো উত্তর না মানে ফরওয়ার্ড পথ বা আপস্ট্রিম ফেরার রুট এটি ফেলে দিচ্ছে।

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