STUN Server: এটি কী, কীভাবে কাজ করে এবং কোথায় ব্যবহৃত হয়

STUN Server কী

STUN Server (Session Traversal Utilities for NAT) হল একটি নেটওয়ার্ক পরিষেবা যা RFC 5389-এ সংজ্ঞায়িত এবং RFC 8489-তে আপডেট করা প্রোটোকলের উপর কাজ করে। STUN সার্ভারের প্রধান কাজ হল ক্লায়েন্টকে তার নিজস্ব পাবলিক IP ঠিকানা এবং পোর্ট সম্পর্কে তথ্য প্রদান করা যেমনটি বাহ্যিক নেটওয়ার্ক থেকে দেখা যায়, পাশাপাশি ক্লায়েন্ট এবং ইন্টারনেটের মধ্যে NAT ডিভাইসের ধরন নির্ধারণ করা।

STUN আর্কিটেকচারে দুটি উপাদান অন্তর্ভুক্ত: একটি STUN ক্লায়েন্ট যা অ্যাপ্লিকেশনে (যেমন ব্রাউজার বা নেটিভ WebRTC অ্যাপ) এম্বেড করা থাকে এবং একটি STUN সার্ভার যা পাবলিক নেটওয়ার্কে স্থাপন করা হয়। ক্লায়েন্ট সার্ভারে একটি STUN বাইন্ডিং রিকোয়েস্ট পাঠায়, যা তার উত্তরে অনুরোধের উৎস IP ঠিকানা এবং পোর্ট নির্দেশ করে — অর্থাৎ ক্লায়েন্টের পাবলিক ঠিকানাগুলি যেমন সার্ভার দেখে। এই ডেটার সাথে তার স্থানীয় ঠিকানাগুলি তুলনা করে, ক্লায়েন্ট নির্ধারণ করতে পারে যে তার নেটওয়ার্কে কী ধরনের NAT ব্যবহার করা হচ্ছে।

STUN প্রোটোকল

STUN UDP (ডিফল্টভাবে পোর্ট 3478) বা TCP (পোর্ট 3478 বা TLS-এর জন্য 5349) এর উপর কাজ করে। একটি STUN বার্তায় 20-বাইটের হেডার এবং পরিবর্তনশীল সংখ্যক অ্যাট্রিবিউট থাকে। হেডারে বার্তার ধরন (বাইন্ডিং রিকোয়েস্ট, বাইন্ডিং রেসপন্স, বাইন্ডিং এরর রেসপন্স), দৈর্ঘ্য এবং একটি অনন্য লেনদেন শনাক্তকারী (96 বিট) থাকে যা অনুরোধ এবং প্রতিক্রিয়া মেলানোর অনুমতি দেয়। প্রতিটি বাইন্ডিং রেসপন্সে XOR-MAPPED-ADDRESS অ্যাট্রিবিউট থাকে — ক্লায়েন্টের বাহ্যিক ঠিকানা, যা STUN ট্রাফিক ইন্টারসেপশনের উপর ভিত্তি করে আক্রমণ থেকে রক্ষা করার জন্য মাস্কিং সহ এনকোড করা হয়।

STUN সার্ভার কীভাবে কাজ করে

একটি STUN সার্ভার একটি সাধারণ অনুরোধ-প্রতিক্রিয়া প্রোটোকলের উপর কাজ করে। NAT-এর পিছনের ক্লায়েন্ট একটি বাইন্ডিং রিকোয়েস্ট তৈরি করে এবং STUN সার্ভারে পাঠায়। সার্ভার প্যাকেটটি গ্রহণ করে, UDP হেডার থেকে উৎস IP ঠিকানা এবং প্রেরকের পোর্ট বের করে, তারপর একটি বাইন্ডিং রেসপন্স তৈরি করে, এই ঠিকানাটি XOR-MAPPED-ADDRESS অ্যাট্রিবিউটে প্যাকেজ করে। প্রতিক্রিয়াটি অনুরোধের উৎস ঠিকানায় ফেরত পাঠানো হয়।

ক্লায়েন্ট প্রতিক্রিয়া গ্রহণ করে এবং XOR-MAPPED-ADDRESS বের করে, যাতে NAT ডিভাইস দ্বারা নির্ধারিত বাহ্যিক IP ঠিকানা এবং পোর্ট থাকে। তারপর ক্লায়েন্ট এই ঠিকানাটি তার স্থানীয় (RFC 1919 — প্রাইভেট) ঠিকানার সাথে তুলনা করে। যদি ঠিকানাগুলি মেলে — ক্লায়েন্ট NAT-এর পিছনে নেই। যদি ভিন্ন হয় — ক্লায়েন্ট NAT-এর পিছনে আছে, এবং বাহ্যিক ঠিকানাটি WebRTC-তে ICE (ইন্টারঅ্যাকটিভ কানেকটিভিটি এস্টাব্লিশমেন্ট)-এর জন্য প্রার্থী হিসাবে ব্যবহৃত হয়।

