SSH معکوس برای یک دستگاه: شنوندهٔ loopback یا VPN مسیریابی‌شده؟

یک درگاه مدیریت برای دستگاهی که فقط می‌تواند به بیرون وصل شود. سه شرط تعیین می‌کند که آیا تونل معکوس کافی است یا به مسیر مسیریابی‌شدهٔ واقعی نیاز دارید.

دستگاه شما پشت NAT اپراتور قرار دارد، می‌تواند اتصال‌های خروجی باز کند و سرور SSH اجرا می‌کند که هیچ‌کس به آن نمی‌رسد. درخواستی که می‌رسد معمولاً با عبارت "به آن VPN بدهید" بیان می‌شود که یکی از چند پاسخ است. پیش از پذیرفتن آن، تصمیم بگیرید یک درگاه TCP مدیریتی می‌خواهید یا مسیری مسیریابی‌شده به یک زیرشبکهٔ کامل، چون این‌ها پروژه‌های متفاوتی با مواجههٔ متفاوت هستند.

تونل معکوس به نسخهٔ باریک خوب پاسخ می‌دهد. دستگاه به هاب شما وصل می‌شود، از هاب می‌خواهد روی یک درگاه loopback گوش دهد و آن درگاه را به سرویس SSH خودش برمی‌گرداند. سپس مدیران از طریق هاب به شنونده می‌رسند، نه از طریق اینترنت عمومی.

سه شرط که انتخاب را تعیین می‌کند

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

ConditionReverse tunnel fitsSomething else is needed
How many services must be reachable?One, or a small fixed set on loopbackAnything that needs many ports or dynamic discovery
Who connects, and how are they authenticated?Named administrators with their own hub accountsThird parties, or anything needing per-flow audit you do not control
Does the device's own LAN need to be reachable?NoYes, so a routed VPN or a managed platform is the honest answer

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

سمت هاب: یک حساب رلهٔ محدود

به هر دستگاه حساب رلهٔ خودش را با احراز هویت کلید عمومی و بدون نشست تعاملی بدهید. Match بلوکی که به آن حساب محدود شده مجوز را کوچک نگه می‌دارد و کلید خصوصی روی همان دستگاه می‌ماند که به آن تعلق دارد.

Match User relay-dev-7
    AuthenticationMethods publickey
    PubkeyAuthentication yes
    AllowTcpForwarding remote
    PermitListen 127.0.0.1:21022
    GatewayPorts no
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

MaxSessions 0 خط جالب است. نشست‌های shell و زیرسیستم را رد می‌کند و در همان حال بازفرست موردنیاز دستگاه را مجاز می‌داند، پس کلید دزدیده‌شده نمی‌تواند به ورود تعاملی تبدیل شود. PermitListen نشانی و درگاه شنونده در سمت هاب را ثابت می‌کند، و GatewayPorts no آن را روی loopback نگه می‌دارد نه اینکه به شبکه‌ای که هاب در آن است باز کند.

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

سمت دستگاه: بازفرستی که بلند شکست می‌خورد

دستگاه اتصال را باز می‌کند و شنونده را درخواست می‌کند. دو نشانی در آرگومان -R معناهای متفاوتی دارند و خواندنشان از چپ به راست سریع‌ترین راه برای به یاد سپردن اینکه کدام کدام است.

ssh -NT \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -R 127.0.0.1:21022:127.0.0.1:22 \
    [email protected]

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

ExitOnForwardFailure=yes فرمان را وادار به خروج می‌کند وقتی شنوندهٔ درخواستی نمی‌تواند برقرار شود، پس حلقهٔ راه‌اندازی دوباره حقیقت را به شما می‌گوید نه اینکه نشستی نیمه‌کاره باقی بگذارد. دربارهٔ سالم بودن سرویس SSH محلی در آینده چیزی نمی‌گوید، پس آن را با یک مدیر فرایند و آزمایش واقعی اتصال گاه‌به‌گاه جفت کنید.

هرگز نشانی شنیدن loopback را با نویسهٔ عام جایگزین نکنید تا از یک پرش اضافه دوری کنید. همان یک تغییر تفاوت میان یک مسیر مدیریتی و درگاهی است که عموم به آن می‌رسند، و معمولاً هنگام اشکال‌زدایی رخ می‌دهد و بعد می‌ماند. اگر همکاری از طریق هاب به درگاه نمی‌رسد، پیکربندی پرش را درست کنید نه اینکه bind را گسترده‌تر کنید. loopback تمام استدلال امنیتی این طرح است.

دسترسی مدیر از طریق هاب

مدیری با یک حساب معمولی روی هاب می‌تواند از آن به درگاه بازفرست‌شده بپرد. حساب رله برای این کار استفاده نمی‌شود، و همین نکتهٔ جدا نگه داشتنشان است.

ssh -J [email protected] -o HostKeyAlias=device-7 \
    -p 21022 [email protected]

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

چرخهٔ عمر را مال خود کنید

فرمان دستگاه را زیر یک مدیر فرایند با دقیقاً یک نمونهٔ فعال و سیاست راه‌اندازی دوباره‌ای که آگاهانه انتخاب کرده‌اید اجرا کنید. گزینه‌های keepalive همتای مرده را تشخیص می‌دهند؛ فرایندی را که خارج شده زنده نمی‌کنند.

سپس رویهٔ از رده خارج کردن را بنویسید. هر دستگاه شنوندهٔ خودش و کلید خودش را دارد، پس از رده خارج کردن یعنی پس گرفتن آن حساب و حذف آن کلید، نه چرخاندن رازی که کل ناوگان در آن شریک است.

در پایان به یاد داشته باشید loopback چه چیزی برایتان می‌خرد. مواجههٔ شبکه را محدود می‌کند و دربارهٔ دیگر کاربران محلی روی یک هاب مشترک کاری نمی‌کند، پس سیاست دسترسی خود هاب همچنان باید درست باشد. مرجع sshd_config هر یک از گزینه‌های بالا را مستند می‌کند، و ارزش دارد بخش‌های بازفرست را کامل بخوانید پیش از آنکه هر یک از آن‌ها را گسترده‌تر کنید.

مقالات مرتبط