બે OpenVPN સર્વરના ક્લાયન્ટ એકબીજા સુધી પહોંચી શકે છે?

બીજું OpenVPN સર્વર ઊભું કરવાથી ક્લાયન્ટ જોડાવા માટે બીજી જગ્યા મળે છે, વધુ કંઈ નહીં. તે એ ક્લાયન્ટને પ્રથમ સર્વરના નેટવર્ક પર મૂકતું નથી, અને client-to-client નામનું વિકલ્પ ફક્ત એક સર્વર પ્રોસેસની અંદર ફોરવર્ડિંગ બદલે છે. જ્યારે તમે જાણી જોઈને તેમની વચ્ચે રૂટ કરો છો ત્યારે બંને પૂલ એક નેટવર્ક બને છે, દરેક દિશા માટે એક માલિક સાથે. નીચેનું બધું યુઝરસ્પેસ TUN મોડ અને એ આંતરિક ફોરવર્ડિંગ બંધ હોવાનું ધારે છે, તેથી નિર્ણય કર્નલ લે છે.

દંતકથા: એક ખાતા યાદી, એક નેટવર્ક

પ્રમાણીકરણ અને પહોંચને ભેળવી દેવાય છે કારણ કે બંને સર્વર રૂપરેખાંકનમાં રહે છે. જે વપરાશકર્તા બંનેમાંથી કોઈપણ ગેટવેમાં લોગિન કરી શકે છે, તે બહારથી બે દરવાજાવાળી એક સિસ્ટમના વપરાશકર્તા જેવો દેખાય છે. અંદર, દરેક સર્વર પોતાના પૂલમાંથી સરનામાં આપે છે અને ફક્ત તે જ ક્લાયન્ટ માટે રૂટ ઇન્સ્ટોલ કરે છે જેને તે સમાપ્ત કરે છે. તેથી ગેટવે A પરનો ક્લાયન્ટ જ્યારે ગેટવે B પરના ક્લાયન્ટને પેકેટ મોકલે છે, ત્યારે એવું લક્ષ્ય માંગે છે જે તેના પોતાના સર્વરે કદી સાંભળ્યું નથી. પેકેટ A ના ડિફોલ્ટ રૂટ પર જાય છે, ટનલ છોડે છે અને એવા ફાયરવોલ પર પહોંચે છે જેને કદી તેને મંજૂરી આપવા કહ્યું નથી.

તેથી બીજું સર્વર ઉમેરવાથી રિડંડન્સી, શોધ કે વિભાજિત બ્રોડકાસ્ટ ડોમેન ઉમેરાતું નથી. તે એક રૂટેડ નેટવર્ક ઉમેરે છે જેને યોજના જોઈએ, અને યોજના સરનામાંકનથી શરૂ થાય છે.

દરેક ગેટવેને તેનું પોતાનું પૂલ અને ટ્રાન્ઝિટ સરનામું આપો

બે શ્રેણીઓ જે બીજા કશા સાથે ઓવરલેપ ન કરી શકે, વત્તા હોસ્ટ વચ્ચે નાની ટ્રાન્ઝિટ કડી, એ આખી સરનામાં યોજના છે. ટ્રાન્ઝિટને તમે નિયંત્રિત કરો છો તેવા ખાનગી સેગમેન્ટ પર રાખો, અને કોઈ સર્વર લીઝ આપે તે પહેલાં સંખ્યાઓ લખી લો.

પ્રોફાઇલ સરખા રહે તે માટે બંને સર્વરને સમાન પૂલ આપવાના લોભનો પ્રતિકાર કરો. કર્નલ રૂટ કહી શકતું નથી કે વિભાજિત શ્રેણીની અંદરનું મનસ્વી સરનામું હાલમાં બે હોસ્ટમાંથી કોની પાસે છે, તેથી રૂટિંગ કોષ્ટક એક ગેટવે તરફ ઇશારો કરશે અને ક્લાયન્ટ બીજા સાથે જોડાયેલો હોઈ શકે. ઇન્ટરફેસ નામો સ્થાનિક પરંપરાઓ છે, વિભાજિત સ્થિતિ નહીં. અહીં બંને હોસ્ટ ટનલ ઉપકરણને tun0 અને ટ્રાન્ઝિટ કડીને transit0 કહે છે, જે ઠીક છે કારણ કે કોઈ પેકેટ એ નામો ધરાવતું નથી.

બંને બાજુ રૂટ ઇન્સ્ટોલ કરો

દરેક ગેટવેને બીજાના પૂલ માટે ટ્રાન્ઝિટ સરનામા દ્વારા રૂટ જોઈએ, અને કોઈપણ હોપ તરીકે કામ કરે તે માટે ફોરવર્ડિંગ ચાલુ હોવું જોઈએ. પહેલા વર્તમાન કોષ્ટકની ખાતરી કરો, પછી એન્ટ્રી ઉમેરો અને પુનઃકનેક્શન હૂકને બદલે હોસ્ટના નેટવર્ક મેનેજર દ્વારા તેને ટકાઉ બનાવો.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