NAT আবিষ্কার প্রক্রিয়া

STUN সার্ভার পরীক্ষামূলক অনুরোধের একটি ক্রমের মাধ্যমে NAT ধরন নির্ধারণের অনুমতি দেয়। ক্লায়েন্ট বিভিন্ন ফ্ল্যাগ (CHANGE-REQUEST) সহ অনুরোধ পাঠায় এবং প্রতিক্রিয়া বিশ্লেষণ করে। সম্পূর্ণ আবিষ্কার চক্র STUN সার্ভারের বিভিন্ন IP ঠিকানা এবং পোর্টে অনুরোধ পাঠানো অন্তর্ভুক্ত করে। যদি সার্ভার পরিবর্তিত পোর্টের সাথে অনুরোধের উত্তর দেয় — NAT রেস্ট্রিক্টেড কôn ধরনের। যদি এটি পরিবর্তিত পোর্ট এবং IP সহ অনুরোধের উত্তর না দেয় — NAT সিমেট্রিক ধরনের। এই তথ্য WebRTC-তে ICE কৌশল বেছে নেওয়ার জন্য গুরুত্বপূর্ণ।

STUN সার্ভার এবং NAT ধরন

একটি STUN সার্ভার চারটি প্রধান ধরনের NAT সনাক্ত করতে পারে, যার প্রতিটি P2P সংযোগ স্থাপনের ক্ষমতাকে ভিন্নভাবে প্রভাবিত করে। NAT ধরন নির্ধারণ করে যে STUN দুটি ক্লায়েন্টের মধ্যে সরাসরি সংযোগ সক্ষম করতে পারে কিনা। এটি আরও নির্ধারণ করে যে সংযোগের জন্য কোন ICE প্রার্থী — host, server reflexive বা relay — ব্যবহার করা হবে।

Symmetric NAT হল একমাত্র ধরন যা STUN মোকাবেলা করতে পারে না। Symmetric NAT-এর সাথে, একটি নতুন গন্তব্য হোস্টের জন্য প্রতিটি নতুন অনুরোধ একটি ভিন্ন বাহ্যিক ঠিকানা (IP এবং/অথবা পোর্ট) পায়। যেহেতু STUN সার্ভার নিজেই STUN সার্ভারের সাথে সংযোগের জন্য ঠিকানা রিপোর্ট করে, এই ঠিকানাটি অন্য ক্লায়েন্টের সাথে সংযোগের জন্য অনুপযুক্ত। এই ধরনের ক্ষেত্রে, WebRTC ট্রাফিক রিলে করার জন্য TURN সার্ভার ব্যবহার করে। গবেষণা অনুসারে (Ford et al., RFC 3489, 2003), ইন্টারনেটে প্রায় 8-10% NAT ডিভাইস সিমেট্রিক।

WebRTC-তে STUN সার্ভারের ব্যবহার

STUN সার্ভার RTCPeerConnection কনফিগারেশনের মাধ্যমে WebRTC-তে একীভূত হয়। ব্রাউজার বা নেটিভ অ্যাপ্লিকেশন ICE প্রার্থী সংগ্রহ করতে STUN ব্যবহার করে, যা পরে সিগন্যালিং সার্ভারের মাধ্যমে বিনিময় করা হয়। WebRTC কনফিগারেশনে, STUN সার্ভার iceServers অ্যারেতে UDP-এর জন্য stun: উপসর্গ বা TLS সংযোগের জন্য stuns: সহ উল্লেখ করা হয়।

আসুন একটি WebRTC অ্যাপ্লিকেশনের জন্য RTCPeerConnection তৈরি করার সময় JavaScript-এ STUN সার্ভার সেটআপের একটি উদাহরণ দেখি।

const config = {
    iceServers: [
        {
            urls: "stun:stun.l.google.com:19302"
        },
        {
            urls: "stun:stun1.l.google.com:19302"
        }
    ]
};

const pc = new RTCPeerConnection(config);

