VoIP پشت CGNAT؛ کدام روش‌ها واقعاً برای تماس پایدار جواب می‌دهند؟

VoIP پشت CGNAT کاملاً شدنی است، اما نه با Port Forward معمولی. وقتی ISP از Carrier-Grade NAT استفاده می‌کند، شما فقط NAT مودم خودتان را کنترل می‌کنید و یک لایه NAT دیگر در شبکه اپراتور وجود دارد. در نتیجه، دریافت مستقیم SIP یا RTP از اینترنت روی تلفن یا PBX پشت CGNAT معمولاً قابل اتکا نیست.

راه‌حل‌های واقعی یک اصل مشترک دارند: ارتباط باید از داخل شبکه کاربر به یک نقطه عمومی ساخته شود و همان مسیر زنده بماند. برای یک تلفن SIP، این مسیر می‌تواند Outbound Registration باشد؛ برای یک PBX کامل، VPN به یک VPS عمومی؛ برای چند شعبه، SBC عمومی؛ و برای WebRTC، ICE/TURN.

CGNAT چیست و چرا روی VoIP اثر می‌گذارد؟

CGNAT یا Carrier-Grade NAT یعنی چند مشترک ISP یک IPv4 عمومی را به‌اشتراک می‌گذارند. RFC 6598 محدوده 100.64.0.0/10 را برای Shared Address Space در شبکه اپراتورها تعریف کرده است.

اگر WAN مودم چنین وضعی داشته باشد، احتمال CGNAT زیاد است:

Router WAN IP:
100.72.18.34

Public IP seen on Internet:
203.0.113.90

مسیر در این حالت تقریباً چنین است:

Phone / PBX
   |
LAN NAT
   |
Customer Router
   |
CGNAT inside ISP
   |
Shared Public IPv4
   |
Internet

RFC 6598 حتی اشاره می‌کند بعضی SIP Clientها پشت CGN برای دریافت تماس ورودی به ترافیک خروجی قبلی یا مکانیزمی برای ایجاد مسیر از داخل نیاز دارند.

چطور بفهمیم پشت CGNAT هستیم؟

دیدن آدرس در محدوده 100.64.0.0/10 نشانه بسیار قوی است، اما نبودن آن CGNAT را صددرصد رد نمی‌کند؛ بعضی اپراتورها از طرح‌های آدرس‌دهی دیگری هم استفاده می‌کنند.

چه روش‌هایی معمولاً CGNAT را حل نمی‌کنند؟

روش ۱: Outbound Registration؛ بهترین نقطه شروع برای تلفن SIP

در این مدل تلفن یا PBX خودش REGISTER را به سرور عمومی می‌فرستد. NAT Flow از داخل ساخته می‌شود و سرور می‌تواند تماس ورودی را روی همان مسیر برگرداند.

Phone behind CGNAT
       |
       | REGISTER outbound
       v
Public PBX / SBC
       |
       | INVITE on existing flow
       v
Phone

RFC 5626 دقیقاً برای محیط‌هایی نوشته شده که Server نمی‌تواند اتصال جدیدی از بیرون به User Agent پشت NAT یا Firewall بسازد. ایده اصلی این است که UA خودش Flow را ایجاد کند و Registrar یا Proxy همان Flow را برای درخواست‌های بعدی نگه دارد.

نمونه تنظیم Endpoint پشت NAT در Asterisk

[1001]
type=endpoint
aors=1001
auth=1001-auth

rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
direct_media=no

[1001]
type=aor
max_contacts=1
remove_existing=yes

rtp_symmetric=yes باعث می‌شود RTP به همان IP/Portی برگردد که RTP از آن دریافت شده است. force_rport پاسخ SIP را به Source واقعی برمی‌گرداند، rewrite_contact Contact را با Source IP/Port هماهنگ می‌کند و direct_media=no Asterisk را در Media Path نگه می‌دارد.

روش ۲: TCP/TLS و Persistent Flow

UDP Connection واقعی ندارد و NAT Mapping آن با Timer زنده می‌ماند. RFC 4787 توضیح می‌دهد NATها برای UDP Mapping Timer دارند و Outbound Traffic می‌تواند این Mapping را Refresh کند.

برای Signaling، TCP یا TLS اغلب از UDP خام قابل‌کنترل‌تر است؛ چون Client خودش یک Connection خروجی می‌سازد و می‌تواند آن را نگه دارد.

Phone
  |
  | TLS connection initiated outbound
  v
SBC / Registrar
  |
  | reuse same flow
  v
Phone

