نشانی peer در PPP یا نقطه پایانی VPN: کدام در via می‌آید

یک خط روی رابط PPP بیشتر بحث مسیریابی روی جعبه VPN را تمام می‌کند: نشانی درونی و peer که کنارش چاپ شده است. این جفت را یک زیرشبکه کوچک بخوانید و به دنبال دروازه‌ای خواهید رفت که وجود ندارد. آن را دو سر یک پیوند بخوانید و گام بعدی روشن می‌شود. مقایسه اینجا میان همین دو خوانش است، چون هر جدولی که بعداً بسازید همانی را که برگزیده‌اید به ارث می‌برد. هیچ‌یک از این دو درباره نقطه پایانی بیرونی VPN چیزی تعیین نمی‌کند.

دو خوانش از یک خط رابط

جلسه‌ای بردارید که رابط در آن inet 10.64.3.9 peer 10.64.3.1/32 را گزارش می‌کند. خوانش زیرشبکه 10.64.3.9 را میزبان تنها روی جزیره /32 می‌داند و سپس برای رسیدن به هر چیز بیرون آن یک مسیریاب می‌جوید. چون تنها نشانی دیگر روی پیوند peer است، آن خوانش در نهایت خود 10.64.3.9 را به‌عنوان دروازه پیشنهاد می‌کند، که دایره‌ای است.

خوانش نقطه پایانی همان خوانش مستند است. روی رابط نقطه‌به‌نقطه، peer سر دور پیوند یگانه را نام می‌برد، پس 10.64.3.1 گام بعدی قابل استفاده است و 10.64.3.9 همیشه فقط نشانی مبدأ است.

همین تفاوت تعیین می‌کند چه چیزی می‌تواند در via بیاید. نوشتن نشانی محلی در آنجا مسیری می‌سازد که هسته نمی‌تواند آن را به همسایه فروبکاهد، پس ورودی یا در اعتبارسنجی رد می‌شود یا ترافیک را می‌بلعد در حالی که در فهرست کاملاً سالم به نظر می‌رسد. peer کار می‌کند چون مقصد واقعی روی پیوند است. هر دو خوانش درباره نقطه پایانی بیرونی VPN توافق دارند، که هویتی کاملاً جدا است: از راه لایه زیرین به آن می‌رسند، نه از راه تونلی که آن را پایان می‌دهد.

آنچه جلسه پیشاپیش نصب کرده است

پیش از نوشتن جدول خودتان، آنچه با پیوند آمده را چاپ کنید. یکپارچه‌سازی پشتیبانی‌شده PPP معمولاً هنگام برپایی جلسه یک مسیر دستگاه و یک مسیر peer نصب می‌کند، و همان دو ورودی خوانش درست را رمزگذاری می‌کنند.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

مسیر دستگاه مانند 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 دروازه ندارد چون خود رابط مسیر است. مسیری که peer را با via نام می‌برد شیء دیگری با عمر دیگر است، و وقتی جلسه بیفتد ناپدید می‌شود. رونوشت هر یک از این دو شکل در جدول ماندگار بدون بررسی اینکه چگونه دوباره نصب می‌شود، همان دلیل معمول گم شدن مسیر یک تونل کارکننده پس از اتصال دوباره است.

دو فهرست را مقایسه کنید نه اینکه به حافظه اعتماد کنید. اگر مسیر peer در main هست ولی جدول افزوده شما خالی است، چیزی آموخته‌اید که خط نشانی هرگز نگفت.

قاعده و جدول دو تصمیم جداگانه‌اند

برگزیدن جدول و پر کردن آن دو گام مستقل است، و مقایسه اینجا مهم است چون این دو هنگام اشکال‌زدایی اغلب با هم اشتباه می‌شوند. قاعده‌ای که ترافیک نشان‌دار را به جدول 100 می‌فرستد اگر جدول 100 مسیر مطابق نداشته باشد هیچ نمی‌کند، و جدول خوب پر شده هم اگر هیچ قاعده‌ای به آن اشاره نکند دست‌نیافتنی است.

