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 |
מצב דמון: כתובת כריכה, מודול ופורט
בתחביר הדמון, מקטע הנתיב נוקב בשם מודול מוגדר, ולא בתיקייה בדיסק. סיסמת מודול נבדקת רק אחרי שהחיבור התקבל, והמודול יכול גם להיות לקריאה בלבד או מוסתר מהרשימה. הסדר הזה חשוב כשקוראים שגיאה, כי חיבור שנדחה ומודול שנדחה הם כשלים בשני שלבים שונים. אף אחת משתי ההודעות לא אומרת לכם דבר על המנהרה עצמה.
אפשר לנעוץ דמון עצמאי לכתובת המנהרה בקובץ התצורה שלו, מה שמרחיק אותו מהממשק הציבורי בלי שום כלל בחומת האש. הערך חייב להתקיים כשהדמון נכרך, ומאזין שמופעל על ידי socket או מנוהל על ידי 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