VPN দিয়ে কেবল একটি ব্যক্তিগত সাবনেট কীভাবে পাঠাবেন

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

ডিজাইন ঠিক করার তিনটি শর্ত

প্রথমত, নেটওয়ার্কের মালিকের কাছ থেকে সঠিক প্রিফিক্স ও মাস্ক দরকার। 10.x নেটওয়ার্ক কোনো প্রিফিক্স নয়; 10.20.0.0/16 হলো প্রিফিক্স। নিশ্চিত করুন এটি আপনার হোম LAN, Docker ব্রিজ বা চালানো অন্য VPN-এর সাথে ওভারল্যাপ করে না, কারণ ওভারল্যাপ রুটটিকে দ্ব্যর্থক করে তোলে এবং কার্নেল আপনার না-চাওয়া এন্ট্রি বেছে নেয়।

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

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

WireGuard: AllowedIPs হলো রুট টেবিল

ক্লায়েন্টে AllowedIPs সেই গন্তব্যগুলো তালিকাভুক্ত করে যেগুলো টানেলে ঢুকতে পারে, এবং wg-quick প্রতিটি এন্ট্রিকে সাধারণ রুটে পরিণত করে। তাই এই কাজের ক্লায়েন্ট অর্ধেক এক লাইন।

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

এখন একই ক্লায়েন্টের জন্য সার্ভারের এন্ট্রির সাথে তুলনা করুন। এটি বর্ণনা করে সার্ভার ক্লায়েন্টকে কী পাঠাবে, যা সাধারণত ক্লায়েন্টের টানেল ঠিকানা, ব্যক্তিগত সাবনেট নয়।

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

এই দুটি একে অন্যের সাথে বদলানোই আমি সবচেয়ে বেশি দেখা ভুল। সার্ভারের peer অংশে 10.20.0.0/16 বসানো বোঝায় পুরো সাবনেটটি ওই ক্লায়েন্টের পেছনে অবস্থিত, যা অনুমতি নয় বরং সাইট-থেকে-সাইট দাবি। কোনো peer-এর AllowedIPs-এর সাথে না মেলা প্যাকেট নিঃশব্দে ফেলে দেওয়া হয়, তাই ভুল এন্ট্রি ঠিক ফায়ারওয়াল সমস্যার মতো দেখায়।

যদি রুট নিজেই পরিচালনা করেন, [Interface]-এর নিচে Table = off সেট করুন এবং যে রুট চান তা যোগ করুন। তখন স্বয়ংক্রিয়ভাবে কিছুই যোগ হয় না, তাই রুটটি ইন্টারফেস তোলার জিনিসের ভেতরেই থাকা উচিত।

OpenVPN: রুট পাঠান, তারপর নিশ্চিত করুন তা পৌঁছেছে

সাধারণ সার্ভারে পরিবর্তনটি সার্ভার কনফিগে ক্লায়েন্ট পুলের পাশে একটি নির্দেশ।

push "route 10.20.0.0 255.255.0.0"

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

পূর্ণ-টানেল সার্ভারের বিপরীতে সংকীর্ণ আচরণ দরকার এমন ক্লায়েন্টের কেবল যেসব অংশ চায় না সেগুলো উপেক্ষা করা উচিত। OpenVPN 2.4 ও পরের সংস্করণে pull-filter ঠিক এজন্য আছে।

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

ঠিকানা পরিবার আলাদা রাখুন: পাঠানো IPv4 রুট IPv6-এ রিজলভ হওয়া অভ্যন্তরীণ সেবার জন্য কিছুই করে না, এবং ওই সেবাটি টানেল দিয়ে ব্যর্থ হয়, অথচ বাকি সব ঠিক দেখায়।

যখন ব্যক্তিগত সাবনেট VPN সার্ভারে নয় বরং অন্য ক্লায়েন্টের পেছনে, তখন সার্ভারকে জানাতে হবে। client-config-dir-এর মাধ্যমে প্রতি ক্লায়েন্টের জন্য একটি ফাইল যোগ করুন যাতে থাকে iroute 10.20.0.0 255.255.0.0, সঙ্গে মিলে যাওয়া route যেন অন্য ক্লায়েন্টরা পথটি শেখে। iroute ছাড়া ওই নির্দিষ্ট টানেল দিয়ে ওই প্রিফিক্স পাঠানোর কোনো কারণ সার্ভারের নেই।

IPsec: ট্রাফিক সিলেক্টরগুলো একমত হতে হবে

IPsec-এ পাঠানোর কোনো রুট নেই। দুই প্রান্ত আলোচনা করে টানেলের ভেতরে কোন ঠিকানাগুলো থাকবে, আর সম্মত সিলেক্টরের বাইরের ট্রাফিক এনক্রিপ্ট হয় না এবং এর মধ্য দিয়ে পাঠানোও হয় না। strongSwan ক্লায়েন্টে সিলেক্টরগুলো স্পষ্টভাবে লেখা থাকে।

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

যদি গেটওয়ে দুই দিকেই 0.0.0.0/0 দিয়ে কনফিগার করা থাকে, তবে IKEv2 সংকোচন সাধারণত চাইল্ড SA-কে দুই প্রস্তাবের ছেদে নামিয়ে আনে, যা-ই আপনার চাওয়া ফল। কিছু গেটওয়ে বরং এমন প্রস্তাব প্রত্যাখ্যান করে যা তাদের কনফিগার করা সিলেক্টরের সাথে মেলে না, আর লগে তখন রাউটিং অভিযোগের বদলে ব্যর্থ চাইল্ড SA দেখায়। এমন হলে পরিবর্তনটি গেটওয়েতেই করতে হবে, কারণ ক্লায়েন্ট রুট এমন সিলেক্টরের জন্য টানেল বানাতে পারে না যা অপর প্রান্ত গ্রহণ করবে না।

Windows-এ বিল্ট-ইন ক্লায়েন্ট একই সিদ্ধান্ত দুটি সেটিংসের পেছনে লুকায়। স্প্লিট টানেলিং চালু থাকতে হবে, এবং প্রিফিক্সটি প্রোফাইলের সাথে নিবন্ধিত হতে হবে।

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

প্রিফিক্স নিবন্ধনই এটিকে পুনঃসংযোগের পরও টিকিয়ে রাখে, যা হাতে যোগ করা রুট করে না।

এন্ডপয়েন্ট ও DNS-কে সিদ্ধান্তের বাইরে রাখুন

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

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

যাচাই করুন, তারপর রিবুট করে আবার যাচাই করুন

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

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

প্রথম লাইন একটি ইন্টারফেসের নাম দেয়। যদি আপনার ফিজিক্যাল ইন্টারফেসের নাম দেয়, তবে রুট কখনো বসেনি। Windows-এ Find-NetRoute -RemoteIPAddress 10.20.5.7 একই প্রশ্নের উত্তর দেয়, আর শেষ পরীক্ষায় এখনও আপনার সাধারণ ঠিকানা দেখানো উচিত, VPN সার্ভারের নয়।

তারপর রিবুট করুন। হাতে যোগ করা রুট হারিয়ে যায়, অথচ প্রোফাইল, পাঠানো কনফিগ বা AllowedIPs থেকে আসা রুট ফিরে আসে। যদি সংকীর্ণ অ্যাক্সেস রিস্টার্টের আগে কাজ করে আর পরে ব্যর্থ হয়, তবে দোষ রুটে নয়, টানেল কীভাবে ওঠে তাতে।

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