OpenVPN ক্লায়েন্টের tunnel ঠিকানায় ping করা যায়, তবুও তার পেছনের LAN-এ কোনো হোস্টে পৌঁছানো যায় না। Access Server ক্লায়েন্টকে VPN pool থেকে ঠিকানা দেয়, আর pool ঠিকানাই সার্ভার নিজের বলে জানে। শাখার prefix আলাদা করে ঘোষণা করতে হয়, এবং তা করার পরেও শাখায় forwarder আর প্রধান কার্যালয়ে return path দরকার। ভুল জায়গায় লেখা route সমাধানের মতো দেখায়, কিন্তু কিছুই বদলায় না।

দুই ঠিকানা, দুই ভিন্ন মালিকানার দাবি

ক্লায়েন্ট সংযুক্ত হলে Access Server কনফিগার করা VPN pool থেকে ঠিকানা দেয়, যেমন 10.90.0.0/24। ওই বরাদ্দ এক হোস্টের lease। সংযোগে বলা নেই ক্লায়েন্টটি 10.60.0.0/24-এর সামনেও বসে, আর সার্ভার অনুমান করে না: LAN prefix নির্দিষ্ট ক্লায়েন্ট দিয়ে পৌঁছানো যায় কেবল প্রশাসক ঘোষণা করলে।

তাই অন্য মেশিনে static route যোগ করলে কাজ হয় না। route বলে 10.60.0.0/24 এই ঠিকানায় পাঠাও, কিন্তু ঠিকানাটি gateway হিসেবে চিহ্নিত নয় এমন ক্লায়েন্টের হলে সার্ভারের সেই প্যাকেট সেখানে পৌঁছানোর কারণ নেই, ক্লায়েন্টের stack সেগুলো ফেলে দিতে পারে। ঘোষণা ও route একই ব্যবস্থার দুই অর্ধ।

gateway সেটিং আসলে কী ইনস্টল করে

Admin Web UI-তে ঘোষণাটি একটি user property: connector ব্যবহারকারীতে Configure VPN gateway চালু করুন এবং প্রকৃত শাখা prefix Network on the VPN client side-এ দিন। ওই ব্যবহারকারী অন্যদের মতোই প্রমাণিত হয়, তাই নজরহীন ডিভাইসের উপযোগী credential নীতি দরকার, আর auto-login profile গোপনীয়, সুবিধার ফাইল নয়।

সেই checkbox-এর পেছনে সার্ভার prefix-টিকে ওই ক্লায়েন্টের pool ঠিকানা দিয়ে পৌঁছানোর যোগ্য ধরে, আর Access Controls-এর route কনফিগারেশন ঠিক করে অন্য ক্লায়েন্টদের কী জানানো হবে: সাধারণ ক্লায়েন্টদের পাঠানো route এবং প্রধান কার্যালয়ের নেটওয়ার্ক থেকে ক্লায়েন্ট ঠিকানা ও subnet-এ ট্রাফিক অনুমোদনের নিয়ম। শাখায় পৌঁছানো উচিত এমন নেটওয়ার্কের জন্য routing চালু করুন, অনুমোদিত তালিকা ছোট রাখুন।

তৈরি ফাইলে পেস্ট করা Community ধাঁচের directive এই মডেলে অংশ নেয় না। পণ্যটি যে routing table পাঠায় তার মালিক সে-ই; হাতে সম্পাদিত লাইন পরের regeneration-এ প্রতিস্থাপিত হয় বা উপেক্ষিত হয়।

দুই নেটওয়ার্কের return path সম্পূর্ণ করুন

নির্দিষ্ট পরিকল্পনা: প্রধান কার্যালয় 10.40.0.0/24, শাখা 10.60.0.0/24, VPN pool 10.90.0.0/24, আর Access Server প্রধান কার্যালয়ের দিকে ব্যক্তিগত ঠিকানায় পাওয়া যায়। প্রধান কার্যালয়ের router-এর শাখা prefix ও pool-এর জন্য route দরকার, দুটোই Access Server-এর দিকে। তা না থাকলে tunnel অনুরোধ বহন করে আর উত্তরটি default gateway দিয়ে বেরোয়, যা পরিচিত অর্ধ-খোলা সংযোগ।

শাখায় connector-কে নিজের প্রতি না-ঠিকানা করা প্যাকেট forward করতে হয়: OS-এ IP forwarding এবং tunnel ও LAN interface-এ সীমিত forwarding অনুমতি; Linux-এ net.ipv4.ip_forward=1 forward chain নিয়মসহ, Windows-এ routing and remote access। এরপর শাখার হোস্টগুলোর return path দরকার: হয় connector তাদের default gateway, নয়তো বিদ্যমান gateway প্রধান কার্যালয় ও pool prefix-এর নির্দিষ্ট route বহন করে।

connector-এর নিজের routing table শাখা LAN-এর প্রতিটি হোস্ট পুনরায় কনফিগার করে না। হোস্টগুলো অন্য router-এর দিকে থাকলে return route সেখানেই, আর সেই router-কে মানতে হবে যে সে যে source ঠিকানা দেখে তা স্থানীয় subnet-এর প্রতিবেশী নয়।

ব্যর্থতাকে পথ হিসেবে পড়ুন, অনুমতি হিসেবে নয়

নির্দিষ্ট ক্রমে পরীক্ষা করুন। প্রথমে Access Server থেকে শাখার হোস্টে অনুমোদিত সেবা, তারপর সাধারণ প্রধান কার্যালয়ের হোস্ট থেকে একই সেবা, তারপর নীতি অনুমতি দিলে বিপরীত দিক। প্রথমটি পাস করে দ্বিতীয়টি ব্যর্থ হলে push করা route বা access নিয়ম সমস্যা। দুটোই পাস করেও উত্তর না এলে শাখার forwarding ও প্রধান কার্যালয়ের return route দেখুন।

host firewall পরের সন্দেহভাজন, কারণ routed access-এ গন্তব্য প্রধান কার্যালয় বা pool ঠিকানাকে source হিসেবে দেখে। স্থানীয় subnet-এর জন্য লেখা নিয়ম মিলবে না, আর routing নিখুঁতভাবে চলার পরেও প্যাকেট ফেলে দেওয়া হয়।

দুটি নকশা এই ধাঁচের বেশি চায়। সাইটের মধ্যে ওভারল্যাপিং prefix গন্তব্যকে অস্পষ্ট করে এবং renumbering বা translation দরকার, আর clustered Access Server-এ প্রতিটি node থেকে শাখার connector পর্যন্ত কাজ করা পথ দরকার, route একটি node-এ রাখা নয়। স্বাভাবিক save ও update পথে পরিবর্তন প্রয়োগ করুন, connector আবার সংযুক্ত করুন, দুই প্রান্ত থেকে আবার যাচাই করুন; প্রতিটি মেশিন full reboot করা পদ্ধতির অংশ নয়।

Access Server site-to-site tutorial একই সেটিং পণ্যের ক্রমে তালিকাভুক্ত করে; নিজের prefix-এ নকশা খাপ খাওয়ানোর আগে একবার অনুসরণ করা উচিত।

সম্পর্কিত নিবন্ধ