MULTI: نشانی مبدأ نامعتبر از سرویس‌گیر: این نشانی از کی بود؟
مبدأ داخلی با سرویس‌گیری که آن را رسانده مطابقت ندارد. آن را با یک تخصیص تونل، یک LAN پشت سرویس‌گیر، یا هویتی تکراری تطبیق دهید.
گزارش سرور MULTI: bad source address from client را چاپ می‌کند، بسته را دور می‌اندازد، و نشست متصل می‌ماند. این ترکیب کسانی را که پیام را شکست احراز هویت می‌خوانند سردرگم می‌کند. این‌طور نیست: سرویس‌گیر احراز هویت شده است، و بسته‌ای که رسید نشانی مبدأ داخلی را حمل می‌کرد که سرور نمی‌توانست آن را به این نمونه از سرویس‌گیر نسبت دهد. بررسی پیش از تحویل انجام می‌شود، و همین است که تونل سالم به نظر می‌رسد در حالی که چیز مفیدی از آن عبور نمی‌کند.
سرور پیش از تحویل چه چیزی را مقایسه می‌کند
برای هر بسته‌ای که از سرویس‌گیر می‌رسد، سرور در فضای کاربر به نشانی مبدأ درون تونل نگاه می‌کند و از وضعیت مسیریابی درونی خود می‌پرسد که این نشانی به کدام سرویس‌گیر تعلق دارد. اگر مالک نمونه دیگری باشد، یا هیچ مالکی نباشد، بسته پاک می‌شود و هشدار صادر می‌گردد.
تحویل عادی از طریق رابط تونل هرگز رخ نمی‌دهد.
این ترتیب جزئیاتی را توضیح می‌دهد که مردم را گیج می‌کند: شمارنده‌های دیوار آتش میزبان تکان نمی‌خورند، زیرا بسته هرگز به دیوار آتش نرسیده است. تنظیم فیلتر مسیر برگشتی روی میزبان اینجا چیزی را تغییر نمی‌دهد، چون رد شدن در بررسی پیوند خود دیمن رخ داده است. پیام را به‌عنوان گزاره‌ای درباره مالکیت بخوانید، سپس بفهمید کدام‌یک از سه وضعیت آن را پدید آورده است.
سه منبع نشانی داخلی ناهمخوان
سرویس‌گیر ممکن است از نشانی‌ای بفرستد که به او تخصیص داده نشده، از شبکه‌ای که هیچ‌کس آن را متعلق به او اعلام نکرده، یا از نسخه تکراری هویتی که از پیش مالک دارد. هر سه یک خط گزارش یکسان تولید می‌کنند. تفاوتشان در چیزی است که باید تغییر دهید. با نشانی و فهرست تخصیص‌های کنونی شروع کنید و بگذارید این دو واقعیت مورد را انتخاب کنند.
تفکیک آن‌ها دو واقعیت می‌خواهد: نشانی ردشده در گزارش، و تخصیص‌هایی که سرور آن‌ها را کنونی می‌داند. دومی از نمای وضعیت یا مدیریت نمونه در حال اجرا در دسترس است، و تنها مرجعی است که ارزش مراجعه دارد، زیرا پرونده پیکربندی قصدها را ثبت می‌کند نه وضعیت کنونی را.
پیش از تغییر هر چیزی هر دو را ثبت کنید، سپس دسته‌بندی کنید. تصویر صفحه‌ای که بعداً گرفته شود ثبت وضعیتی نیست که هشدار را پدید آورد. مهر زمانی را هم نگه دارید، زیرا تخصیص‌ها میان نشست‌ها جابه‌جا می‌شوند.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
LAN پشت سرویس‌گیر و iroute
وقتی سرویس‌گیر یک سایت شبکه خصوصی خود را مسیریابی می‌کند، آن شبکه باید متعلق به سرویس‌گیر اعلام شود. پرونده‌ای مخصوص سرویس‌گیر با یک ورودی iroute این کار را می‌کند، و ورودی پیشوندی را نام می‌برد که سرویس‌گیر اجازه حمل آن را دارد.
مسیر هسته‌ای که همان پیشوند را به تونل هدایت می‌کند الزام جداگانه‌ای است، و افزودن آن هیچ چیزی در مالکیت داخلی دیمن تغییر نمی‌دهد.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0تأیید کنید که هویت مؤثر با نام پرونده مطابقت دارد، زیرا ناهمخوانی یعنی پرونده هرگز بارگذاری نمی‌شود و نشانه با ورودی غایب یکسان است. برای خاموش کردن هشدار یک iroute گسترده اضافه نکنید، زیرا این کار یک مبدأ غیرمنتظره را به مبدأ مجاز تبدیل می‌کند بدون اینکه پاسخ دهد چرا سرویس‌گیر آن را فرستاده است. راهنمای OpenVPN 2.6، iroute و duplicate-cn و نگاشت هویت را به‌عنوان کنترل‌های جداگانه مستند می‌کند.
همان هویت روی دو ماشین
نمایه‌ای که به لپ‌تاپ دومی کپی شده همان گواهی و همان نام مشترک را حمل می‌کند. بسته به تنظیمات سرور، اتصال تازه‌تر می‌تواند قدیمی‌تر را جایگزین کند، و هر نمونه‌ای که مالکیت را در دست دارد بررسی پیوند را می‌برد.
این باعث می‌شود خطا متناوب به نظر برسد و تنها وقتی هر دو دستگاه بیدارند پدید آید.
اجازه دادن به نام‌های مشترک تکراری هر دو را وصل می‌کند، اما به آن‌ها نشانی‌های ایستای مستقل یا مالکیت مستقل نمی‌دهد. اگر دو دستگاه باید هم‌زیستی کنند، آن‌ها را جداگانه ثبت کنید تا هر یک هویت و تخصیص خود را داشته باشد. برخورد با تنظیم تکرار به‌عنوان تعمیر این هشدار، معما را سر جایش می‌گذارد و دومی را اضافه می‌کند.
اثبات کنید پیوند تغییر کرده است
اصلاح را از طریق مالک پیکربندی اعمال کنید، سپس سرویس‌گیر متأثر را دوباره وصل کنید تا سیاست تازه بارگذاری شود.
همان جریان را تکرار کنید و سه چیز را تأیید کنید: مبدأ داخلی بسته، نمونه سرویس‌گیری که سرور آن را با آن پیوند می‌دهد، و رفتار مقصد پس از آن.
اگر هشدار متوقف شود اما برنامه هنوز شکست بخورد، مشکل جابه‌جا شده نه ناپدید. ارسال به جلو، قواعد دیوار آتش و مسیر برگشت مراحل جداگانه‌اند، و گذر از بررسی پیوند فقط یعنی به بسته اجازه داده شد تونل را ترک کند.