نیمی از مسیر پیش‌فرض مسیر پیش‌فرض نیست. یک 0.0.0.0/1 تنها نیمه پایین فضای IPv4 را می‌پوشاند، پس سیاستی که می‌خواهد همه چیز را بگیرد به 128.0.0.0/1 متناظر یا default واقعی هم نیاز دارد. خواندن پیکربندی کارکننده و رونوشت یکی از دو نیمه همان راهی است که مردم به حلقه مسیریابی می‌رسند که فقط روی مقصدهای خاص می‌شکند.

برای نشانی‌هایی که باید در LAN بمانند استثناهای عامدانه بگذارید، و تعیین کنید وقتی جست‌وجو در جدول برگزیده چیزی نمی‌یابد چه می‌شود. مسیر جانشین صریح آسان‌تر از جدول خالی قابل اندیشیدن است، جدولی که نتیجه دست‌نیافتنی برمی‌گرداند و برنامه را به‌جای بدمسیریابی، خراب نشان می‌دهد.

از جست‌وجو همان پرسشی را بپرسید که برنامه‌تان می‌پرسد

ip route get مسیری را حل می‌کند، ip route show ورودی‌های ذخیره‌شده را فهرست می‌کند، و این دو می‌توانند بدون اینکه هیچ‌کدام غلط باشد اختلاف داشته باشند. بافت مبدأ را وارد کنید، چون قواعد مبتنی بر مبدأ تنها وقتی مطابقت می‌کنند که جست‌وجو مبدأیی با خود ببرد.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

فرمان نخست پرسش را از سمت میزبان می‌پرسد. دومی یک رابط ورودی می‌افزاید که به آنچه ترافیک ارسال‌شده تجربه می‌کند نزدیک‌تر است، و پاسخ غالباً به جدول دیگری اشاره می‌کند. هیچ‌یک از این مقصدها سرویس آزمون زنده نیست؛ 198.51.100.23 نشانی مستندات است، پس آن را با میزبانی که اجازه کاوش آن را دارید جایگزین کنید.

حتی جست‌وجوی درست تنها اثبات می‌کند مسیری برگزیده شد. چیزی درباره اینکه طرف دور ترافیک را می‌پذیرد یا پاسخ می‌تواند با همان استدلال بازگردد نمی‌گوید.

کجا مقایسه برمی‌گردد

ترافیک میزبان و ترافیک ارسال‌شده فقط جست‌وجوهای متفاوت ندارند؛ در راه بازگشت با پالایه‌های متفاوتی روبه‌رو می‌شوند. Linux اعتبارسنجی مسیر معکوس را با سخت‌گیرانه‌ترِ تنظیمات همه رابط‌ها و رابط گیرنده اعمال می‌کند، پس تغییر مقدار یک رابط ممکن است اثر دیدنی نداشته باشد. مسیریابی مبتنی بر نشانه رابطه src_valid_mark را می‌افزاید، که در آن نشانه باید منطبق باشد تا مبدأ معتبر شمرده شود.

اگر پاسخ‌ها ناپدید شوند در حالی که مسیریابی خروجی درست به نظر می‌رسد، پیش از دست زدن به آن‌ها مقادیر مؤثر را بخوانید، و فقط با دلیلی سیاستی اعلام‌شده تغییرشان دهید.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

میان دو طراحی بر پایه شواهد یکی را برگزینید: اگر برنامه به نشانی PPP گره خورده باشد، یک قاعده مبدأ و جدولی که مسیر peer را نگه می‌دارد کافی است. اگر جعبه برای LAN پشتش ارسال می‌کند، باید بافت ورودی و مسیر بازگشت هم منطبق باشند. وقتی منطبق نیستند، مالکیت مسیر را درست کنید نه اینکه اعتبارسنجی را برای کل ماشین شل کنید.