הגדרת VPN בין אתרים: מדריך לשילוב משרד-ענן

מדריך מומחה לחיבור רשתות משרד עם VPC בענן באמצעות VPN

אנו נתקלים באופן קבוע באתגר של הקמת מנהרות Site-to-Site VPN בין משרד לבין VPC בענן (AWS, GCP, Azure). הדרישה היא ששירותי הענן יראו מארחים פנימיים באמצעות כתובות פרטיות—ללא NAT hairpinning או קפיצות נוספות. בפועל, מצטברים ניואנסים רבים: חוסר התאמה ב-MTU על המנהרה, סטייה של Phase 2 SAs ב-IKEv1, התנגשויות subnet בין המשרד לבין CIDR ברירת המחדל של ה-VPC, או תרחיש שבו הפעלת BGP פעילה, מסלולים מפורסמים, אבל התעבורה זורמת רק בכיוון אחד עקב חומת אש stateful א-סימטרית בקצה הארגוני. עם למעלה מ-50 פרויקטים של שילוב משרדים עם סביבות ענן מאחורינו, אנו מכירים את המלכודות האופייניות וכיצד להימנע מהן. המהנדסים המוסמכים שלנו מבטיחים יציבות ואבטחה לכל מנהרה. עלות השירות האופיינית נעה בין $1,500 ל-$5,000, ועשויה לחסוך לכם עד 40% בעלויות העברת נתונים בענן. קבלו ייעוץ מהנדס לפרויקט שלכם.

באיזה טופולוגיה ופרוטוקול לבחור?

לחיבור משרד-ענן, אנו משתמשים ב-IPsec IKEv2 כתשתית הבסיס. IKEv2 מקים חיבורים מהר ב-30% מ-IKEv1 ומתאושש בצורה אמינה יותר לאחר ניתוק. אנו משתמשים ב-GRE מעל IPsec כאשר יש צורך להעביר multicast או OSPF/BGP בתוך המנהרה; אחרת, ה-overhead אינו מוצדק.

הגדרת AWS VPN סטנדרטית עם BGP נראית כך:

Customer Gateway (CGW): внешний IP офисного маршрутизатора
Virtual Private Gateway (VGW) или Transit Gateway (TGW): на стороне AWS
BGP ASN клиента: 65001 (private range)
BGP ASN AWS: 64512 (дефолтный) или кастомный
Two tunnels: обязательно для HA, каждый с отдельным pre-shared key

AWS יוצר אוטומטית שתי מנהרות עם כתובות IP שונות לקצה—זו לא יתירות לשם מראית עין, אלא failover אמיתי. המנהרה הראשונה נופלת במהלך תחזוקת קצה AWS; ללא השנייה, יהיה לכם חלון השבתה של 30 שניות עד מספר דקות.

בצד המשרד, תצורה אופיינית עבור MikroTik (RouterOS 7.x):

/ip ipsec profile add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=aws-profile
/ip ipsec proposal add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=1h name=aws-proposal pfs-group=modp2048
/ip ipsec peer add address=<AWS_TUNNEL1_IP>/32 exchange-mode=ike2 name=aws-tunnel1 profile=aws-profile
/ip ipsec identity add peer=aws-tunnel1 secret=<PSK_TUNNEL1>
/ip ipsec policy add dst-address=10.0.0.0/16 peer=aws-tunnel1 sa-dst-address=<AWS_TUNNEL1_IP> \
    sa-src-address=<OFFICE_PUBLIC_IP> src-address=192.168.1.0/24 tunnel=yes

/ip firewall mangle add action=change-mss chain=forward new-mss=1387 out-interface=<ipsec-tunnel> \
 passthrough=yes protocol=tcp tcp-flags=syn

BGP מעל המנהרה

שימו לב: כאשר יש צורך לפרסם מספר subnets או להגדיר failover בין שתי מנהרות, אנו מריצים BGP מעל IPsec. AWS Transit Gateway שימושי במיוחד עבור טופולוגיות hub-and-spoke—מספר משרדים מתחברים ל-TGW יחיד, אשר מנתב תעבורה ביניהם ובין ה-VPC.

דוגמה לתצורת BGP על Cisco IOS עבור מנהרה ל-AWS:

crypto isakmp policy 10
 encr aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 28800
