تنظیم MSS در TCP روی دروازه IPsec لینوکس: چه چیزی را درست می‌کند

Ping کار می‌کند، SSH کار می‌کند، یک صفحه کوچک بارگذاری می‌شود، و سپس هر پاسخ بزرگ تا پایان مهلت متوقف می‌ماند. الگوی کلاسیک به اندازه بسته اشاره می‌کند، نه به دسترسی‌پذیری: مسیر دست‌دهی و چند کیلوبایت اول را حمل می‌کند، سپس یک قطعه با اندازه کامل ناپدید می‌شود. روی دروازه IPsec لینوکس، قاعده TCP MSS اغلب راه‌حل است، اما تنها اگر بفهمید چه چیزی را تغییر می‌دهد و بسته‌ای که لمس می‌کند واقعاً کجاست. ترتیب زیر بسته را از نشانه تا جای‌گذاری قاعده دنبال می‌کند، تا بتوانید به‌محض اینکه توضیح دیگر جور نبود متوقف شوید.

نشانه‌ای که به MSS اشاره می‌کند

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

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

قاعده TCPMSS چه می‌کند و چه نمی‌کند

قاعده گزینه MSS را در بسته‌های دست‌دهی TCP هنگام عبور بازنویسی می‌کند. MTU رابط تونل را تعیین نمی‌کند، سیاست IPsec را تغییر نمی‌دهد، و روی هسته‌های کنونی فقط یک مقدار اعلام‌شده را پایین می‌آورد، نه اینکه مقدار کوچک‌تری را بالا ببرد. همچنین فقط TCP را لمس می‌کند؛ بارهای UDP، رفتار DNS و انتخابگرهای ترافیک مذاکره‌شده خارج از دسترس آن هستند.

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

قاعده را روی مسیر داخلی TCP بگذارید

روی دروازه لینوکس مبتنی بر سیاست، بسته ارسال‌شده وقتی دیوار آتش آن را می‌بیند هنوز مثل TCP معمولی به نظر می‌رسد. سیاست IPsec تصمیم می‌گیرد که بسته محافظت شود؛ دیوار آتش برای جریان داخلی هدر ESP نمی‌بیند، بنابراین تطبیق با ESP در اینجا بسته کاملاً دیگری را توصیف می‌کند. همین ناهماهنگی دلیل آن است که بعضی قاعده‌ها درست به نظر می‌رسند و هرگز تطبیق نمی‌یابند.

در اصطلاحات iptables، قاعده به جدول mangle در مسیر ارسال تعلق دارد، محدود به بسته‌های دست‌دهی: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. عدد یک مثال است، نه یک ثابت جهانی؛ آن را از سرباری کپسوله‌سازی و MTU واقعی مسیر استخراج کنید. معادل nftables حداکثر اندازه قطعه را در زنجیره forward یا postrouting تنظیم می‌کند.

قاعده‌های شنود بیرونی برای IKE و ESP را از قاعده‌های ارسال داخلی جدا نگه دارید. یک قاعده واحد که می‌خواهد هم جریان برنامه و هم پروتکل بیرونی را مجاز کند، در نهایت با هیچ‌کدام به‌طور قابل اتکا تطبیق نمی‌یابد.

به مالک دیوار آتش و ترتیب NAT احترام بگذارید

اگر UFW صاحب دیوار آتش میزبان است، تغییرات mangle و ارسال را از طریق پیکربندی پایدار پشتیبانی‌شده آن اضافه کنید، نه با تایپ دستوری که در بارگذاری بعدی ناپدید می‌شود. قاعده‌ای که در جدول اشتباه یا پس از یک قاعده پایانی درج شود هیچ اثری ندارد، و جدول زنده آن را از شما پنهان می‌کند.

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

دقیق بررسی کنید، سپس متوقف شوید

اتصال تازه‌ای به سرویس خراب باز کنید و هم برنامه و هم شمارنده‌های قاعده را زیر نظر بگیرید. اگر توقف برطرف شد، درباره آن مسیر TCP با آن کپسوله‌سازی شواهدی دارید. شواهدی ندارید که هر پروتکل VPN جا می‌شود، هر برنامه UDP درست شده یا سرویس مشخصی در بالادست علت اصلی بوده است.

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