pc.onicecandidate = (event) => {
    if (event.candidate) {
        console.log("ICE প্রার্থী:", event.candidate.candidate);
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

এই উদাহরণে Google-এর পাবলিক STUN সার্ভার (stun.l.google.com:19302) ব্যবহার করা হয়েছে। offer বা answer তৈরি করার সময়, ব্রাউজার স্বয়ংক্রিয়ভাবে নির্দিষ্ট সার্ভারগুলিতে STUN বাইন্ডিং রিকোয়েস্ট পাঠায়, বাহ্যিক ঠিকানা (server reflexive প্রার্থী) গ্রহণ করে এবং এটি ICE প্রার্থীদের তালিকায় যোগ করে। সমস্ত প্রার্থী সংগ্রহ করার পর, তারা সরাসরি P2P সংযোগ স্থাপনের প্রচেষ্টার জন্য সিগন্যালিং সার্ভারের মাধ্যমে দূরবর্তী পিয়ারের কাছে পাঠানো হয়।

ICE প্রার্থীর ধরন এবং STUN

ICE প্রক্রিয়ায় তিন ধরনের প্রার্থী রয়েছে: host (স্থানীয় ঠিকানা), srflx (server reflexive — STUN থেকে প্রাপ্ত) এবং relay (TURN-এর মাধ্যমে রিলে করা)। STUN সার্ভার srflx প্রার্থী তৈরি করতে সক্ষম করে, যাদের relay প্রার্থীদের চেয়ে উচ্চ অগ্রাধিকার থাকে কারণ STUN-ভিত্তিক সংযোগ সরাসরি এবং রিলে করার প্রয়োজন হয় না। ICE প্রক্রিয়া উভয় পিয়ারের সমস্ত প্রার্থী সংমিশ্রণ (স্থানীয় এবং STUN থেকে প্রাপ্ত) পরীক্ষা করে, সর্বোচ্চ অগ্রাধিকার থেকে শুরু করে।

STUN প্রোটোকলের সীমাবদ্ধতা

STUN সার্ভার-এর প্রোটোকল আর্কিটেকচারের সাথে সম্পর্কিত মৌলিক সীমাবদ্ধতা রয়েছে। প্রধান সীমাবদ্ধতা হল Symmetric NAT-এর সাথে কাজ করতে অক্ষমতা, যেখানে প্রতিটি বাহ্যিক হোস্টের নতুন অনুরোধ একটি অনন্য বাহ্যিক পোর্ট পায়। এই ক্ষেত্রে, STUN সার্ভার থেকে প্রাপ্ত ঠিকানাটি অন্য পিয়ারের সাথে সংযোগ করতে ব্যবহার করা যায় না কারণ NAT শুধুমাত্র STUN সার্ভারের সাথে যোগাযোগের জন্য বাইন্ডিং তৈরি করেছে।

দ্বিতীয় সীমাবদ্ধতা হল STUN ডেটা রিলে প্রদান করে না। যদি সরাসরি P2P সংযোগ অসম্ভব হয় (উভয় পিয়ার Symmetric NAT-এর পিছনে), STUN ডেটা ট্রান্সমিশনের জন্য কোনো বিকল্প পথ প্রদান করে না। এই ক্ষেত্রে, TURN সার্ভারের প্রয়োজন হয়, যা পিয়ারদের মধ্যে মিডিয়া ট্রাফিক রিলে হিসাবে কাজ করে, একজন অংশগ্রহণকারীর কাছ থেকে ডেটা গ্রহণ করে এবং তার পাবলিক IP ঠিকানার মাধ্যমে অন্যজনের কাছে পাঠায়।

• Symmetric NAT — STUN সিমেট্রিক NAT-এর সাথে কাজ করে না কারণ বাহ্যিক ঠিকানা প্রতিটি গন্তব্য হোস্টের জন্য অনন্য এবং P2P-এর জন্য পুনরায় ব্যবহার করা যায় না।
• ফায়ারওয়াল ডিপ প্যাকেট ইন্সপেকশন — কিছু ফায়ারওয়াল পোর্ট 3478-এ UDP প্যাকেটে প্রোটোকল স্বাক্ষর শনাক্ত করে STUN ট্রাফিক ব্লক করে।
• IPv6 — IPv6 নেটওয়ার্কে, NAT সাধারণত ব্যবহার করা হয় না, তাই STUN প্রয়োজন হয় না, তবে IPv6-এ WebRTC STUN বা TURN-এর প্রয়োজন ছাড়াই host প্রার্থী ব্যবহার করতে পারে।
• উপলভ্যতার উপর নির্ভরতা — STUN সার্ভার সংযোগ স্থাপন পর্যায়ে ক্লায়েন্টের জন্য অ্যাক্সেসযোগ্য হতে হবে, অন্যথায় srflx প্রার্থী সংগ্রহ করা হবে না।
• নিরাপত্তা — STUN প্রোটোকল এমপ্লিফিকেশন আক্রমণের জন্য ঝুঁকিপূর্ণ যদি সার্ভার ভুলভাবে কনফিগার করা হয় এবং জাল উৎস ঠিকানা সহ অনুরোধের উত্তর দেয়।

সীমাবদ্ধতা সত্ত্বেও, STUN সার্ভার WebRTC অবকাঠামোর একটি গুরুত্বপূর্ণ উপাদান রয়ে গেছে। বেশিরভাগ ক্ষেত্রে (80-90%), STUN ব্যবহার করে সরাসরি P2P সংযোগ স্থাপন করা যায়, যা TURN রিলে-এর খরচ এড়ায় এবং মিডিয়া ডেটা ট্রান্সমিশন লেটেন্সি হ্রাস করে। পাবলিক WebRTC অ্যাপ্লিকেশনের জন্য, যেকোনো নেটওয়ার্ক অবস্থায় সংযোগের গ্যারান্টি দিতে স্বয়ংক্রিয় ফallback সহ STUN এবং TURN সার্ভারের সংমিশ্রণ ব্যবহার করার পরামর্শ দেওয়া হয়।