OpenVPN-এ route-nopull আসলে সার্ভার কী পুশ করা থেকে বিরত রাখে
route-nopull পুশ করা রুট ও DHCP অপশন বাদ দেয়, হ্যান্ডশেক নয়। এটির সঙ্গে pull-filter বা কিছুই না—এর মধ্যে বেছে নিন, তারপর রুটগুলো নিজে যোগ করুন।
আপনি ক্লায়েন্ট প্রোফাইলে route-nopull রেখেছেন যাতে টানেল আপনার ডিফল্ট রুট গিলে না ফেলে, আর এখন অফিস সাবনেট পৌঁছানোর বাইরে, অথচ ক্লায়েন্ট এখনও বলে যে সংযুক্ত। দুটি পর্যবেক্ষণই সত্য, এবং কিছুই ব্যর্থ হয়নি। ফ্ল্যাগটি ক্লায়েন্টকে বলে সার্ভার যে রুট ও DHCP এন্ট্রি পুশ করে সেগুলো এড়িয়ে যেতে, যা যোগ করার সময় বেশিরভাগ মানুষ যা আশা করে তার চেয়ে সংকীর্ণ নির্দেশ। যা থাকে তা হল একটি কার্যকর টানেল, কোন গন্তব্য এটির ব্যবহার করবে সে বিষয়ে কোনো মতামত ছাড়াই।
এই ফাঁকটাই হল সেই পুরো সিদ্ধান্ত যা নিয়ে এই লেখাটি। হয় সার্ভার নেটওয়ার্কটি বর্ণনা করে, নয় ক্লায়েন্ট করে, আর ফ্ল্যাগটি সেই কাজটি ক্লায়েন্টের হাতে তুলে দেয়, আপনার হয়ে তার কিছুই না করে।
সংযোগের সময় ফ্ল্যাগটি কী বন্ধ করে
টানা OpenVPN ক্লায়েন্ট সাধারণত প্রমাণীকরণের পরে সার্ভার থেকে একটি বান্ডেল নেয়: রুট, ডিফল্ট গেটওয়ের পুনর্নির্দেশ, DNS সার্ভার এবং কিছু টিউনিং নির্দেশনা। route-nopull চালু থাকলে ক্লায়েন্ট তখনও সেশন গ্রহণ করে, তখনও সার্টিফিকেট যাচাই করে, তখনও সাইফার ও keepalive নিয়ে দরকষাকষি করে, এবং তখনও ইন্টারফেস তুলে আনে। এটি বাদ দেয় পুশ করা route লাইন ও পুশ করা dhcp-option লাইনের প্রয়োগ, DNS সহ।
বিভ্রাটের উৎস মৃত অ্যাপের পাশে থাকা সবুজ নির্দেশক। টানেল আছে; গন্তব্যগুলোর সঙ্গে সেই টানেলের মিল নেই। ক্লায়েন্টের স্ট্যাটাস প্যানেলে কিছুই “সংযুক্ত ও রাউট করছে” আর “সংযুক্ত ও নিষ্ক্রিয়” এর মধ্যে পার্থক্য করে না, কারণ টানেলের দৃষ্টিতে দুটোই একই অবস্থা।
কেন সচল টানেল তবুও কিছুই রাউট করতে পারে না
ইন্টারফেসটি নিজের ঠিকানা নিয়ে উপস্থিত হয়, আর পয়েন্ট-টু-পয়েন্ট লিংকে প্রায়শই পিয়ারের দিকে হোস্ট রুটের চেয়ে বেশি নির্দিষ্ট কিছু থাকে না। একটি প্রাইভেট সাবনেট তখনই পৌঁছানোর যোগ্য হয় যখন কোনো রুট সঠিক প্রিফিক্স নিয়ে সেই ইন্টারফেসের দিকে নির্দেশ করে, আর পুশ বন্ধ থাকলে সেই রুট কখনও আসে না। ডাউনলোড করা প্রোফাইলও সাধারণত সাহায্য করতে পারে না, কারণ এটি ধরে নিয়েই লেখা হয়েছিল যে সার্ভার ঠিক এই তথ্যটিই দেবে। তাই ইন্টারফেস সুস্থ দেখাতে পারে অথচ সাবনেট অন্ধকার থাকে।
তাহলে প্রোফাইল পড়া খুব কমই প্রমাণ করে। বরং সংযুক্ত মেশিনে চলমান অবস্থাটি পড়ুন:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10দ্বিতীয় কমান্ডে সাবনেট রুট ছাড়া একটি ঠিকানা এই সমস্যার লক্ষণ। তৃতীয় কমান্ডটি তখন ব্যবহারকারীদের আসল যত্নের প্রশ্নটির উত্তর দেয়, কারণ এটি এমন ইন্টারফেস রিপোর্ট করে যা কার্নেল একটি নির্দিষ্ট গন্তব্যের জন্য বেছে নেবে, আপনি যে তালিকাটি ব্যবহার হবে বলে আশা করেছিলেন তা নয়। যদি এটি আপনার ফিজিক্যাল লিংক দিয়ে উত্তর দেয়, তবে টানেল পথেই নেই।
নাম রেজল্যুশন ব্যর্থ হয় একটি সম্পর্কিত কারণে, আলাদা কোনো কারণে নয়। পুশ করা dhcp-option DNS এন্ট্রিগুলো একই ফ্ল্যাগে এড়িয়ে যাওয়া হয়, তাই অভ্যন্তরীণ হোস্টের জন্য কোয়েরি যায় স্থানীয় নেটওয়ার্ক যে রেজলভার দিয়েছে তার কাছে। সেই রেজলভারের অফিসের জন্য কোনো জোন নেই, তাই কোয়েরি ব্যর্থ হয় বা পাবলিক উত্তর দেয়, আর ব্যর্থতাটি সার্ভার সমস্যার মতো দেখায় অথচ এটি ক্লায়েন্ট কনফিগারেশনের সমস্যা। নামের আগে ঠিকানা পরীক্ষা করাই দুটোকে আলাদা করে।
ফ্ল্যাগ আর প্রিফিক্স ফিল্টারের মধ্যে বাছাই
দুটি বিকল্প একই অভিযোগের ভিন্ন আকার সমাধান করে, আর খারাপ বাছাইই “সংযুক্ত কিন্তু অকেজো” অবস্থাটি তৈরি করে। একটি পুশ করা নীতিটি সম্পূর্ণ বদলে দেয়, অন্যটি প্রিফিক্স দিয়ে তা সম্পাদনা করে। সারণিটি সংক্ষিপ্ত সংস্করণ দেয়, আর তার পরের অনুচ্ছেদটি সেই অংশটি কভার করে যা মানুষকে ধরে ফেলে।
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter তিনটি ক্রিয়াবিশিষ্ট একটি প্রিফিক্স ম্যাচার, তাই এটি একগুচ্ছ লাইন গ্রহণ করতে পারে, নীরবে উপেক্ষা করতে পারে, অথবা কোনো প্রিফিক্স দেখা গেলে সংযোগটি সরাসরি প্রত্যাখ্যান করতে পারে। শেষ আচরণটিই জানার যোগ্য: একটি প্রত্যাখ্যান নিয়ম নীতিগত মতবিরোধকে নীরব বাদ দেওয়ার বদলে ব্যর্থ হ্যান্ডশেকে পরিণত করে। OpenVPN 2.6 ম্যানুয়াল গৃহীত প্রিফিক্স ও প্রতিটি ক্রিয়ার সুনির্দিষ্ট অর্থ তালিকাভুক্ত করে।
একটি সাধারণ মধ্যপথ হল শুধু redirect-gateway প্রত্যাখ্যান করা এবং অফিসের রুট ও DNS যথারীতি আসতে দেওয়া। এটি সার্ভার যে অংশগুলো আপনার চেয়ে ভালো বোঝে সেগুলোর জন্য পুশ কার্যকর রাখে, আর একই সঙ্গে যে এক লাইন আপনার ডিফল্ট রুট দখল করত তা ঠেকায়।
হাতে রুট ও রেজলভার যোগ করা
ফ্ল্যাগটি রাখলে, প্রোফাইলকে অবশ্যই বলতে হবে যা সার্ভার বলত। ক্লায়েন্ট-পাশের route নির্দেশনাগুলো সংযোগ প্রতিষ্ঠার পরে প্রয়োগ হয়, তাই সেগুলো ফ্ল্যাগের সঙ্গে কাজ করে, এটি দ্বারা অবরুদ্ধ হয় না। সেগুলো প্রোফাইলে রাখুন, ইন্টারঅ্যাক্টিভ কমান্ড লাইনে নয়, নইলে পরের পুনঃসংযোগ কার্যকর অবস্থাটি পুনরুৎপাদন করবে না।
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53DNS লাইনটি একটি অস্বস্তিকর জায়গায় থাকে: এটি ক্লায়েন্ট-পাশের নির্দেশ, কিন্তু কিছু ক্লায়েন্ট এটি কেবল প্ল্যাটফর্মের DNS ইন্টিগ্রেশনের মাধ্যমে প্রয়োগ করে, যা লিংক বদলালে এটির উপর লেখা হতে পারে। systemd হোস্টে টানেল ইন্টারফেসে সরাসরি রেজলভার সেট করা ক্লায়েন্ট প্রায়োরিটি প্রতিযোগিতায় জিতবে বলে আশা করার চেয়ে বেশি অনুমানযোগ্য:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comরাউটিং ডোমেইনটি ঠিকানার মতোই গুরুত্বপূর্ণ। এটি ছাড়া পাবলিক নামের কোয়েরিও ভেতরের রেজলভারে যেতে পারে, আর রিকার্সন প্রত্যাখ্যানকারী যেকোনো অভ্যন্তরীণ রেজলভার প্রাইভেট জোন কাজ রাখলেও ব্রাউজিং ভেঙে দেবে। এটি থাকলে কেবল সেই সাফিক্সের অধীন নামগুলো টানেল রেজলভারে রাউট হয় আর বাকি সব ফিজিক্যাল লিংক অনুসরণ করে।
ফল যাচাই: ঠিকানা, নাম এবং বাইরের পথ
তিনটি পরীক্ষা সম্ভাব্য ব্যর্থতাগুলো আলাদা করে। আগে IP দিয়ে প্রাইভেট ঠিকানা নিন, তারপর নাম দিয়ে একই হোস্ট, তারপর একটি সাধারণ পাবলিক সাইট। কাজ করা IP আর ব্যর্থ নাম রেজলভারের দিকে ইঙ্গিত করে; ব্যর্থ IP আর কাজ করা নাম রাউটিংয়ের দিকে ইঙ্গিত করে; দুটোই ব্যর্থ হলে সাধারণত বোঝায় টানেল পথে নেই।
তারপর ভেতরের দিকে নয়, বাইরের দিকে তাকান। টানেল এন্ডপয়েন্টের নিজস্ব রুটকে পরিবর্তনটি টিকে থাকতে হবে, আর যেকোনো ব্লকিং ব্যর্থতা এন্ডপয়েন্ট না ধরে টানেলের মধ্যে সীমাবদ্ধ থাকতে হবে। টানেল নামার পরেও যে ক্লায়েন্ট ব্রাউজিং চালিয়ে যায় সেটি রাউটিং সমস্যা নয়, নীতি সমস্যা, এবং উপরের তিনটি পরীক্ষার কোনোটিতেই তা দেখা যাবে না।
চূড়ান্ত তালিকাটি প্রোফাইলের ডকুমেন্টেশনে লিখুন: রুট, রেজলভার, ডোমেইন, এবং প্রতিটির থাকার কারণ। একই সারণি পুনরুৎপাদনকারী একটি পুনঃসংযোগই একমাত্র প্রমাণ যে স্থানীয় নীতিটি সম্পূর্ণ। টানেল চালু থাকলেও যদি অ্যাপ্লিকেশনগুলো এখনও ব্যর্থ হয় এবং তিনটি পরীক্ষাই পাস করে, তবে পরের জায়গাটি হলো “সংযুক্ত কিন্তু অফলাইন” শ্রেণির সমস্যা, ইতিমধ্যে যাচাই করা সার্টিফিকেট নয়।