أساسيات الشبكات لـ DevOps

NAT والبروكسي والبوابات

18 دقيقة الدرس 8 من 30

NAT والبروكسي والبوابات

كل بيئة إنتاجية سحابية تُخفي مساحة عناوينها الداخلية عن الإنترنت العام. الخوادم في الشبكات الفرعية الخاصة لا تملك عناوين IP قابلة للتوجيه، ومع ذلك تستطيع الوصول إلى سجلات npm، وسحب صور الحاويات من Docker Hub، واستقبال حركة HTTPS من ملايين المستخدمين. ثلاثة آليات تُحقق ذلك: ترجمة عناوين الشبكة (NAT)، والبروكسي، والبوابات (Gateways). يُحلّل هذا الدرس الثلاثة على مستوى الحزم ويربطها بالأنماط التي ستضبطها يومياً بوصفك مهندس DevOps.

ترجمة عناوين الشبكة (NAT)

يُعيد NAT كتابة عناوين IP (وأرقام منافذ TCP/UDP) في ترويسات الحزم عند مرورها عبر جهاز توجيه أو جدار حماية. هناك نوعان حرجان في الإنتاج.

SNAT — ترجمة عنوان المصدر

ترجمة عنوان المصدر (SNAT) تستبدل عنوان IP المصدر في الحزم الصادرة. نسختك الخاصة على 10.0.1.42 تريد الوصول إلى 54.230.10.1. قبل مغادرة الحزمة من VPC، يُعيد جهاز NAT كتابة المصدر إلى IP العام الخاص به (مثلاً 52.1.2.3) ويُسجّل الربط في جدول تتبع الاتصالات. عند وصول الرد إلى 52.1.2.3، يُراجع الجهاز الجدول، يُعيد كتابة الوجهة إلى 10.0.1.42، ويُحوّل الحزمة للداخل. يرى الخادم الخارجي IP العام فقط — ولا يعلم أن العنوان الخاص موجود أصلاً.

في AWS، تنفّذ NAT Gateway عملية SNAT للشبكات الفرعية الخاصة. في Linux، يُنجز iptables الأمر نفسه بقاعدة واحدة:

# SNAT لجميع حركة البيانات الخارجة من eth0 باستخدام IP الواجهة العام
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# أو التثبيت على IP محدد (أكثر قابلية للتنبؤ؛ يُفضّل في الإنتاج)
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 52.1.2.3

# فحص جدول تتبع الاتصالات
conntrack -L -p tcp --dport 443

MASQUERADE مناسب للعناوين الديناميكية (أجهزة التوجيه المنزلية، النسخ الموقتة) لأنه يقرأ عنوان الواجهة الحالي تلقائياً. لبوابات NAT الإنتاجية ذات Elastic IPs الثابتة، استخدم دائماً SNAT --to-source لضمان سلوك حتمي بعد إعادة التشغيل.

DNAT — ترجمة عنوان الوجهة

ترجمة عنوان الوجهة (DNAT) تستبدل عنوان IP الوجهة. تصل حزمة إلى IP العام على المنفذ 443، فيُعيد جدار الحماية كتابة الوجهة إلى خادم داخلي على 10.0.2.80:8443 قبل التوجيه. هكذا تعمل موازنات الحمل المعدنية وقواعد إعادة توجيه المنافذ — وهو بالضبط ما يحدث داخل كل موازن حمل شبكي (NLB) على مستوى الحزم.

# DNAT: إعادة توجيه المنفذ 443 العام إلى الخادم الداخلي
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 \
  -j DNAT --to-destination 10.0.2.80:8443

# السماح بمرور حركة البيانات المُعاد توجيهها عبر سلسلة FORWARD
iptables -A FORWARD -p tcp -d 10.0.2.80 --dport 8443 -j ACCEPT

# تفعيل IP forwarding (يجب أن يكون مُفعّلاً)
sysctl -w net.ipv4.ip_forward=1

تتبع الحالة هو المفتاح. يعمل NAT فقط لأن النواة تحتفظ بجدول تتبع الاتصالات (conntrack) الذي يربط التدفقات الصادرة بردودها الواردة. يحتوي كل إدخال على: البروتوكول، IP المصدر:المنفذ، IP المُترجَم:المنفذ، IP الوجهة:المنفذ، والحالة (SYN_SENT, ESTABLISHED, TIME_WAIT…). تنتهي الإدخالات تلقائياً، لكن الأنظمة عالية الحركة قد تستنفد جدول conntrack — تحقق من nf_conntrack_count مقابل nf_conntrack_max قبل أن يكتشفها حادث إنتاجي.

يُعيد SNAT كتابة عنوان المصدر عند الخروج؛ يُعيد DNAT كتابة عنوان الوجهة عند الدخول. كلاهما يستخدم جدول conntrack نفسه لعكس الترجمة في الردود.

البروكسي الأمامي (Forward Proxy)

يجلس البروكسي الأمامي بين العملاء الداخليين والإنترنت. يُضبط العملاء لتوجيه جميع الطلبات الصادرة عبره. يُنجز البروكسي الاتصال الفعلي نيابةً عنهم، ويُعيد الرد. من منظور خادم الأصل، جاء الطلب من البروكسي.

يظهر البروكسي الأمامي في المؤسسات الكبيرة لثلاثة أسباب: التحكم في الخروج (السماح بوجهات محددة فقط)، وفحص TLS (فك التشفير، الفحص لحماية البيانات، إعادة التشفير)، والتخزين المؤقت (تقليل تكاليف النطاق الترددي لسجلات الحزم).

# Squid forward proxy — /etc/squid/squid.conf (التوجيهات الرئيسية)
http_port 3128
acl localnet src 10.0.0.0/8
acl SSL_ports port 443
acl CONNECT method CONNECT

