STUN Server: มันคืออะไร ทำงานอย่างไร และใช้ที่ไหน

เซิร์ฟเวอร์ STUN คืออะไร

STUN Server (Session Traversal Utilities for NAT) เป็นบริการเครือข่ายที่ทำงานตามโปรโตคอลที่กำหนดใน RFC 5389 และอัปเดตใน RFC 8489 งานหลักของเซิร์ฟเวอร์ STUN คือการให้ข้อมูลแก่ไคลเอ็นต์เกี่ยวกับที่อยู่ IP สาธารณะและพอร์ตของตนเองตามที่เห็นจากเครือข่ายภายนอก รวมถึงการระบุประเภทของอุปกรณ์ NAT ระหว่างไคลเอ็นต์และอินเทอร์เน็ต

โครงสร้าง STUN ประกอบด้วยสองส่วนประกอบ: ไคลเอ็นต์ STUN ที่ฝังอยู่ในแอปพลิเคชัน (เช่น เบราว์เซอร์หรือแอปพลิเคชัน WebRTC ดั้งเดิม) และ เซิร์ฟเวอร์ STUN ที่ติดตั้งในเครือข่ายสาธารณะ ไคลเอ็นต์ส่ง Binding Request ไปยังเซิร์ฟเวอร์ ซึ่งในการตอบกลับจะระบุที่อยู่ IP ต้นทางและพอร์ตของคำขอ — นั่นคือที่อยู่สาธารณะของไคลเอ็นต์ตามที่เซิร์ฟเวอร์เห็น โดยการเปรียบเทียบข้อมูลนี้กับที่อยู่ท้องถิ่นของตน ไคลเอ็นต์สามารถระบุได้ว่าใช้ NAT ประเภทใดในเครือข่ายของตน

โปรโตคอล STUN

STUN ทำงานผ่าน UDP (พอร์ต 3478 โดยค่าเริ่มต้น) หรือ TCP (พอร์ต 3478 หรือ 5349 สำหรับ TLS) ข้อความ STUN ประกอบด้วยส่วนหัว 20 ไบต์และจำนวนแอตทริบิวต์ที่แปรผันได้ ส่วนหัวประกอบด้วยประเภทข้อความ (Binding Request, Binding Response, Binding Error Response) ความยาว และตัวระบุธุรกรรมที่ไม่ซ้ำกัน (96 บิต) ที่ช่วยให้สามารถจับคู่คำขอและการตอบกลับได้ แต่ละ Binding Response ประกอบด้วยแอตทริบิวต์ XOR-MAPPED-ADDRESS — ที่อยู่ภายนอกของไคลเอ็นต์ ที่ถูกเข้ารหัสโดยใช้การซ่อนเพื่อป้องกันการโจมตีบนพื้นฐานการดักจับทราฟฟิก STUN

เซิร์ฟเวอร์ STUN ทำงานอย่างไร

เซิร์ฟเวอร์ STUN ทำงานตามโปรโตคอลคำขอ-การตอบกลับที่ง่าย ไคลเอ็นต์ที่อยู่เบื้องหลัง NAT สร้าง Binding Request และส่งไปยังเซิร์ฟเวอร์ STUN เซิร์ฟเวอร์รับแพ็กเกต แยกที่อยู่ IP ต้นทางและพอร์ตของผู้ส่งจากส่วนหัว UDP จากนั้นสร้าง Binding Response โดยบรรจุที่อยู่นี้ในแอตทริบิวต์ XOR-MAPPED-ADDRESS การตอบกลับจะถูกส่งกลับไปยังที่อยู่ต้นทางของคำขอ

ไคลเอ็นต์รับการตอบกลับและแยก XOR-MAPPED-ADDRESS ซึ่งประกอบด้วยที่อยู่ IP ภายนอกและพอร์ตที่กำหนดโดยอุปกรณ์ NAT จากนั้นไคลเอ็นต์เปรียบเทียบที่อยู่นี้กับที่อยู่ท้องถิ่น (RFC 1919 — ส่วนตัว) ของตน หากที่อยู่ตรงกัน — แสดงว่าไคลเอ็นต์ไม่ได้อยู่เบื้องหลัง NAT หากแตกต่างกัน — ไคลเอ็นต์อยู่เบื้องหลัง NAT และที่อยู่ภายนอกจะถูกใช้เป็นผู้สมัครสำหรับ ICE (Interactive Connectivity Establishment) ใน WebRTC

กระบวนการค้นหา NAT

