Nebula Overlay Mesh VPN לתשתית מבוזרת

אנו מתקינים את Nebula—VPN רשת-על מסוג mesh מבית Slack—עבור תשתיות מבוזרות, כאשר VPN קלאסיים מתקשים עם ענן מרובה וקצה. בניגוד ל-WireGuard, אין צורך להגדיר ידנית כל עמית. ה-lighthouse מטפל ב-bootstrapping וב-hole punching, בעוד שהתעבורה בין הצמתים עוברת peer-to-peer. אנו משתמשים ב-Nebula בפרויקטים עבור לקוחות שהתשתית שלהם מפוזרת על פני עננים מרובים, מרכזי נתונים ומיקומי קצה. זה פותר בעיות קישוריות שטונלים רגילים לא יכולים להתמודד איתן. אם יש לכם משימות דומות, צרו קשר—נעריך את התשתית שלכם ונציע תוכנית שילוב של Nebula.

כיצד פועלת רשת-העל

כל צומת מקבל תעודה חתומה על ידי CA. התעודה מכילה את כתובת ה-IP של רשת-העל, קבוצות ותקופת תוקף. אין PSK, אין IKE—האימות הוא תעודה בלבד. תעודה שנפגעה ניתנת לביטול על ידי הוספתה ל-CRL ב-lighthouse. לפי התיעוד הרשמי של Nebula, ה-lighthouse אינו מעביר תעבורה בין עמיתים.

יצירת ה-CA ותעודות הצמתים:

# Создаём CA (один раз, ключ храним в Vault или HSM)
nebula-cert ca -name "Infra CA" -duration 8760h

# Сертификат для lighthouse
nebula-cert sign -name "lighthouse-01" \
  -ip "10.100.0.1/24" \
  -groups "lighthouses"

# Сертификат для production-сервера
nebula-cert sign -name "web-prod-01" \
  -ip "10.100.1.10/24" \
  -groups "prod,web"

# Сертификат для staging
nebula-cert sign -name "web-staging-01" \
  -ip "10.100.2.10/24" \
  -groups "staging,web"

הגדרת Lighthouse

lighthouse הוא רק צומת עם IP ציבורי והגדרה סטטית. הוא אינו מנתב תעבורה—הוא רק עוזר לצמתים למצוא זה את זה. לפי תיעוד Nebula, ה-lighthouse אינו משתתף בניתוב תעבורה.

# /etc/nebula/config.yaml на lighthouse
pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/lighthouse.crt
  key: /etc/nebula/lighthouse.key
static_host_map: {}
lighthouse:
  am_lighthouse: true
  serve_dns: false
  listen:
    host: 0.0.0.0
    port: 4242
firewall:
  inbound:
    - port: any
      proto: any
      host: any
  outbound:
    - port: any
      proto: any
      host: any
logging:
  level: info
  format: json

הגדרת צומת רגיל עם מדיניות חומת אש

חומת האש של Nebula אינה עטיפה של iptables. הכללים חלים ברמת רשת-העל ופועלים על קבוצות תעודות. זהו היתרון המרכזי: מדיניות גישה מוטמעת בתשתית PKI, בלתי תלויה בכתובות IP, ופועלת ללא קשר לחומת האש של המארח.

# /etc/nebula/config.yaml на prod-сервере pki:
ca: /etc/nebula/ca.crt
cert: /etc/nebula/web-prod-01.crt
key: /etc/nebula/web-prod-01.key
static_host_map:
  "10.100.0.1": ["203.0.113.10:4242"] # lighthouse public IP
lighthouse:
  am_lighthouse: false
  interval: 60
  hosts:
    - "10.100.0.1"
listen:
  host: 0.0.0.0
  port: 4242
punchy:
  punch: true
  respond: true
  delay: 1s
firewall:
  conntrack:
    tcp_timeout: 120s
    udp_timeout: 30s
  inbound:
    # Мониторинг от prometheus (группа monitoring)
    - port: 9100
      proto: tcp
      group: monitoring
    # SSH только от bastion/ops группы
    - port: 22
      proto: tcp
      group: ops
    # Внутренний API от других prod-сервисов
    - port: 8080
      proto: tcp
      group: prod
  outbound:
    - port: any
      proto: any
      host: any
logging:
  level: info
  format: json

