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