Hairpin NAT: ভেতর থেকে VPN এন্ডপয়েন্ট কেন কাজ করে না
পাবলিক ঠিকানা ব্যবহার করা একটি স্থানীয় ক্লায়েন্ট LAN ছেড়ে আবার ফিরে আসে। রাউটার hairpin না করলে বাইরে কাজ করে, ভেতরে করে না।
মোবাইল নেটওয়ার্ক থেকে সাড়া দিলেও সোফা থেকে ব্যর্থ হওয়া VPN সার্ভার সাধারণত সার্টিফিকেটের সমস্যা নয়। LAN-এর ভেতরের ক্লায়েন্ট রাউটারকে এমন একটি প্যাকেট অনুবাদ করতে বলে যার গন্তব্য রাউটারের নিজের পাবলিক ঠিকানা, অর্থাৎ প্যাকেটটিকে বেরিয়ে সোজা ফিরে আসতে হবে। এই কৌশলের নাম hairpinning, এবং অনেক রাউটার এটি হয় বাস্তবায়ন করে না, নয়তো কেবল একটি চেকবক্স চালু থাকলে করে। বাইরের পরীক্ষা পাস করাই বিষয়টি বিভ্রান্তিকর করে, কারণ এটি প্রমাণ করে লিসেনার ও ফরওয়ার্ডিং নিয়ম ঠিক আছে।
প্যাকেট বেরোয় এবং ফিরে আসে
প্যাকেটটি অনুসরণ করুন। ক্লায়েন্ট পাবলিক নামটি রিজলভ করে, পাবলিক ঠিকানায় সংযোগ করে, এবং রাউটারের গন্তব্য NAT গন্তব্যকে ভেতরের সার্ভারে পুনর্লিখন করে। সার্ভারের উত্তর ক্লায়েন্টের LAN ঠিকানায় সম্বোধন করা হয়, তাই এটি রাউটারের LAN ইন্টারফেস দিয়ে ফিরে যায়, যে NAT নিয়ম উৎসকে ফিরিয়ে দিত তা কখনো অতিক্রম না করেই।
এখন ক্লায়েন্ট এমন ঠিকানা থেকে প্যাকেট পায় যেখানে সে কিছুই পাঠায়নি, এবং তা ফেলে দেয়। এই অসামঞ্জস্যই পুরো ব্যর্থতা।
RFC 4787 এই ক্ষেত্রে NAT থেকে প্রত্যাশিত আচরণ বর্ণনা করে, এবং সংক্ষেপে বলা যায় এটি তত্ত্বে নির্ধারিত হলেও বাস্তবে ঐচ্ছিক। কিছু রাউটার সেটিংকে NAT loopback বলে, অন্যরা hairpin NAT বা NAT reflection বলে, আবার কিছু কিছুই দেখায় না। যে রাউটারে এটি নেই সেটি ভুল কনফিগার করা নয়; এটি সাধারণ কাজটিই করছে, আর সমাধান অন্য জায়গায়। স্থানীয় পরীক্ষা ব্যর্থ হলেই পাবলিক ফরওয়ার্ডিং নিয়ম ভুল বলে সিদ্ধান্ত নেবেন না।
পরীক্ষা 1: দুটি পথ আলাদাভাবে পরীক্ষা করুন
LAN-এর বাইরে থেকে একজন প্রকৃত ব্যবহারকারী যে প্রোফাইল ব্যবহার করবেন সেই একই প্রোফাইলে সংযোগ করে সেশন প্রতিষ্ঠা নিশ্চিত করুন। ভেতর থেকে একই প্রোফাইলে পাবলিক ঠিকানায় সংযোগ করে সঠিক ত্রুটি ও সময় লিখে রাখুন।
একটি নিখুঁত স্থানীয় পরীক্ষা হোস্টনেম ধরে রেখে কেবল ঠিকানা বদলায়: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ অনুরোধটি পাবলিক ঠিকানায় পাঠায়, অথচ সঠিক সার্ভার নামই উপস্থাপন করে। এটি নাম-রিজলিউশনের সমস্যাকে অনুবাদের সমস্যা থেকে আলাদা করে, যেগুলো একই নাম ক্যাফে থেকে কাজ করলে সহজেই গুলিয়ে যায়। ক্লায়েন্ট TCP সংযোগে ব্যর্থ হয় নাকি পরে TLS-এ, তা লক্ষ্য করুন, কারণ প্রথমটি অনুবাদের দিকে আর দ্বিতীয়টি পরিচয়ের দিকে ইঙ্গিত করে।
পরীক্ষা 2: সার্ভার কী দেখে তা পড়ুন
সবচেয়ে উপযোগী পর্যবেক্ষণ হলো সার্ভারের দৃষ্টিভঙ্গি। VPN হোস্টে ক্লায়েন্টের LAN ঠিকানা ও রাউটারের LAN ঠিকানায় ফিল্টার করা ক্যাপচার চালান, তারপর স্থানীয় প্রচেষ্টা পুনরাবৃত্তি করুন। কিছুই না এলে বোঝা যায় প্যাকেট অনুবাদ পার হয়নি।
সংযোগটি ক্লায়েন্টের ঠিকানার বদলে রাউটারের LAN ঠিকানা থেকে এলে hairpinning ঘটছে এবং উৎস পুনর্লিখিত হয়েছে। এটি কার্যকর কনফিগারেশন, কোনো ত্রুটি নয়।
পরীক্ষা 3: বাইরের পথ না ছুঁয়ে ঠিক করুন
তিনটি সমর্থিত রূপ আছে, প্রভাবের পরিধি বাড়ার ক্রমে। সবচেয়ে সংকীর্ণ হলো split DNS: একটি অভ্যন্তরীণ রেকর্ড প্রকাশ করুন যাতে একই সার্ভার নাম LAN-এর ক্লায়েন্টদের জন্য অভ্যন্তরীণ ঠিকানায় রিজলভ হয়, ফলে পাবলিক পথ সম্পূর্ণ এড়ানো যায়। পরেরটি হলো রাউটারের নথিভুক্ত loopback বা reflection অপশন থাকলে তা চালু করে কেবল এই সেবায় প্রয়োগ করা। সবচেয়ে প্রশস্ত হলো রাউটারে source-NAT নিয়ম যা LAN থেকে আসা ট্রাফিক সার্ভারে পুনর্লিখন করে যাতে উত্তর রাউটার দিয়ে ফিরে আসে; Linux রাউটারে এটি সার্ভারের ঠিকানা ও পোর্টের সাথে মেলা MASQUERADE নিয়ম POSTROUTING -এ। তিনটিই বাহ্যিক পথ অপরিবর্তিত রাখে, আর এই বৈশিষ্ট্যটিই সংরক্ষণ করতে হবে।
স্থানীয় পথকে বাহ্যিকের মতো করতে অসম্পর্কিত পোর্ট ফরওয়ার্ডিং বাড়াবেন না, এবং সমস্যা এড়াতে সেবাটিকে অন্য পোর্টে সরাবেন না। দুটি পরিবর্তনই কেবল ভেতরের জগৎ যা দেখে তা ঠিক করতে বাইরের জগৎ কী পৌঁছাতে পারে তা বদলে দেয়।
Split DNS-এ একটি ফাঁদ আছে যা উল্লেখ করা দরকার। হোস্টনেমকে ইচ্ছেমতো IP দিয়ে বদলালে ক্লায়েন্ট যা যাচাই করে তা বদলে যায়, তাই অভ্যন্তরীণ রেকর্ডকে সার্টিফিকেটের নামের সাথে মিলতেই হবে।
পরীক্ষা 4: পরে দুটি পথই যাচাই করুন
LAN-এর বাইরে থেকে বাহ্যিক প্রচেষ্টা পুনরাবৃত্তি করুন, একই প্রোফাইলে অভ্যন্তরীণ প্রচেষ্টা পুনরাবৃত্তি করুন, এবং নিশ্চিত করুন সার্ভার লগ একটি সফলতা ও একটি নীরবতা নয়, বরং দুটি আলাদা সফল সেশন দেখায়। তারপর দেখুন অন্য ক্লায়েন্টরা এখনো লিসেনারে পৌঁছায় কি না এবং ব্যক্তিগত সম্পদের রুট অপরিবর্তিত আছে কি না।
রেকর্ডটি সংক্ষিপ্ত রাখুন: কোন ক্লায়েন্ট কোন ঠিকানা ব্যবহার করেছে, সার্ভার কী দেখেছে, এবং তিনটি সমাধানের কোনটি প্রয়োগ করা হয়েছে। RFC 4787-এর hairpinning প্রয়োজনীয়তা এখানে NAT থেকে কী প্রত্যাশিত তার রেফারেন্স, এবং ব্যাখ্যা করে এই বৈশিষ্ট্য ছাড়া রাউটার কেন স্বাভাবিক আচরণ করছে। বাইরের জগৎ যা পুনরুৎপাদন করতে পারে না এমন স্থানীয় ব্যর্থতা বিপরীত প্রমাণিত না হওয়া পর্যন্ত অনুবাদের প্রশ্ন, তাই সেভাবেই পরীক্ষা করুন।