ક્લાઉડ સરહદ પર VPN ક્લાયન્ટની IP સાચવો અથવા SNAT કરો

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

ત્રણ શરતો તે નક્કી કરે છે

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

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

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

માર્ગ એ છેતરપિંડીની પરવાનગી નથી

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

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

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

ઝડપી પેકેટ કેપ્ચર કન્સોલ વાંચવા કરતાં પ્રશ્ન ઝડપથી ઉકેલે છે. જો જવાબો નીકળી જાય અને ક્લાયન્ટ તેમને ક્યારેય ન જુએ, તો ફેબ્રિક નકલી સ્રોતને ફેંકી દે છે, એપ્લિકેશન નિષ્ફળ જતી નથી.

અનુવાદ શું ખરીદે છે અને શું ખર્ચ કરાવે છે

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

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

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

રિલે એ અલગ ઇન્ટરફેસ છે

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

તે હેડર ફક્ત ત્યારે જ વિશ્વસનીય છે જ્યારે બેકએન્ડ તેને પ્રોક્સી પાસેથી સ્વીકારે અને બીજા કોઈ પાસેથી નહીં. nginx ની દ્રષ્ટિએ તેનો અર્થ એ છે કે જે આવે તેને માનવાને બદલે વિશ્વસનીય સાથીનું નામ સ્પષ્ટપણે આપવું:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

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

રિલે તમે શું ખરીદો છો તે પણ બદલે છે. તમને એપ્લિકેશન-સ્તરીય ઓળખ અને તેને લોગ કરવાની કુદરતી જગ્યા મળે છે; તમે સામાન્યતા ગુમાવો છો, કારણ કે દરેક નવા પ્રોટોકોલને પોતાનું પ્રોક્સી સમર્થન જોઈએ છે. HTTP સેવાઓ માટે આ બદલો સામાન્ય રીતે સારો છે, અને જે HTTP નથી તેના માટે સામાન્ય રીતે તે જરાય ઉપલબ્ધ નથી.

દરેક સરહદ શું જુએ છે તે લખો

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

પછી પસંદ કરો. જ્યારે એપ્લિકેશનની અધિકૃતિ ખરેખર ક્લાયન્ટ સરનામા પર આધારિત હોય અને તમે માર્ગની જવાબદારી લઈ શકો ત્યારે સ્રોત સાચવો. જ્યારે એમ ન હોય અને તમે ઓળખ બહારના માર્ગે રાખી શકો ત્યારે અનુવાદ કરો, અને પ્લેટફોર્મ-વિશિષ્ટ ફોરવર્ડિંગ સેટિંગ્સ માટે AWS ફોરવર્ડિંગ-ઇન્સ્ટન્સ માર્ગદર્શિકા વાપરો. રિલે તરફ જાઓ જ્યારે સેવા HTTP બોલે છે અને તમે ઇચ્છો છો કે ઓળખ બિલકુલ સરનામું ન રહે.