RFC 5626 برای این سناریو Keepalive و Flow Recovery تعریف می‌کند. RFC 5923 نیز روشن می‌کند برای SIP Entityهایی که به‌دلیل NAT یا Firewall فقط در یک جهت Connection می‌سازند، مکانیزم SIP Outbound مناسب است.

Keepalive؛ چرا Registered هستیم ولی تماس ورودی نمی‌رسد؟

CGNAT State دائمی نیست. ممکن است UI تلفن هنوز «Registered» نشان دهد، اما Mapping واقعی در NAT منقضی شده باشد.

یک Interval ثابت برای همه اپراتورها وجود ندارد. RFC 4787 هم تأکید می‌کند NAT Mapping Timeout در تجهیزات مختلف متفاوت است؛ بنابراین Interval باید با شبکه واقعی تست شود.

روش ۳: SBC عمومی روی VPS

اگر چند شعبه، چند Provider یا تعداد زیادی Endpoint پشت CGNAT دارید، یک SBC با IP عمومی معماری را منظم‌تر می‌کند.

Branch A behind CGNAT ----\
                           \
Branch B behind CGNAT ------> Public SBC ---- SIP Provider
                           /
Remote phones ------------/

Media:
Endpoints ---- RTP/SRTP ---- Media Proxy ---- Provider/PBX

در این مدل Endpointها اتصال را از داخل به SBC عمومی می‌سازند. SBC می‌تواند Registration، ACL، TLS، Rate Limiting، Topology Hiding و Routing را مدیریت کند و Media Proxy نیز RTP را Anchor کند.

Kamailio در ماژول nathelper برای NAT Ping، Contact Handling و Reuse کردن TCP/TLS Connection ابزارهای مشخصی دارد.

روش ۴: VPN؛ انتخاب قوی برای PBX کامل پشت CGNAT

اگر Asterisk یا FreePBX باید داخل شرکت بماند، معمولاً ساده‌تر است کل شبکه VoIP را با یک Tunnel خروجی به VPS عمومی متصل کنید.

Office PBX
192.168.50.10
     |
     | outbound VPN tunnel
     v
Public VPS
10.80.0.1
     |
     +---- SBC
     +---- SIP Provider
     +---- Remote branches

WireGuard، ZeroTier یا NetBird می‌توانند نقش Tunnel یا Overlay را داشته باشند. مزیت اصلی این است که CGNAT دیگر لازم نیست Port ورودی SIP/RTP باز کند؛ Tunnel از داخل ساخته می‌شود.

برای پروژه‌ای که Provider فقط IP Authentication دارد، می‌توانید Public IP خود VPS را به Provider معرفی کنید و ترافیک را از Tunnel به PBX داخلی برسانید.

روش ۵: TURN؛ فقط برای Clientهای ICE/TURN-aware

TURN یک Relay عمومی برای عبور Media از NAT است. RFC 8656 توضیح می‌دهد وقتی مسیر مستقیم بین دو Host ممکن نیست، TURN Packetها را از یک Relay عمومی عبور می‌دهد.

اما TURN راه‌حل عمومی همه تلفن‌های SIP نیست. Client باید ICE/TURN را پشتیبانی کند؛ این مدل بیشتر در WebRTC دیده می‌شود.

WebRTC Client
   |
   | ICE
   v
Direct path?
   |
   +--> yes -> direct media
   |
   +--> no  -> TURN relay

TURN جای SIP Registrar، SBC یا VPN را نمی‌گیرد و چون Media از Relay عبور می‌کند، Bandwidth Server را مصرف می‌کند.

روش ۶: IPv6 عمومی

اگر ISP، PBX، Provider و Endpoint همگی IPv6 را کامل پشتیبانی کنند، مسیر IPv6 دیگر به IPv4 CGNAT وابسته نیست.

اما Global IPv6 به معنی حذف Firewall نیست؛ Endpointی که IPv6 عمومی دارد می‌تواند مستقیماً Routeable باشد، بنابراین ACL و Firewall باید دقیق تنظیم شوند.

روش ۷: Public IPv4 از ISP

گاهی ساده‌ترین انتخاب همچنان گرفتن Public IPv4 یا Static IP از ISP است؛ مخصوصاً اگر Provider فقط IP Authentication دارد یا تجهیزات Legacy از SIP Outbound، VPN یا ICE پشتیبانی خوبی ندارند.

مقایسه روش‌های VoIP پشت CGNAT

چرا STUN همیشه کافی نیست؟

STUN به Client کمک می‌کند Public Mapping را کشف کند؛ اما اگر NAT Policy اجازه ارتباط مستقیم را ندهد، دانستن Mapping کافی نیست.

STUN:
"What public mapping do I have?"

TURN:
"If direct path fails, relay my packets."

VPN:
"Build me a stable routed tunnel."

