rsync از طریق VPN: درگاه سرویس 873 در برابر حالت SSH
درگاه 873 سرویسی درونی است که تونل آن را حمل می‌کند، نه جایگزینی برای آن. حالت سرویس را از حالت SSH جدا کنید و سپس فقط مسیری را باز کنید که واقعاً استفاده می‌کنید.
اجازه دادن به TCP 873 روی رابط تونل، rsync را از OpenVPN، عبور نمی‌دهد و باعث نمی‌شود طرف دور ماژول را بپذیرد. تونل یک اتصال درونی را حمل می‌کند که قواعد پروتکل و مقصد آن دقیقاً همان‌طور که بودند می‌ماند. پس پرسش نخست این نیست که کدام درگاه را باز کنیم، بلکه این است که rsync چه نوع اتصالی برقرار می‌کند. همه چیز در ادامه فرض می‌کند که تونل از پیش برپاست و تنها سرویس درونی هنوز محل تردید است.
تعیین کنید rsync در واقع چه اتصالی برقرار می‌کند
آرگومان دور در فرمان معمولاً پیش از هر تغییری در دیوار آتش به آن پرسش پاسخ می‌دهد. دو دونقطه یا یک طرح‌واره URL سرویس را انتخاب می‌کند، در حالی که یک دونقطه پس از نام میزبان یک صدف دور را انتخاب می‌کند. آرگومانی را بخوانید که واقعاً اجرا می‌کنید، نه آن یکی را که در مثال مستندات آمده است.
یک گزینه صریح صدف دور می‌تواند پاسخ را دوباره تغییر دهد، چون به rsync می‌گوید کدام برنامه را برای انتقال اجرا کند. کل خط فرمان را بخوانید، از جمله اسکریپت‌های پوششی به‌ارث‌رسیده، نه فقط بخش میزبان را.
| Remote argument | What it opens |
|---|---|
rsync://vault.corp.internal/archive/ | rsync daemon, normally TCP 873 |
vault.corp.internal::archive/ | rsync daemon, normally TCP 873 |
[email protected]:/srv/archive/ | Remote shell, normally SSH on its configured port |
حالت سرویس: نشانی اتصال، ماژول و درگاه
در نحو سرویس، بخش مسیر یک ماژول پیکربندی‌شده را نام می‌برد، نه یک پوشه روی دیسک. گذرواژه ماژول تنها پس از پذیرفته شدن اتصال بررسی می‌شود، و ماژول می‌تواند علاوه بر این فقط‌خواندنی یا از فهرست پنهان باشد. این ترتیب هنگام خواندن یک خطا مهم است، چون اتصال ردشده و ماژول ردشده شکست در دو مرحله متفاوت‌اند. هیچ‌یک از این دو پیام چیزی درباره خود تونل به شما نمی‌گوید.
یک سرویس مستقل را می‌توان در پرونده پیکربندی‌اش به نشانی تونل سنجاق کرد، که آن را بدون هیچ قاعده دیوار آتش از رابط عمومی دور نگه می‌دارد. مقدار باید هنگام اتصال سرویس وجود داشته باشد، و یک شنونده فعال‌شده با سوکت یا مدیریت‌شده با inetd می‌تواند آن را کاملاً نادیده بگیرد.
address = 10.44.0.1
port = 873
[archive]
path = /srv/archive
read only = yesسپس به جای نام عمومی، نشانی خصوصی را بیازمایید. نام میزبان عمومی به نشانی WAN تبدیل می‌شود و مسیر دیگری را طی می‌کند، حتی وقتی یک ماشین به هر دو پاسخ می‌دهد.
rsync --list-only rsync://10.44.0.1/archive/حالت صدف دور: SSH انتقال را حمل می‌کند
با یک دونقطه، rsync یک برنامه صدف دور را اجرا می‌کند و پروتکل آن را روی همان کانال سخن می‌گوید، پس تنها سرویس قابل دسترس SSH است روی هر درگاهی که سرور بر آن گوش می‌دهد. سرویس rsync هرگز اجرا نمی‌شود، درگاه 873 بی‌ربط است، و تصمیم دسترسی به تصمیم حساب SSH تبدیل می‌شود. مسیر دور آن‌گاه یک مسیر واقعی سامانه پرونده‌ها است که صدف طرف دیگر تفسیرش می‌کند. به همین دلیل تغییری در دیوار آتش که 873 را هدف بگیرد برای این حالت هیچ کاری نمی‌کند.
این طراحی به دو چیز نیاز دارد: حسابی مجاز و بررسی کلید میزبان. همچنین سیاست احراز هویت خود SSH را به ارث می‌برد، و غالباً وقتی انتقال باید از شبکه‌ای نامطمئن بگذرد گزینه بهتر است، چون رمزگذاری به پروتکلی تعلق دارد که برای همین ساخته شده. سرویسی که گذرواژه می‌پرسد همان چیز نیست.
فقط مسیری را باز کنید که انتخاب کرده‌اید
وقتی حالت مشخص شد، تنها سرویس درونی را روی تنها رابطی که تونل را حمل می‌کند مجاز کنید. قاعده را با رابط، استخر مبدأ و نشانی مقصد محدود کنید تا تغییر بعدی در منع پیش‌فرض نتواند بی‌صدا آن را گسترده کند. سپس ترتیب قواعد را بازبینی کنید، چون قاعده‌ای سهل‌گیرانه‌تر در ابتدای زنجیره قاعده باریک را تشریفاتی می‌کند.
اگر سرویس روی ماشینی پشت دروازه VPN اجرا شود نه روی خود دروازه، دروازه به مسیر ارسال هم نیاز دارد و هدف به اجازه و مسیر بازگشت خودش. باز کردن درگاه فقط روی دروازه اتصالی می‌سازد که پذیرفته می‌شود و بعد به هیچ‌جا نمی‌رسد.
از سمت کارخواه با همان حالت و مقصدی که در تولید استفاده می‌کنید بررسی کنید. یک فهرست موفق شنونده، مسیر و قاعده را با هم اثبات می‌کند؛ یک پایان مهلت به مسیر اشاره دارد و یک رد به شنونده.
ufw allow in on tun0 from 10.44.0.0/24 to 10.44.0.1 port 873 proto tcp
ss -ltnp | grep 873