পোর্ট ফরওয়ার্ডিং ছাড়াই NAT-এর পিছনের ওয়ার্কস্টেশনে পৌঁছানো
ইনবাউন্ড পোর্ট নেই এমন ওয়ার্কস্টেশনও হাব, রিলে বা অ্যাপ ব্রোকারের মাধ্যমে পৌঁছানো যায়। একটি বেছে নেওয়ার আগে প্রতিটি ডিজাইন কী নিশ্চিত করে তা তুলনা করুন।
ক্যারিয়ার NAT এবং একটি লকড-ডাউন অফিস রাউটারের পিছনে থাকা দুটি এন্ডপয়েন্ট ফরওয়ার্ড করার জন্য কোনো ইনবাউন্ড পোর্ট রাখে না, আর প্রতিক্রিয়া হিসেবে তবুও একটি চাওয়াই স্বাভাবিক। ভালো প্রশ্ন হলো কোন দিকটি বাইরে ডায়াল করতে পারে এবং কোন পৌঁছানোযোগ্য সার্ভিসকে ট্রাফিক বহন করার অনুমতি দেওয়া হয়েছে। চারটি ডিজাইন সেই প্রশ্নের ভিন্নভাবে উত্তর দেয়, এবং পথ অবরুদ্ধ হলে তারা ভিন্নভাবে ব্যর্থ হয়। এদের মধ্যে বেছে নেওয়া মানে প্রোটোকলের নাম নয়, নিশ্চয়তার তুলনা।
চারটি ডিজাইন, চারটি ভিন্ন প্রতিশ্রুতি
নিচের টেবিলটি সংক্ষিপ্ত সংস্করণ। মাঝের কলামটিকে সেই প্রতিশ্রুতি হিসেবে পড়ুন যা আপনি পরীক্ষা করতে পারেন, আর ডান কলামটিকে সেই প্রতিশ্রুতি হিসেবে যা কেউ দেয়নি।
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
কোন সারিটি প্রযোজ্য তা পছন্দের বদলে কাজের প্রকৃতির ওপর নির্ভর করে। একটি রিমোট ডেস্কটপ সেশন, একটি প্রশাসনিক শেল এবং সম্পূর্ণ একটি প্রাইভেট সাবনেটে প্রবেশাধিকার — এই তিনটি চাহিদার একই প্রবেশপথ দরকার নেই, যদিও তারা একই মেশিন নিয়ে হতে পারে।
হাব বদলায় কে বাইরে ডায়াল করবে, কী অনুমোদিত তা নয়
রাউটেড হাব ডিজাইনে দূরের ল্যাপটপ এবং ওয়ার্কস্টেশন, বা তার সামনের সাইট গেটওয়ে, প্রত্যেকে এমন একটি সার্ভিসে আউটবাউন্ড টানেল খোলে যেখানে দুই পক্ষই পৌঁছাতে পারে। ওয়ার্কস্টেশনের রাউটারে কোনো অনুরোধহীন সংযোগ গ্রহণ করা হয় না, আর ঠিক এ কারণেই এই ডিজাইন NAT-এর মধ্যে টিকে থাকে এবং সাইটে স্ট্যাটিক ঠিকানা না থাকলেও কাজ করে। এরপর হাব নিজের নীতিমালা অনুযায়ী দুই ভেতরের ঠিকানার মধ্যে ট্রাফিক রাউট করে।
খরচ হলো হাবটিকে থাকতে হবে, দুই দিক থেকেই পৌঁছানোযোগ্য হতে হবে এবং কাউকে তা পরিচালনা করতে হবে। আউটবাউন্ড ফিল্টারিংকে ট্রান্সপোর্টের অনুমতি দিতে হবে, আর যে নেটওয়ার্ক তা ব্লক করে সে পোর্ট ফরওয়ার্ড প্রয়োজন না হলেও ডিজাইনটি ব্যর্থ করবে।
সূক্ষ্ম অংশটি হলো পৌঁছানোযোগ্যতা ও অনুমোদন দুটি আলাদা সিদ্ধান্ত যা ভিন্ন জায়গায় নেওয়া হয়। একটি প্রিফিক্সে যাওয়া রুট এই কথা বলে না যে ওয়ার্কস্টেশনের কোন সার্ভিসটি ওই পরিচয় ব্যবহার করতে পারবে, আর টানেলের অনুমতি দেওয়া ফায়ারওয়াল নিয়ম এই কথা বলে না যে অ্যাকাউন্টটি লগইন করতে পারবে কি না। দুটিই কনফিগার করুন, দুটিই পরীক্ষা করুন, এবং অনুমোদনের সিদ্ধান্তটি রাউটিং টেবিলের কাছে নয়, রিসোর্সের মালিক সিস্টেমের কাছে রাখুন।
ট্রাভার্সাল কেবল তখনই কাজ করে যখন দুই স্ট্যাকই তা বাস্তবায়ন করে
পিয়ার ট্রাভার্সাল নির্দিষ্ট একটি সিস্টেমের সক্ষমতা, VPN-কে উন্নত করার কোনো সেটিং নয়। Interactive Connectivity Establishment কয়েকটি প্রার্থী ঠিকানা সংগ্রহ করে এবং একটি কাজ না করা পর্যন্ত জোড়া পরীক্ষা করে: স্থানীয় ইন্টারফেসে হোস্ট প্রার্থী, NAT যা প্রকাশ করে তা থেকে গঠিত সার্ভার-রিফ্লেক্সিভ প্রার্থী, এবং রিলেতে বরাদ্দ করা রিলে প্রার্থী। শুধু একটি প্রাইভেট ঠিকানা কোনো পথ নয়, কারণ অন্য পক্ষ সেখানে রাউট করতে পারে না।
রিলে হওয়া কেসটি বাতিল করার আগে বোঝা উচিত। RFC 8656 TURN-কে এমন প্রোটোকল হিসেবে বর্ণনা করে যেখানে ক্লায়েন্ট একটি সার্ভারের কাছে রিলে করা ট্রান্সপোর্ট ঠিকানা চায় এবং সার্ভার সেই ক্লায়েন্ট ও তার পিয়ারদের মধ্যে ট্রাফিক পাঠায়। তাই রিলেই ডেটা বহন করে, যা কেবল এন্ডপয়েন্টদের মিলিত হতে সাহায্য করা একটি ডিরেক্টরি থেকে সম্পূর্ণ আলাদা। পিয়ারের সঙ্গে রিলে ঠিকানা বিনিময় একটি সমন্বয় ধাপ যা অ্যাপ্লিকেশনকে করতে হয়।
যা আপনি প্রতিশ্রুতি দিতে পারেন না তা হলো সরাসরি পথ। সিমেট্রিক NAT এবং কিছু এন্টারপ্রাইজ ফায়ারওয়াল হোল পাঞ্চিং ব্যর্থ করে, আর তা হলে সিস্টেম হয় রিলেতে ফিরে যায় নয়তো ব্যর্থ হয়। আরও যা আপনি সিদ্ধান্তে আসতে পারেন না তা হলো দুইটি অনূদিত এন্ডপয়েন্ট কখনো কথা বলতে পারবে না; রিলে ফলব্যাকসহ একটি সমর্থিত স্ট্যাক ঠিক এ কারণেই আছে যে তারা প্রায়ই পারবে। ঠিক করুন প্রাপ্যতা বেশি গুরুত্বপূর্ণ, নাকি সরাসরি পথ, তারপর সুখী পরিস্থিতি ধরে নেওয়ার বদলে ডিপ্লয়মেন্ট আসলে কোন পথ বেছে নিয়েছে তা যাচাই করুন।
ব্রোকার নেটওয়ার্কের চেয়ে সংকীর্ণ
যখন চাহিদা একটি অ্যাপ্লিকেশন, তখন একটি অ্যাপ্লিকেশন ব্রোকার বা ওয়ার্কস্টেশন থেকে শুরু করা রিভার্স সংযোগই সবচেয়ে ছোট উত্তর হতে পারে। ওয়ার্কস্টেশন ব্রোকারের কাছে বাইরে ডায়াল করে, ব্রোকার দূরবর্তী ব্যবহারকারীকে প্রমাণ করে, এবং কেবল সেই অ্যাপ্লিকেশন সেশনই বহন করা হয়। ওয়ার্কস্টেশনের সাবনেটে কোনো রুট তৈরি হয় না, তাই দূরবর্তী সেশনের আপস তার পাশের প্রতিটি ডিভাইসে পথ উত্তরাধিকারসূত্রে পায় না।
এই সংকীর্ণতার একটা দাম আছে: প্রতিটি অতিরিক্ত অ্যাপ্লিকেশনের নিজস্ব ইন্টিগ্রেশন দরকার, আর অ্যাপ্লিকেশন স্থানীয় নেটওয়ার্ক সম্পর্কে যা ধরে নেয়, যেমন কাছের সার্ভারে খোলা একটি ফাইল শেয়ার, তা হয়তো পৌঁছানো যাবে না। ব্রোকার নীতিমালা ও লগিং এক জায়গায় কেন্দ্রীভূত করে, যা উপকারী যতক্ষণ না সেই জায়গাটিই বিভ্রাট হয়ে ওঠে।
বিশ্বাসের সীমানা তুলনা করুন, তারপর পথ পরীক্ষা করুন
যে হাব টানেল শেষ করে সে তার রাউট করা ট্রাফিক পড়তে পারে। অ্যাপ্লিকেশন এন্ড-টু-এন্ড এনক্রিপ্ট করলে রিলে স্বতন্ত্রভাবে সুরক্ষিত বিনিময় বহন করতে পারে, আর ব্রোকার সাধারণত যে সেশন উপস্থাপন করে তা শেষ করে। দুটি ডিজাইন এনক্রিপ্টেড বলেই সমতুল্য — এ সিদ্ধান্তে আসার আগে নির্ধারণ করুন সুরক্ষা আসলে কোথায় শেষ হয়।
তারপর দেখুন ওয়ার্কস্টেশন আউটবাউন্ডে আসলে কোথায় পৌঁছাতে পারে, কারণ উপরের প্রতিটি ডিজাইন তার ওপর নির্ভর করে। আপনি যে হোস্টনেম ব্যবহার করতে চান তা বসিয়ে এটি ওয়ার্কস্টেশনে চালান।
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comকেবল তখনই ডিজাইনটি গ্রহণ করুন যখন অনুমোদিত পরিচয়ে অভীষ্ট দূরবর্তী কাজটি সফল হয়, অননুমোদিত পরিচয় প্রত্যাখ্যাত হয়, এবং সরাসরি বা রিলে পথ অনুপলব্ধ হলে কী আচরণ হবে তা জানা ও নথিভুক্ত থাকে। পুনঃসংযোগ এবং ওয়ার্কস্টেশনের স্বাভাবিক স্টার্টআপ প্রেক্ষাপট অন্তর্ভুক্ত করুন, কারণ অফিসে LAN দিয়ে শুরু হওয়া সেশন দূরবর্তী প্রবেশাধিকার নির্ভর করে এমন কিছুই পরীক্ষা করে না।