એક OpenVPN ક્લાયન્ટને SSH દ્વારા બીજા સુધી પહોંચવા દો, પૂલ ખોલ્યા વિના

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

યંત્રણા નિયમના પાઠ કરતાં વધુ મહત્ત્વની છે, કારણ કે બંને અભિગમ પેકેટને જુદી જુદી જગ્યાએ મૂકે છે. તમે કયો પસંદ કર્યો તે જાણવું કંઈ ન કરતું લાગતું નિયમ અને તેના વિના જોડાતા સહકર્મી બંનેને સમજાવે છે.

client-to-client પેકેટને ક્યાં ખસેડે છે

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

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

સહકર્મીનું પેકેટ ખરેખર જે માર્ગ લે છે

ધારો કે Linux Community OpenVPN 2.6 સેવા, DCO ને બદલે વપરાશકર્તા જગ્યામાં TUN પ્રક્રિયા, સબનેટ ટોપોલોજી, tun0, અને 10.44.0.0/24 નો પૂલ જેમાં ક્લાયન્ટ A 10.44.0.21 પર અને ક્લાયન્ટ B 10.44.0.37 પર છે. સબનેટ ટોપોલોજીમાં A ને મળેલું સરનામું અને નેટમાસ્ક પહેલેથી પૂલ ઢાંકે છે, તેથી A કોઈ વધારાના ધકેલાયેલા રૂટ વિના પેકેટ ટનલ ઉપકરણને મોકલે છે. A પર અસરકારક રૂટ તપાસો, ધારો નહીં.

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

સર્વર પર બે નિયમ, આ જ ક્રમમાં

ત્રણ નિયમ આખી પરવાનગી ઉપાડે છે: ફોરવર્ડિંગ, જોડીનો અપવાદ, અને ટનલ જોડી માટે ડિફોલ્ટ ડ્રોપ. સ્વીકૃતિ નિયમ જોડી અને સેવાનું નામ લે છે, તેથી પરવાનગી વધતા પૂલમાં ટકે છે. તેને ટનલ-થી-ટનલ ટ્રાફિકની કોઈપણ વ્યાપક ના પહેલાં મૂકો, કારણ કે પહેલી મેળ જ જીતે છે:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

એ આદેશો ઉદાહરણ છે અને તમારો હોસ્ટ નિયમો સાચવવા જે યંત્રણા વાપરે છે તેની છે; ચાલુ હોય ત્યારે નાખેલો નિયમ આગલી બૂટ પર અદૃશ્ય થાય છે. સ્થિતિવાળો નિયમ જ B ના જવાબો અને TCP હેન્ડશેકને બીજી, પ્રતિબિંબિત સ્વીકૃતિ વગર પાછા આવવા દે છે.

પછી નિયમોની યાદી નહીં, કાઉન્ટર તપાસો, કારણ કે જે નિયમ ક્યારેય મળતો નથી તે કામ કરતા જેવો જ દેખાય છે. જો કાઉન્ટર શૂન્ય પર રહે, તો પેકેટ તમે ધારો છો તે માર્ગ નથી લેતું.

B ને હજી શું પરવાનગી આપવી પડશે

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

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

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