પૂલ બદલીને બીજા હોસ્ટ પર પણ એ જ કરો. અસંબંધિત સ્ક્રિપ્ટમાંથી વારંવાર એ જ રૂટ ઉમેરવો એ રીત છે જેનાથી હોસ્ટ પાસે ઘણી નકલો અને આગલી વખતે કોઈ કોષ્ટક વાંચે ત્યારે રહસ્યમય ફેરફાર રહી જાય છે. જો ટ્રાન્ઝિટ કડી પોતે ટનલ હોય, તો રૂટ એ ટનલની ટોપોલોજી તરફ જાય છે અને હોપે તેના પુનઃકનેક્શનમાં ટકી રહેવું પડે. ત્રીસ સેકન્ડ માટે અદૃશ્ય થતું ટ્રાન્ઝિટ સરનામું પૂલ વચ્ચેનો માર્ગ પણ સાથે લઈ જાય છે, જે ડિઝાઇન લક્ષણ છે જેને શોધવાને બદલે જાહેર કરવું યોગ્ય છે.

માલિકીનું નકલી ન કરીને ક્લાયન્ટ રૂટ પુશ કરો

ક્લાયન્ટને દૂરસ્થ પૂલ માટે રૂટ જોઈએ, નહીં તો તેમની પોતાની ઓપરેટિંગ સિસ્ટમ પેકેટને તેના ડિફોલ્ટ ગેટવે પર મોકલે છે અને ટનલ તેને કદી જોતી નથી. સર્વર રૂપરેખાંકન એ આ પહોંચાડવાની કુદરતી જગ્યા છે.

push "route 10.64.20.0 255.255.255.0"

બીજા સર્વરના રૂપરેખાંકનમાં મિરર લાઇન મૂકો, પછી પરીક્ષણ ક્લાયન્ટ ફરી જોડો અને તેનું કોષ્ટક વાંચો. પુશ કરેલા રૂટ અવગણતો ક્લાયન્ટ પોતાનું મંજૂર રૂપરેખાંકન માંગે છે, અને જે રૂટ કદી પહોંચતો નથી તે ઍક્સેસ નિયંત્રણ નથી. બીજા ગેટવેના આખા પૂલ માટે ક્લાયન્ટને iroute આપશો નહીં. એ સૂચના એક જોડાયેલા ક્લાયન્ટ પાછળના સબનેટ માટે છે, અને ગેટવે વચ્ચેના ખૂટતા રૂટને ઢાંકવા તેનો ઉપયોગ કરવાથી બને છે એવું સર્વર જે માને છે કે તે એવા સરનામાં ધરાવે છે જ્યાં પહોંચી શકતું નથી.

એક વિનંતી સાબિત કરો અને બીજી નકારો

વાસ્તવિક ક્રિયા પસંદ કરો, ઉદાહરણ તરીકે 10.64.10.21 પરના ક્લાયન્ટથી 10.64.20.37 પરની સેવા સુધી HTTPS, અને બંને હોસ્ટ પર બરાબર એ જ મંજૂર કરો. દરેક ફાયરવોલ પોતાની ઇનબાઉન્ડ બાજુ વિનંતી અને રિટર્ન બાજુ ટ્રેક કરેલો જવાબ સ્વીકારે છે; લક્ષ્યની પોતાની સેવા નીતિએ પણ તેને સ્વીકારવું પડે.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

પરસ્પર રૂટ સાથે સ્રોત NAT બિનજરૂરી છે અને અહીં સક્રિય રીતે નુકસાનકારક છે: સ્રોતનું ભાષાંતર છુપાવે છે કે કયા ક્લાયન્ટે વિનંતી કરી અને લક્ષ્ય બાજુની સ્રોત-આધારિત નીતિને હરાવે છે. તપાસો કે ઇન્ટરનેટ ઇગ્રેસ માટેનો હાલનો masquerade નિયમ આ માર્ગને પણ પકડતો નથી. પછી નકારની કસોટી કરો. પૂલ B માટે સ્થાનિક રહેવાની સેવા પૂલ A થી અજાણી રહેવી જોઈએ, અને એક જ ગેટવેના ક્લાયન્ટ જોડાં પણ ચકાસવા જોઈએ, કારણ કે તમે હમણાં બદલેલી ફોરવર્ડિંગ નીતિ તેમને પણ લાગુ પડે છે.

માનસિક મોડેલમાં વધુ એક સુધારો: ટ્રાન્ઝિટ કડી ડિક્રિપ્ટ થયેલા આંતરિક પેકેટ વહે છે, તેથી તે ખાનગી બાંયધરી નહીં પણ ભરોસા સીમા છે. જો તે તમે નિયંત્રિત ન કરતા નેટવર્કમાંથી પસાર થાય, તો એ હોપને મંજૂર એન્ક્રિપ્ટેડ ટનલથી સુરક્ષિત કરો અને તેની વાસ્તવિક ટોપોલોજી દ્વારા રૂટ કરો. એન્ડ-ટુ-એન્ડ TLS હજુ પણ એપ્લિકેશનનું પોતાનું પ્રમાણીકરણ કરે છે, તેથી આંતરિક સેવાએ તેનો ઉપયોગ ચાલુ રાખવો જોઈએ.