એક AWS Client VPN સેશન પાછળનું LAN: શું ફોરવર્ડ થાય છે

લેપટોપ AWS Client VPN એન્ડપોઇન્ટ સાથે જોડાય છે, ખાનગી સબનેટ સુધી પહોંચે છે, અને બધું સ્વસ્થ લાગે છે. તે જ LAN પરનું ડેસ્કટોપ ક્યાંય પણ પહોંચતું નથી, જોકે Linux હોસ્ટમાં પણ બ્રિજ ઇન્ટરફેસ છે અને બંને મશીન એક જ વાયર પર છે. ટનલમાં કંઈ ખોટું કન્ફિગર થયેલું નથી; ખૂટતો ભાગ રૂટિંગ છે, અને બ્રિજ એ ભ્રામક સંકેત છે.

Client VPN સેશનને LAN સુધી લંબાવવું એ ગેટવેની ભૂમિકા છે. તે મેનેજ્ડ સેવામાં ખેંચાયેલો Ethernet સેગમેન્ટ નથી.

હોસ્ટ કામ કરે છે અને LAN નહીં

Linux બોક્સ પરના ટનલ ઇન્ટરફેસનું સરનામું Client VPN ક્લાયન્ટ CIDR ની અંદર છે, અને એન્ડપોઇન્ટે VPC શ્રેણીઓ માટે રૂટ પુશ કર્યા છે. તે બોક્સ પર કરાયેલી વિનંતી સ્થાનિક રીતે ઉત્પન્ન થયેલ ટ્રાફિક છે: તે રૂટ પસંદ કરે છે, ટનલ દ્વારા બહાર જાય છે અને જવાબ મેળવે છે. તે માર્ગ ક્યારેય ફોરવર્ડિંગ કોડ, LAN ઇન્ટરફેસ કે ટ્રાન્ઝિટને નિયંત્રિત કરતા કોઈપણ ફાયરવોલ નિયમને સ્પર્શતો નથી.

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

દરેક ક્લાયન્ટ ગેટવે બની શકતું નથી

AWS જણાવે છે કે તેની Client VPN ડેસ્કટોપ એપ્લિકેશન IP ફોરવર્ડિંગને સમર્થન આપતી નથી, અને અન્ય ક્લાયન્ટ આપી શકે છે. તે પ્રતિબંધ કોઈપણ આદેશ ટાઇપ કરવા પહેલાં આર્કિટેક્ચર નક્કી કરે છે. જો ઉપલબ્ધ એકમાત્ર ક્લાયન્ટ સત્તાવાર ડેસ્કટોપ એપ હોય, તો LAN માટે ફોરવર્ડ કરતું Linux ગેટવે એવું કન્ફિગરેશન નથી જે તમે પૂર્ણ કરી શકો, અને કોઈપણ પ્રમાણમાં masquerading તેને બદલશે નહીં.

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

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

LAN ને ટનલ તરફ દોરો અને તેનું અનુવાદ કરો

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

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

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

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

જવાબને પણ માર્ગની જરૂર છે

વિનંતી VPC સુધી પહોંચ્યા પછી, જવાબે એ જ અનુવાદ સ્થિતિઓમાંથી પાછો આવવો જોઈએ અને ગેટવે પર LAN રૂટ શોધવો જોઈએ. તે ભાગ સામાન્ય રીતે ત્યારે કામ કરે છે જ્યારે masquerade નિયમ જગ્યાએ હોય, કારણ કે મેપિંગ તે હોસ્ટ પર રહે છે જેણે તે કર્યું. જ્યારે VPC બાજુએ એવો રૂટ હોય જે જવાબ બીજે મોકલે ત્યારે તે તૂટે છે, અને તેથી જ ક્લાયન્ટ CIDR રૂટ અને એન્ડપોઇન્ટ પરનું સબનેટ જોડાણ બંને મહત્ત્વના છે.

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

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

શેર કરેલી ઓળખ એ ભાગ છે જેનો જવાબ નીતિએ આપવો પડે

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

તે સ્વીકાર્ય હોઈ શકે, અથવા ડિઝાઇન નામંજૂર થવાનું કારણ હોઈ શકે. તે VPC સંસાધનો કોણ કૉલ કરે છે તે વિશે શું ધારે છે તેના પર આધાર રાખે છે. અધિકૃતિ મોડેલમાં ફિટ થતી શેર કરેલી ઓળખ ઠીક છે; જે ચૂપચાપ એક પ્રમાણિત સેશનને આખા LAN ની ઍક્સેસમાં ફેરવે છે તે લખાવાની રાહ જોતી શોધ છે.

જો જરૂરિયાત ખરેખર આખી સાઇટને VPC સાથે જોડવાની હોય, તો રિમોટ-ઍક્સેસ ક્લાયન્ટ લંબાવતા પહેલાં સમર્થિત સાઇટ-થી-સાઇટ ડિઝાઇનની સરખામણી કરો. અર્થશાસ્ત્ર અલગ છે, અને જ્યારે VPC ને LAN માં જોડાણો શરૂ કરવાની જરૂર હોય ત્યારે NAT કરેલું ક્લાયન્ટ સેશન સાઇટ લિંક માટે નબળો વિકલ્પ છે.

ક્લાયન્ટ, રૂટ, અનુવાદ અને ઓળખની વાર્તા એ જ ક્રમમાં નક્કી કરો. દરેક આગળના એકને મર્યાદિત કરે છે, અને ક્રમ સમજાવે છે કે હોસ્ટ કેમ કામ કરે છે જ્યારે LAN નહીં.