SBC:
"Control SIP and often anchor media."

این ابزارها مکمل هم هستند، نه جایگزین کامل یکدیگر.

برای PBX پشت CGNAT کدام معماری بهتر است؟

نمونه معماری شرکت با PBX داخلی پشت CGNAT

Office LAN
Asterisk 192.168.50.10
       |
       | WireGuard / Overlay
       | outbound through CGNAT
       v
VPS with Public IP
       |
       +---- SBC / SIP proxy
       +---- Media proxy
       |
       v
SIP Provider

Provider فقط Public IP VPS را می‌بیند، PBX داخلی از طریق Tunnel ثابت به Edge وصل است و تغییر CGN Mapping روی Trunk اثر مستقیم ندارد.

نمونه معماری تلفن Remote پشت اینترنت خانگی یا موبایل

Remote phone
   |
   | SIP TLS outbound
   | Registration + keepalive
   v
Public PBX/SBC
   |
   | RTP anchored
   v
Provider / other extensions

برای یک Endpoint منفرد معمولاً لازم نیست VPN اجباری باشد؛ مگر اینکه Policy امنیتی، ISP یا رفتار NAT همان شبکه استفاده از Tunnel را ضروری کند.

مشکل‌هایی که بعد از چند دقیقه ظاهر می‌شوند

در Asterisk چه چیزی را بررسی کنیم؟

Contactها:

asterisk -rx "pjsip show contacts"

Endpoint:

asterisk -rx "pjsip show endpoint 1001"

Trace:

asterisk -rvvv
pjsip set logger on

در REGISTER به Contact، Source IP/Port، Via، received و rport دقت کنید. بعد از تست Logger را خاموش کنید.

Packet Capture؛ Flow را از دید سرور عمومی ببینید

tcpdump -ni any -s0 \
  -w /tmp/cgnat-voip.pcap \
  'udp port 5060 or tcp port 5060 or tcp port 5061'

اگر SIP روی TLS باشد، Payload رمزنگاری شده است، اما Source/Destination، TCP Session، Disconnect و Reconnect همچنان در PCAP دیده می‌شوند. برای متن SIP از Log داخلی PBX/SBC استفاده کنید.

امنیت؛ CGNAT جای Firewall نیست

چک‌لیست انتخاب روش

پرسش‌های رایج

VoIP پشت CGNAT کار می‌کند؟

بله. بهترین معماری این است که اتصال از داخل شبکه به یک سرور عمومی ایجاد شود. Outbound Registration، SBC، VPN و در WebRTC استفاده از TURN روش‌های رایج‌اند.

آیا Port Forward روی مودم CGNAT را حل می‌کند؟

معمولاً خیر. Port Forward فقط NAT روتر خودتان را کنترل می‌کند و NAT بالادستی ISP همچنان خارج از کنترل شماست.

TCP یا TLS بهتر از UDP است؟

برای Signaling پشت CGNAT اغلب قابل‌کنترل‌تر است چون Client یک Flow خروجی Connection-oriented می‌سازد؛ با این حال Keepalive، Reconnect و پشتیبانی Server از Reuse همان Flow همچنان لازم است.

آیا VPN بهترین راه است؟

برای PBX کامل یا شبکه یک شعبه پشت CGNAT، VPN به یک VPS عمومی معمولاً بسیار پایدار و قابل‌کنترل است. برای یک تلفن منفرد ممکن است Outbound Registration ساده‌تر باشد.

آیا TURN برای همه تلفن‌های SIP کار می‌کند؟

خیر. TURN بیشتر برای Clientهایی مناسب است که ICE/TURN را پشتیبانی می‌کنند، به‌خصوص WebRTC. تلفن SIP معمولی الزاماً TURN را نمی‌شناسد.

چرا تلفن Registered است ولی تماس ورودی نمی‌گیرد؟

ممکن است NAT/CGNAT Flow منقضی شده باشد ولی UI تلفن هنوز Registration قبلی را نشان دهد. Keepalive، Re-registration و Contact واقعی سمت Registrar را بررسی کنید.

آیا IPv6 CGNAT را حل می‌کند؟

اگر ISP، PBX، Provider و Endpoint همگی IPv6 را کامل پشتیبانی کنند، برای مسیر IPv6 دیگر به IPv4 CGNAT وابسته نیستید؛ اما Firewall و Security همچنان ضروری‌اند.

برای Trunk با IP Authentication چه کنیم؟

بهتر است یک SBC یا VPS با Public IP جلوی PBX قرار دهید یا از ISP Public IP بگیرید. IP Authentication مستقیم روی PBX پشت CGNAT معماری مناسبی نیست.