crypto ipsec transform-set AWS-TS esp-aes 256 esp-sha256-hmac
 mode tunnel
interface Tunnel1
 ip address 169.254.10.2 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination <AWS_TUNNEL1_OUTSIDE_IP>
 ip tcp adjust-mss 1387
router bgp 65001
 neighbor 169.254.10.1 remote-as 64512
 neighbor 169.254.10.1 timers 10 30
 network 192.168.0.0 mask 255.255.0.0

כתובות link-local 169.254.x.x/30 הן סטנדרטיות עבור כתובות עמית BGP במנהרות AWS. אל תנסו להשתמש בכתובות משלכם—ה-VGW לא יקבל אותן.

אילו בעיות מתעוררות עם Site-to-Site VPN?

התנגשות CIDR. תרחיש: משרד על 10.0.0.0/8, VPC נוצר עם ברירת מחדל 10.0.0.0/16. המנהרה פעילה, BGP הוקם, אבל תעבורה למקרי EC2 לא זורמת—המסלול המקומי גובר על המנהרה. פתרון: בעת יצירת VPC, השתמשו ב-172.16.0.0/12 או 192.168.0.0/16 עבור רשתות ענן, והשאירו את 10.x.x.x למשרדים.

Dead Peer Detection. כברירת מחדל, DPD במנהרות AWS יש מרווח של 10 שניות ו-3 ניסיונות חוזרים. עם ספק אינטרנט לא יציב בצד המשרד, המנהרה מאתחלת כל 30 שניות. אם Phase 1 ו-Phase 2 לא עולים במהירות (Cisco IOS עם Customer Gateway (CGW): внешний IP офисного маршрутизатора Virtual Private Gateway (VGW) или Transit Gateway (TGW): на стороне AWS BGP ASN клиента: 65001 (private range) BGP ASN AWS: 64512 (дефолтный) или кастомный Two tunnels: обязательно для HA, каждый с отдельным pre-shared key ), אתם מקבלים אובדן מנות בכל חיבור מחדש.

ניתוב א-סימטרי. למשרד יש שני ספקי אינטרנט—failover דרך הקו השני. תעבורה חוזרת מגיעה דרך הקו הראשי. חומת אש stateful בקצה המשרד מפילה מנות מהממשק ה"לא צפוי". זה מתוקן או באמצעות ניתוב מבוסס מדיניות או על ידי העברת תעבורת המנהרה לאזור חומת אש נפרד ללא בדיקה stateful.

כיצד אנו מגדירים Site-to-Site VPN: תהליך שלב-אחר-שלב

1. ביקורת רשת—ניתוח הטופולוגיה הקיימת, subnets, ציוד וגרסאות תוכנה.
2. תכנון—בחירת טופולוגיה, פרוטוקול, תכנית כתובות וזמינות גבוהה.
3. הגדרה—הקמת IPsec ו-BGP בשני הצדדים, יישום MSS clamping.
4. בדיקות—אימות failover, מדידת זמן התאוששות, בדיקת עומס MTU.
5. תיעוד—דיאגרמת רשת, קבצי תצורה עם הערות, runbook לשחזור מאסון.

השוואה: IKEv1 לעומת IKEv2

מה כלול בתוצאה

לאחר סיום העבודה, אתם מקבלים:

• דיאגרמת רשת מתועדת (draw.io או Mermaid)
• קבצי תצורה עם הערות
• Runbook לשחזור מנהרה לאחר תקלת ספק אינטרנט
• אחריות יציבות (מוסכם חוזית)

לוחות הזמנים תלויים במורכבות: מיום אחד למנהרה פשוטה ועד שבועיים לרשת היברידית עם AD, DNS ו-NTP. העלות נקבעת לאחר ניתוח—צרו קשר כדי לדון בפרויקט שלכם.

אופטימיזציה של ניתוב יכולה לחסוך עד 40% בתעבורת ענן, ועלויות התפעול יורדות ב-20% הודות ל-failover אוטומטי. קבלו ייעוץ מהנדס כדי להעריך את הפרויקט שלכם. צרו קשר כדי להזמין את השירות. למידע נוסף על עיצוב חיבור מאובטח, עיינו ב-RFC 4301 ובתיעוד הספקים: AWS VPN, GCP VPN, Azure VPN Gateway, והמדריך הרשמי של MikroTik.