রাউটারে VPN চললে STUN উত্তরে কী প্রকাশ পায়
রাউটারের টানেল ঠিকানা ব্রাউজারের স্থানীয় ঠিকানা নয়। রিফ্লেক্টর যা জানায় তা পড়ার আগে প্রতিটি অনুরোধ কীভাবে রুট হয় ও রূপান্তরিত হয় তা অনুসরণ করুন।
টানেল যখন রাউটারে থাকে, ব্রাউজার চালানো মেশিনে কোনো টানেল ইন্টারফেসই থাকে না। সেই মেশিনের কাছ থেকে স্থানীয় ঠিকানা চাইলে পাওয়া যায় একটি প্রাইভেট LAN ঠিকানা আর একটি লুপব্যাক, VPN ঠিকানার মতো কিছুই নয়। তবুও ওপারের STUN সার্ভার এখনও পথ সম্পর্কে অর্থবহ কিছু জানাতে পারে, আর সে যা জানায় তা পুরোপুরি নির্ভর করে ওই নির্দিষ্ট অনুরোধটি কীভাবে রুট হয়েছে ও রূপান্তরিত হয়েছে তার উপর।
এই অংশটিই ধীরে ভাবার যোগ্য। “ব্রাউজার VPN ঠিকানার মালিক নয়” কথাটি ইন্টারফেস নিয়ে প্রশ্নের উত্তর দেয়, অন্যদিকে প্রতিফলিত ঠিকানা হলো রূপান্তরের মধ্য দিয়ে যাওয়া পথের উত্তর। দুটিকে গুলিয়ে ফেললে প্রকাশ নিয়ে আত্মবিশ্বাসী সিদ্ধান্ত আসে, যা প্রমাণ সমর্থন করে না।
দুই ডিভাইস, দুই সেট ইন্টারফেস
রাউটারভিত্তিক ব্যবস্থায় টানেল রাউটারেই শেষ হয় এবং LAN ক্লায়েন্ট সাধারণ ট্রাফিক তার ডিফল্ট গেটওয়েতে পাঠায়। ক্লায়েন্টের ইন্টারফেস তালিকা ছোটই থাকে: একটি প্রাইভেট ঠিকানা, হয়তো অন্য নেটওয়ার্কের জন্য আরেকটি, আর লুপব্যাক। ঝুঁকি এই নয় যে এর কোনওটি ঘুরেফিরে টানেল ঠিকানা; ঝুঁকি হলো অনুরোধটি এমন পথে বেরোয় যা আপনি বেছে নেননি।
কোন ইন্টারফেস আছে তা না জিজ্ঞেস করে ক্লায়েন্টকে জিজ্ঞেস করুন একটি নির্দিষ্ট গন্তব্য কোন পথে যাবে। উত্তরে একটি গেটওয়ে আর কার্নেল যে সোর্স ঠিকানা ব্যবহার করবে তা নাম ধরে আসে, যা ঠিকানার যেকোনো তালিকার চেয়ে বেশি তথ্যবহ।
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsডকুমেন্টেশন রেঞ্জ পরীক্ষার ভালো গন্তব্য, কারণ সেগুলো কখনও কোনো বাস্তব সেবায় রিজলভ হয় না। ক্লায়েন্ট যা বলে তার সঙ্গে রাউটার যা বলে তা মিলিয়ে দেখুন, আর যেকোনো অমিলকে প্রমাণ হিসেবে ধরুন যে পলিসি রাউটিং, স্প্লিট-টানেল নিয়ম বা দ্বিতীয় ডিফল্ট রুট এমন কিছু করছে যা আপনি হিসাবে নেননি।
Binding উত্তরে যা বলা অনুমোদিত
RFC 8489 Binding অনুরোধ ও প্রতিক্রিয়া নির্ধারণ করে, যেখানে সার্ভার ওই অনুরোধের জন্য নিজে দেখা সোর্স ট্রান্সপোর্ট ঠিকানা জানায়। এটি এক মুহূর্তে এক পঞ্চক নিয়ে বক্তব্য, ক্লায়েন্টের ইন্টারফেসের জনগণনা নয়। তাই আকর্ষণীয় সবকিছু ঘটে ক্লায়েন্ট আর পর্যবেক্ষণ বিন্দুর মাঝে।
ওই ফাঁক ভরে দেয় রাউটিং আর রূপান্তর। যে রাউটার বহির্গামী ট্রাফিকে সোর্স NAT করে, সে ক্লায়েন্টের প্রাইভেট সোর্সকে বহির্গামী ইন্টারফেসে নিজের ঠিকানায় বদলে দেয়। সেই ইন্টারফেস টানেল হলে রিফ্লেক্টর টানেল ঠিকানা দেখে। প্যাকেট টানেল থেকে বাদ পড়লে রিফ্লেক্টর দেখে WAN রূপান্তর যা তৈরি করেছে তা। একই ক্লায়েন্ট, একই রিফ্লেক্টর, আলাদা উত্তর।
একই রকম দেখায় অথচ এক নয় এমন তিনটি ক্ষেত্র
দরকারি পার্থক্য পাবলিক বনাম প্রাইভেট নয়, বরং কোন প্রয়োগ বিন্দু প্যাকেটটি সামলেছে। রাউটারের নিজের টেবিল খোলা রেখে ক্ষেত্রগুলো দেখুন, কারণ একটি ব্রাউজারই তিনটিই তৈরি করতে পারে—আপনি যে নিয়ম লিখেছিলেন তা ভুলে গেলে।
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
কেবল দ্বিতীয় ক্ষেত্রই কিছু ট্রাফিক কখনও সরাসরি বেরোবে না এই শর্ত ভাঙে, আর কেবল প্রথম ও তৃতীয় ক্ষেত্রই টানেল-পাশের শনাক্তকারী প্রকাশ করে। তিনটি সারির কোনওটিই নির্দিষ্ট কোনো প্রোভাইডারের আচরণ নিয়ে দাবি নয়: প্রাইভেট রিফ্লেক্টরে আদৌ পৌঁছানো যায় কি না তা নির্ভর করে রাউটিং, পিয়ারের অনুমোদিত IP আর দুই প্রান্তের ফায়ারওয়াল নীতির উপর।
একই প্রোভাইডারে অ্যাকাউন্ট থাকলে এর কিছুই প্রমাণ হয় না। এটাও মনে রাখা দরকার যে রাউট করা অনুরোধে ক্লায়েন্টের LAN সোর্স থেকে যেতে পারে যদি কিছু তা রূপান্তর না করে, তাই সোর্স ফিল্ড টোপোলজি চিত্র থেকে ধরে নয়, অনুসরণ করে দেখতে হবে।
সংগ্রহ করা বেছে নেওয়া নয়
WebRTC চেষ্টার জন্য প্রার্থী ঠিকানা সংগ্রহ করে, আর ডায়াগনস্টিক তালিকায় দেখা যাওয়া প্রার্থী কখনও মিডিয়া বহন না-ও করতে পারে। তালিকাটিকে “পিয়ার এটাই শিখেছে” হিসেবে পড়া প্রমাণকে অতিরঞ্জিত করে। নির্বাচিত জোড়টিই আসলে সেশন বহন করেছে, আর সেটি অন্য একটি ফিল্ডে থাকে।
HTTPS প্রস্থান যাচাইকরণ আরেকটি প্রশ্নের উত্তর দেয়: ওই অনুরোধের জন্য একটি ওয়েব সার্ভার যে সোর্স ঠিকানা দেখেছে। এটি দরকারি ক্রস-চেক ঠিক এই কারণে যে এটি UDP রিফ্লেক্টরের চেয়ে ভিন্ন প্রোটোকল আর প্রায়ই ভিন্ন গন্তব্য ব্যবহার করে, আর দুটির মধ্যে অমিল সাধারণত বাগ নয়, রাউটিং নিয়মের দিকে ইঙ্গিত করে।
নীতি ঠিক করুন, তারপর উত্তর পড়ুন
পরীক্ষার আগে উদ্দেশ্য লিখে রাখুন: কোন ট্রাফিককে টানেল ব্যবহার করতে হবে, কোনটি সরাসরি যেতে পারে, কোন ঠিকানা-পরিবার পরিধিতে আছে, আর টানেল ডাউন হলে কী ঘটবে। এই ভিত্তি ছাড়া প্রতিটি পর্যবেক্ষণ দ্ব্যর্থক, কারণ ইচ্ছাকৃতভাবে অনুমোদিত পথ থেকে লিক আলাদা করা যায় না।
তারপর একবারে একটি প্রশ্ন করুন। এই গন্তব্য কোন পথে যায়। এই রিফ্লেক্টর কোন ঠিকানা জানায়। সেশন কোন প্রার্থী জোড় বেছে নিয়েছে। উত্তরগুলো নীতির পাশে রাখুন আর তারিখ দিন, কারণ ফার্মওয়্যার হালনাগাদ ডিফল্ট আচরণ এমনভাবে বদলাতে পারে যা গত বছরের সিদ্ধান্তকে চুপচাপ অকার্যকর করে দেয়।
রাউটার এখনও একটি শক্তিশালী প্রয়োগ বিন্দু, কারণ এটি এমন ট্রাফিক দেখে যা ক্লায়েন্ট নিজেকে পুনরায় কনফিগার না করে এড়াতে পারে না। এটি এই প্রতিশ্রুতি নয় যে প্রতিটি অ্যাপ্লিকেশন প্রোটোকলের প্রতিটি ফিল্ড কিছুই প্রকাশ করে না, আর আপনি যে পথগুলো অনুমোদন করতে বেছে নিয়েছেন তা লিখে রাখার বিকল্পও এটি নয়।