گسترش سایت VPN: مسیر بازگشت را از فراتر از دروازه دنبال کنید
گسترش VPN یک سایت به مرکز داده دیگری به مسیری رو به جلو و مسیر بازگشت نیاز دارد، نه فقط یک پیشوند دیگر روی دروازه نزدیک.
ترافیک یک شعبه روی دروازهای تمام میشود که LAN آن برنامهای را که از شما خواسته شده بود به آن برسید در خود ندارد. سرور در مرکز داده دومی قرار دارد، آنسوی یک پیوند داخلی که VPN هرگز آن را پیکربندی نکرد. افزودن پیشوندی دیگر به دروازه نزدیک برای آن حالت هیچ کاری نمیکند، زیرا دروازه دور یک نقطه پایانی رمزنگاری است، نه آخرین مسیریاب. مسیر به یک راه رو به جلو، پذیرشی در مرز امنیتی دور و تصمیمی برای بازگشت در شبکه خود مقصد نیاز دارد.
دروازه دور یک نقطه پایانی رمزنگاری است
IPsec میان دروازهها ترافیک میان دو دستگاه امنیتی را محافظت میکند و آدرسهای داخلی رمزنگاریشده از آن قطعه عبور میکنند. فراتر از دروازه دور، مسیریابی معمولی کار را بر عهده میگیرد، از جمله هر سیاستی که میان مراکز داده وجود دارد. بنابراین قطعه محافظتشده بخشی از سفر را پوشش میدهد و نه باقی آن را. فرض کردن خلاف این است که یک طراحی به تونل سالم و برنامهای دستنیافتنی میرسد.
مسیر را در سه بخش بکشید: شعبه به دروازه نزدیک، نزدیک به دروازه دور، دروازه دور به برنامه. هر بخش صاحب خود و شیوه شکست خود را دارد.
هر دو جهت سیاست تونل را بخوانید
سیاست تونل معمولاً از دیدگاه سمت محلی نوشته میشود و پیکربندیهای ناقص از همین عادت میآیند. هر دو همتا باید منبع شعبه و مقصد را همانگونه فهرست کنند که داخل تونل ظاهر میشوند، از جمله هر ترجمهای که طراحی در نظر دارد. بهروزرسانی فقط انتهای نزدیک ناسازگاری فاز دوم را تولید میکند که شبیه شکست مسیریابی به نظر میرسد. دو مجموعه سیاست را پیش از دست زدن به هر مسیری مقایسه کنید.
منبع و مقصد را بهصورت آدرس بنویسید، نه نام سایت. ابهام در اینجا بعداً بهشکل عدم تقارنی گیجکننده بازمیگردد.
مسیر رو به جلو را اضافه کنید و پذیرش را تأیید کنید
دروازه دور به مسیری به سوی زیرشبکه برنامه نیاز دارد و هر مسیریاب میان آنها باید منبع شعبه را بپذیرد. بررسی کنید که دروازه دور واقعاً چه دارد، نه آنچه نمودار ادعا میکند.
ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10فرمان نخست رابط خروج و گام بعدی را گزارش میدهد که دروازه دور برای آن منبع انتخاب میکرد، پرسشی که یک جدول مسیریابی ساده نمیتواند پاسخ دهد. ردگیری نشان میدهد بستهها کجا متوقف میشوند و گسیختگی پس از دروازه دور به گذر داخلی اشاره دارد، نه به تونل. وقتی مسیر وجود دارد و ترافیک همچنان ناپدید میشود، روی دروازه دور ضبط کنید و آدرس منبع ورودی را بخوانید، زیرا آدرس غیرمنتظره یعنی ترجمه جایی برنامهریزینشده در حال رخ دادن است. همه آدرسهای اینجا جاینگهدارند، پس زیرشبکههای واقعی شعبه، گذر و برنامه را جایگزین کنید.
از شعبه آزمایش کنید، سپس مسیر قدیمی را دوباره آزمایش کنید
پذیرش به منبعی واقعی نیاز دارد، نه کاوشگری از دروازه دور. بررسی را از میزبان شعبه اجرا کنید و مقصدهایی را که پیشتر کار میکردند در همان آزمایش نگه دارید.
curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1پاسخی از برنامه مسیر رو به جلو و مسیر بازگشت را با هم اثبات میکند، در حالی که ping به مقصد قدیمی اثبات میکند تغییر چیزی را که پیشتر کار میکرد نشکسته است. آدرس منبعی را که برنامه ثبت میکند بردارید، زیرا قواعد دسترسی آن و هر مسیر بازگشتی باید با آن مقدار همخوان باشد. جایی که شعبه پیش از تونل ترجمه میکند، آدرس سیاست و آدرس مورد مشاهده برنامه بر اساس طراحی متفاوتاند، پس هر دو را ثبت کنید. آزمایش را پس از تجدید کلید یا تغییر مسیریابی تکرار کنید، زیرا این مسیرها معمولاً یک بار اعتبارسنجی و سپس فراموش میشوند.
به هر یک از سه بخش و به مسیر بازگشت درون شبکه مقصد یک صاحب اختصاص دهید. مسیری با چهار صاحب در شکافهای میان آنها شکست میخورد.