เซิร์ฟเวอร์ STUN ช่วยให้สามารถระบุประเภท NAT ผ่านลำดับของคำขอทดสอบ ไคลเอ็นต์ส่งคำขอด้วยแฟลกต่างๆ (CHANGE-REQUEST) และวิเคราะห์การตอบกลับ วงจรการค้นหาแบบเต็ม รวมถึงการส่งคำขอไปยังที่อยู่ IP และพอร์ตต่างๆ ของเซิร์ฟเวอร์ STUN หากเซิร์ฟเวอร์ตอบกลับคำขอที่มีพอร์ตเปลี่ยนแปลง — NAT เป็นประเภท Restricted Cone หากไม่ตอบกลับคำขอที่มีพอร์ตและ IP เปลี่ยนแปลง — NAT เป็นประเภท Symmetric ข้อมูลนี้สำคัญต่อการเลือกกลยุทธ์ ICE ใน WebRTC

เซิร์ฟเวอร์ 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 ทั้งหมดบนอินเทอร์เน็ตเป็นแบบสมมาตร

การใช้เซิร์ฟเวอร์ STUN ใน WebRTC

เซิร์ฟเวอร์ STUN ถูกรวมเข้ากับ WebRTC ผ่านการกำหนดค่า RTCPeerConnection เบราว์เซอร์หรือแอปพลิเคชันดั้งเดิมใช้ STUN เพื่อรวบรวมผู้สมัคร ICE ซึ่งจะถูกแลกเปลี่ยนผ่าน Signaling Server ในการกำหนดค่า WebRTC เซิร์ฟเวอร์ STUN จะถูกระบุในอาร์เรย์ iceServers โดยใช้คำนำหน้า stun: สำหรับ UDP หรือ stuns: สำหรับการเชื่อมต่อ TLS

ลองพิจารณาตัวอย่างการตั้งค่าเซิร์ฟเวอร์ STUN ใน JavaScript เมื่อสร้าง RTCPeerConnection สำหรับแอปพลิเคชัน WebRTC

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);

ตัวอย่างนี้ใช้ เซิร์ฟเวอร์ STUN สาธารณะของ Google (stun.l.google.com:19302) เมื่อสร้าง offer หรือ answer เบราว์เซอร์จะส่ง Binding Request STUN ไปยังเซิร์ฟเวอร์ที่ระบุโดยอัตโนมัติ รับที่อยู่ภายนอก (ผู้สมัคร server reflexive) และเพิ่มลงในรายการผู้สมัคร ICE หลังจากรวบรวมผู้สมัครทั้งหมดแล้ว พวกมันจะถูกส่งไปยังเพียร์ระยะไกลผ่าน Signaling Server เพื่อพยายามสร้างการเชื่อมต่อ 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
• ไฟร์วอลล์ที่ตรวจสอบแพ็กเกตแบบลึก — ไฟร์วอลล์บางตัวกันทราฟฟิก STUN โดยการตรวจจับลายเซ็นของโปรโตคอลในแพ็กเกต UDP บนพอร์ต 3478
• IPv6 — ในเครือข่าย IPv6 โดยทั่วไปไม่ใช้ NAT ดังนั้นไม่จำเป็นต้องใช้ STUN แต่ WebRTC บน IPv6 สามารถใช้ผู้สมัคร host โดยไม่ต้องใช้ STUN หรือ TURN
• การพึ่งพาความพร้อมใช้งาน — เซิร์ฟเวอร์ STUN ต้องสามารถเข้าถึงได้สำหรับไคลเอ็นต์ในช่วงขั้นตอนการสร้างการเชื่อมต่อ มิฉะนั้นผู้สมัคร srflx จะไม่ถูกรวบรวม
• ความปลอดภัย — โปรโตคอล STUN มีความเสี่ยงต่อการโจมตีแบบขยาย (amplification attack) หากเซิร์ฟเวอร์ถูกกำหนดค่าไม่ถูกต้องและตอบกลับคำขอที่มีที่อยู่ต้นทางปลอม

แม้จะมีข้อจำกัด แต่ เซิร์ฟเวอร์ STUN ยังคงเป็นส่วนประกอบสำคัญของโครงสร้างพื้นฐาน WebRTC ในกรณีส่วนใหญ่ (80–90%) การเชื่อมต่อ P2P โดยตรงสามารถสร้างได้โดยใช้ STUN ซึ่งช่วยหลีกเลี่ยงค่าใช้จ่ายของการส่งต่อแบบ TURN และลดความหน่วงในการส่งข้อมูลสื่อ สำหรับแอปพลิเคชัน WebRTC สาธารณะ แนะนำให้ใช้การผสมผสานของเซิร์ฟเวอร์ STUN และ TURN ร่วมกับการสำรองอัตโนมัติเพื่อรับประกันการเชื่อมต่อในทุกสภาวะเครือข่าย