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