VPN मार्फत rsync: डेमन पोर्ट 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