# السماح للعملاء الداخليين
http_access allow localnet

# السماح بنطاقات محددة فقط (نمط egress بالقائمة البيضاء)
acl allowed_domains dstdomain .amazonaws.com .docker.io .npmjs.com
http_access allow allowed_domains
http_access deny all

# على أجهزة العميل — تصدير متغيرات البيئة (يلتقطها curl و apt و pip)
export http_proxy=http://10.0.3.10:3128
export https_proxy=http://10.0.3.10:3128
export no_proxy=169.254.169.254,10.0.0.0/8

نمط egress الإنتاجي: في البيئات الخاضعة للتنظيم (PCI-DSS، HIPAA، SOC 2)، يمر جميع الخروج عبر بروكسي أمامي بسياسة رفض الكل مع استثناءات القائمة البيضاء. يضمن هذا أن الحمل المُعرَّض للخطر لا يستطيع تسريب البيانات إلى بنية المهاجم — يمكنه فقط الوصول إلى الوجهات المعتمدة مسبقاً. يجب أن يستثني no_proxy دائماً IP بيانات تعريف النسخة (169.254.169.254) وإلا ستفقد نسخ EC2/GCE بيانات اعتماد IAM الخاصة بها.

البروكسي العكسي (Reverse Proxy)

يجلس البروكسي العكسي أمام خوادمك الخلفية. يتحدث العملاء إلى البروكسي معتقدين أنه الأصل. يُعيد البروكسي توجيه الطلبات إلى خادم خلفي أو أكثر، يجمع الرد، ويُعيده. لا يعلم العملاء أبداً بعناوين الخلفية.

Nginx هو البروكسي العكسي الكنسي في DevOps. إليك ضبط بروكسي عكسي HTTPS بسيط:

# /etc/nginx/sites-available/api.example.com
upstream backend {
    server 10.0.2.10:8080;
    server 10.0.2.11:8080;
    keepalive 32;          # إعادة استخدام اتصالات TCP للخلفيات
}

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate     /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;

    location / {
        proxy_pass         http://backend;
        proxy_set_header   Host              $host;
        proxy_set_header   X-Real-IP         $remote_addr;
        proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_read_timeout 60s;
    }
}

ترويسة X-Forwarded-For حرجة: تحمل IP العميل الأصلي عبر سلسلة البروكسي حتى تُظهر سجلات تطبيقك IPs الحقيقية بدلاً من عنوان البروكسي. بدونها، يبدو كل طلب صادراً من البروكسي.

البوابات: API Gateway وNAT Gateway

كلمة "بوابة" مُثقلة بالمعاني في شبكات السحابة. نوعان مهمان:

Internet Gateway (IGW) — NAT 1:1 بين IP الشبكة الفرعية العامة الخاص وElastic IP الخاص بها. يُتيح للنسخ ذات IPs العامة أن تكون قابلة للوصول مباشرة. لا حدود للنطاق الترددي، ولا ترجمة منافذ.
NAT Gateway — SNAT مُدارة للشبكات الفرعية الخاصة. تُوجّه النسخ في الشبكات الخاصة مسارها الافتراضي (0.0.0.0/0) إلى NAT Gateway، التي تُطبّق SNAT على حركة الخروج وتُعيد DNAT على الردود. مُدارة بالكامل وتتوسع تلقائياً حتى 100 Gbps.
API Gateway — يعمل على الطبقة السابعة. يُنهي HTTP/HTTPS، يُطبّق المصادقة، يُحدّد معدل الطلبات، ويُوجّه إلى الخدمات المصبّة (Lambda، EC2، الحاويات). وظيفياً هو بروكسي عكسي مع طبقة مصادقة وتحويل طلبات.

أنماط الخروج في الإنتاج

تجمع المنصات الكبيرة هذه العناصر في بُنى خروج متدرجة. الأحمال الخاصة لا تملك IPs عامة أبداً. كل حركة الخروج تتدفق عبر VPC خروج مركزي (يُسمى أحياناً "transit VPC" أو "egress VPC") يُشغّل NAT Gateway مُدارة مع بروكسي أمامي لنظام كشف التسلل. يخدم Elastic IP واحد لكل منطقة توفر كعنوان مصدر ثابت لجميع حركة الإنتاج — يُدرج موردو الطرف الثالث هذه IPs في قوائم السماح الخاصة بجدران الحماية لديهم.

استنفاد conntrack في NAT Gateway هو نمط فشل إنتاجي حقيقي. يمكن لكل NAT Gateway تتبع حتى 1,000,000 اتصال متزامن. دوال Lambda التي تُطلق آلاف الاتصالات الصادرة المتزامنة يمكنها الوصول إلى هذا الحد، مما يُسبّب إسقاطاً صامتاً لمحاولات الاتصال الجديدة. راقب CloudWatch: NatGateway ConnectionAttemptCount مقابل ConnectionEstablishedCount. الفجوة بينهما هي معدل الإسقاط. الحل: توزيع Lambda عبر NAT Gateways متعددة في AZs مختلفة، أو التحول إلى VPC Endpoint لحركة خدمات AWS (لا حاجة لـNAT أصلاً).

فهم مكان عمل كل آلية — SNAT على مستوى الحزم، البروكسي الأمامي على مستوى تطبيق HTTP، البروكسي العكسي المُنهي لـTLS، API Gateway المُطبّق للمصادقة — يُمكّنك من اختيار الأداة الصحيحة وتشخيص الأعطال بدقة. عندما يتوقف خادم خلفي عن استقبال الحركة، السؤال الأول: أي طبقة انكسرت؟ هل امتلأ جدول conntrack لـNAT، أم الخادم الخلفي للبروكسي غير صحي، أم المسار في البوابة مفقود، أم انتهت صلاحية الشهادة؟