כמה ניואנסים לגבי hole punching: ברשתות עם NAT סימטרי (חלק מרשתות ארגוניות וחלק משערי NAT בענן), לא נוצר נתיב P2P ישיר—התעבורה עוברת דרך ממסר. ל-Nebula אין ממסר מובנה כמו DERP של Tailscale, כך שעם NAT סימטרי משני הצדדים, הקישוריות לא תהיה peer-to-peer. יש לקחת זאת בחשבון בעת תכנון הטופולוגיה—יש למקם lighthouses על מארחים עם IP ציבורי ישיר ללא NAT. זמן השהייה אופייני של P2P הוא 1–5 אלפיות שנייה (אנו מבטיחים פחות מ-10 אלפיות שנייה), זמן התאוששות מביטול תעודה הוא פחות משנייה אחת.

מדוע להפוך את סיבוב התעודות לאוטומטי?

מפתח ה-CA הוא החלק הקריטי ביותר. פגיעה ב-CA משמעותה החלפה מלאה של כל תשתית ה-PKI של Nebula. אנו ממליצים לאחסן את מפתח ה-CA ב-HashiCorp Vault עם מנוע הסודות PKI או באחסון לא מקוון נפרד. תוחלת חיי התעודה צריכה להיות 90 יום עם סיבוב אוטומטי.

סקריפט לסיבוב אוטומטי דרך Vault:

#!/bin/bash
# rotate-nebula-cert.sh
NODE_NAME=$1
OVERLAY_IP=$2
GROUPS=$3

# Получаем CA из Vault
vault kv get -field=ca_key secret/nebula/ca > /tmp/ca.key
vault kv get -field=ca_crt secret/nebula/ca > /tmp/ca.crt

# Генерируем новый сертификат
nebula-cert sign \
  -ca-crt /tmp/ca.crt \
  -ca-key /tmp/ca.key \
  -name "$NODE_NAME" \
  -ip "$OVERLAY_IP" \
  -groups "$GROUPS" \
  -duration 2160h # 90 дней

# Распространяем через Ansible
ansible -i inventory "$NODE_NAME" -m copy \
  -a "src=${NODE_NAME}.crt dest=/etc/nebula/host.crt"
ansible -i inventory "$NODE_NAME" -m service \
  -a "name=nebula state=restarted"

# Чистим временные файлы
rm -f /tmp/ca.key /tmp/ca.crt

כיצד Nebula פותר את בעיית ה-NAT?

WireGuard מצוין לנקודה-לנקודה, אבל עבור mesh עם מאות צמתים, תצטרכו להגדיר כל עמית—זה לא ניתן להרחבה. IPsec מורכב להגדרה ולניפוי שגיאות. Nebula מספק PKI, גילוי עמיתים דינמי דרך lighthouse, ומדיניות חומת אש מבוססת קבוצות מחוץ לקופסה. עבור תשתיות עם autoscaling ו-spot instances (שם כתובות ה-IP משתנות), זו הבחירה הטובה ביותר. הניסיון שלנו: במשך 5+ שנים פרסנו את Nebula ביותר מ-30 פרויקטים, ומעולם לא היו לנו בעיות הרחבה. בזכות hole punching אוטומטי, צמתים חדשים מתחברים תוך שניות. צרו קשר—נבקר את הרשת שלכם ונציע את ההגדרה האופטימלית. מעבר ל-Nebula יכול לחסוך עד 12,000 דולר בשנה ברישיונות VPN עבור 50 צמתים.

מה כלול בהקמת Nebula במפתח מלא

תהליך

1. ניתוח—דיון בדרישות: אילו צמתים, אילו עננים, האם נדרשת אינטגרציית Vault.
2. עיצוב—יצירת ארכיטקטורה: מספר lighthouses, אזורי NAT, קבוצות אבטחה.
3. יישום—פריסת lighthouses, יצירת CA, חתימת תעודות, הגדרת קבצי הגדרות דרך Ansible או Terraform.
4. בדיקות—אימות קישוריות P2P, בדיקות עומס, MTTR לתקלות.
5. פריסה—חיבור צמתי ייצור, הגדרת ניטור (Prometheus + Loki), מסירת תיעוד.

לוחות זמנים משוערים

החיסכון ברישיונות VPN בעת מעבר ל-Nebula הוא עד 50% בהשוואה לפתרונות מסחריים, ואנו מבטיחים חיסכון מינימלי של 20%. העלות המדויקת מחושבת לאחר ביקורת התשתית שלכם. קבלו ייעוץ—נציע את מודל הפריסה האופטימלי. למומחי Nebula המוסמכים שלנו יש למעלה מ-5 שנות ניסיון מעשי עם יותר מ-30 פריסות מוצלחות.