peered VPC સુધી પહોંચવા માટે AWS Client VPN કે bastion
બંને માર્ગ કામ કરે છે, પણ જુદી જગ્યાએ તૂટે છે. endpoint રૂટ, રિટર્ન રૂટિંગ અને જ્યાં bastion પ્રામાણિક સીમા છે તે ત્રણ કિસ્સાઓની સરખામણી કરો.
એક Client VPN endpoint તેના સંકળાયેલ VPC સાથે peered હોય તેવા VPC સુધી પહોંચી શકે છે, અને તેને કાયદેસર બનાવવા માટે તમને bastion ની જરૂર નથી. જે પસંદગી કરવા જેવી છે તે એ છે કે ટ્રાફિક ક્યાં હાથ બદલે છે: endpoint રૂટ જે association સબનેટમાં ઉતરે છે અને peering કનેક્શન પાર કરે છે, અથવા peered VPC માંનું host જે સેશન સમાપ્ત કરે છે. બંને માર્ગ કામ કરે છે અને તેઓ જુદી જગ્યાએ નિષ્ફળ જાય છે, તેથી નિર્ણય માલિકી અને ઓડિટ વિશે છે, AWS શું મંજૂરી આપે છે તે વિશે નહીં. અહીં હું તેમની વચ્ચે કેવી રીતે પસંદ કરું છું, અને તે ચાર એન્ટ્રી જે રૂટેડ માર્ગને કામ કરાવે છે.
બે માર્ગ, એક endpoint, જુદા માલિકો
રૂટેડ માર્ગ પર ક્લાયન્ટ ટ્રાફિક endpoint સુધી પહોંચે છે, association સબનેટમાં Client VPN નેટવર્ક ઇન્ટરફેસના સરનામામાં અનુવાદિત થાય છે, અને A થી B સુધીના peering કનેક્શન દ્વારા તે સબનેટ છોડે છે. VPC B કોઈ VPN સેશન સમાપ્ત કરતું નથી; તે VPC A તરફથી સામાન્ય ટ્રાફિક જુએ છે, તેથી તેનો રિટર્ન રૂટ VPC A તરફ નિર્દેશ કરે છે, ક્લાયન્ટ પૂલ તરફ નહીં.
bastion માર્ગ પર ક્લાયન્ટ પહેલા host સુધી પહોંચે છે. A માંનું bastion હજી પણ છેલ્લી હોપને peering કનેક્શન પાર કરવા દે છે, તેથી તમે peering કામ જાળવી રાખો છો અને સેશન ઉમેરો છો. B માંના bastion ને પણ ક્લાયન્ટ તરફથી માર્ગની જરૂર છે, અને જ્યારે તે માર્ગ એ જ endpoint રૂટ હોય, ત્યારે તમારી પાસે રૂટેડ ડિઝાઇન વત્તા એક હોપ હોય છે. bastion માત્ર ત્યારે જ કામ ઘટાડે છે જ્યારે તે પહેલેથી અસ્તિત્વમાં હોય, પહેલેથી મંજૂર હોય, અને તેની પાછળની વસ્તુને નેટવર્ક સીમાને બદલે સેશન સીમાની જરૂર હોય.
ચાર એન્ટ્રી રૂટેડ માર્ગને કામ કરાવે છે
AWS આ દૃશ્યને Client VPN how-it-works પૃષ્ઠ પર દસ્તાવેજ કરે છે, અને વ્યવહારમાં તે બે કે ત્રણ ટીમોની માલિકીની ચાર એન્ટ્રી પર આવે છે. શ્રેણીઓ દૃષ્ટાંતરૂપ છે; peered શ્રેણી અનન્ય હોવી જોઈએ અને રિટર્ન શ્રેણી તમારી યોજના સાથે મેળ ખાવી જોઈએ.
| Control | What it must say |
|---|---|
| Endpoint route | 10.70.0.0/16 targets the association subnet |
| Authorization rule | The approved group may reach 10.70.0.0/16 |
| VPC A association-subnet table | 10.70.0.0/16 targets the peering connection |
| VPC B resource-subnet table | VPC A's range targets the same peering connection |
રૂટ અને પરવાનગી અલગ નિયંત્રણો છે. મેળ ખાતા ઓથોરાઇઝેશન નિયમ વિનાનો સાચો endpoint રૂટ ક્લાયન્ટને કંઈ આપતો નથી; endpoint રૂટ કરી શકે નહીં તેવા ગંતવ્ય માટેનો ઓથોરાઇઝેશન નિયમ તેને કાળો ખાડો આપે છે. બંનેએ એક જ શ્રેણીનો ઉલ્લેખ કરવો જોઈએ.
endpoint રૂટ endpoint ના પોતાના VPC માંના સબનેટ તરફ નિર્દેશ કરે છે, ક્યારેય peering કનેક્શન તરફ નહીં. VPC રૂટ કોષ્ટકો peering કનેક્શન તરફ નિર્દેશ કરે છે, ક્યારેય instance કે ઇન્ટરફેસ તરફ નહીં. બંને વચ્ચે મૂલ્યની નકલ કોઈ ફરિયાદ વિના સંગ્રહાય છે અને કંઈ રૂટ કરતી નથી.
કારણ કે association સબનેટ ક્લાયન્ટનું સ્રોત અનુવાદિત કરે છે, B એ ક્લાયન્ટ પૂલ તરફ નહીં, VPC A તરફ પાછું રૂટ કરવું જોઈએ. peering કનેક્શન પર ક્લાયન્ટ શ્રેણી મોકલવી સમમિત લાગે છે, સમીક્ષા પસાર કરે છે અને શાંતિથી નિષ્ફળ જાય છે કારણ કે B ક્યારેય ક્લાયન્ટ સ્રોતવાળું પેકેટ જોતું નથી.
સિક્યોરિટી ગ્રુપ અને પરવાનગીનો છેલ્લો મીટર
રૂટિંગ પેકેટને B માં લાવે છે; B હજી નિર્ણય લે છે. એક જ પ્રદેશમાં સક્રિય peering કનેક્શન માટે, B માંનું સિક્યોરિટી ગ્રુપ Client VPN association પર લાગુ થયેલા ગ્રુપનો સંદર્ભ લઈ શકે છે, જે નિયમને સાંકડો રાખે છે અને સરનામાંના ફેરફારોમાં ટકી રહે છે. જ્યાં ગ્રુપ સંદર્ભ શક્ય ન હોય, ત્યાં 0.0.0.0/0 સુધી પહોળું કરવાને બદલે association સબનેટની શ્રેણીને સ્પષ્ટપણે મંજૂરી આપો, કારણ કે તે રૂટિંગ ભૂલને અસ્પષ્ટ ટાઇમઆઉટમાં ફેરવે છે.
પછી જુઓ કે રૂટિંગ ક્યારેય શું સ્પર્શતું નથી: બંને સબનેટ પરના નેટવર્ક ACL, એપ્લિકેશનની allow-list કે ટોકન ઑડિયન્સ, અને DNS. peering ખાનગી hosted ઝોનની નકલ કરતું નથી, તેથી લેપટોપ એવા સરનામા સુધી કાર્યકારી રૂટ રાખી શકે છે જે તે ઉકેલી શકતું નથી, અને peering કનેક્શન પ્રમાણપત્રમાં કોઈ વિશ્વાસ ઉમેરતું નથી. endpoint ને B માટે જવાબ આપતા resolver તરફ નિર્દેશ કરો, પછી ખાતરી કરો કે ખાનગી નામ અને પ્રમાણપત્ર મેળ ખાય છે.
ક્યારે bastion પ્રામાણિક જવાબ છે
હું જાણી જોઈને bastion પસંદ કરવા માટે ત્રણ ટ્રિગર રાખું છું. peered VPC એવી ટીમનું છે જે તમારી શ્રેણી માટે રિટર્ન રૂટ ઉમેરશે નહીં અથવા ગ્રુપ સંદર્ભ સ્વીકારશે નહીં. ઍક્સેસ દરેક સેશન માટે મંજૂર કે રેકોર્ડ થવી જોઈએ અને એપ્લિકેશન તે જાતે ઉપાડી શકતી નથી. અથવા છેલ્લી હોપ B ની અંદર જ રહેવી જોઈએ કારણ કે સેવા ફક્ત ત્યાં જ ઉકેલાય છે અને તેની TLS ઓળખ આંતરિક નામ સાથે પિન થયેલી છે.
આમાંથી કંઈપણ peering બિન-ટ્રાન્ઝિટિવ હોવાની હકીકતની આસપાસનો રસ્તો નથી. બિન-ટ્રાન્ઝિટિવિટી B માંના સ્રોતો શું કરી શકે તે મર્યાદિત કરે છે: તેઓ A ને ત્રીજા VPC તરફ ટ્રાન્ઝિટ તરીકે વાપરી શકતા નથી જેની સાથે A peered છે. તેનો અર્થ ક્યારેય એ નહોતો કે VPN વપરાશકર્તા સીધા peered VPC સુધી પહોંચી શકતો નથી, અને તે ખોટા વાંચનને ટાળવા માટે બનાવેલું bastion એ કારણ વિના પેચ કરવાનું host છે.
ઊલટી ભૂલ સમય સાથે વધુ ખર્ચ કરે છે: દરેક ટીમને પહેલેથી અસ્તિત્વમાં હોય તેવા એકમાત્ર bastion દ્વારા પસાર કરો, પછી શોધો કે તેનું સિક્યોરિટી ગ્રુપ, રૂટ કોષ્ટક અને પેચ વિન્ડો જ પ્રોડક્શન આધાર છે. host કયા ટ્રિગરની સેવા કરે છે તે લખો, અને ટ્રિગર જાય ત્યારે તેને નિવૃત્ત કરો.
Transit Gateway અને અનેક association ગણતરી બદલે છે
જો endpoint સબનેટને બદલે સીધું Transit Gateway સાથે જોડાયેલું હોય, તો મોડેલ બદલાય છે: ક્લાયન્ટ હવે association સબનેટમાં ઇન્ટરફેસ સરનામામાં અનુવાદિત થતા નથી, અને gateway રૂટ કોષ્ટકોએ ક્લાયન્ટ શ્રેણી ઉપરાંત peered VPC તરફ લઈ જતું જોડાણ પણ રાખવું પડે છે. માપમાં તે વધુ સ્વચ્છ છે, પણ કામ ચાર એન્ટ્રીમાંથી gateway રૂટ કોષ્ટકોમાં ખસે છે.
અનેક association તપાસને ગુણકરે છે. endpoint રૂટ endpointનો છે, તેમ છતાં દરેક association સબનેટને વાસ્તવિક peering નેક્સ્ટ હોપવાળું રૂટ કોષ્ટક જોઈએ. એક association દ્વારા સેશન સફળ થઈ શકે જ્યારે બીજા પાસે રિટર્ન માર્ગ ન હોય, તેથી દરેકને ચકાસો.
ભંગાણ ઝડપથી શોધતો ચકાસણી ક્રમ
આને ક્રમમાં ચલાવો; દરેક પગલું પસાર થઈ શકે જ્યારે આગળનું નિષ્ફળ જાય, અને ક્લાયન્ટ ટાઇમઆઉટ લગભગ ક્યારેય કહેતું નથી કે કયું તૂટ્યું.
- ક્લાયન્ટથી એપ્લિકેશનનું નામ ઉકેલો અને તપાસો કે સરનામું peered શ્રેણીની અંદર છે.
- કનેક્ટ કરો, પછી જે association એ સેશન સમાપ્ત કર્યું તેના માટે endpoint કનેક્શન લોગ વાંચો.
- તે association સબનેટ પર ખાતરી કરો કે રૂટ કોષ્ટક peered શ્રેણીને સક્રિય peering કનેક્શન તરફ નિર્દેશ કરે છે.
- B માંના સ્રોત સબનેટ પર ઇન્ટરફેસ શ્રેણી માટે રિટર્ન એન્ટ્રી અને મેળ ખાતા ગ્રુપ નિયમોની ખાતરી કરો.
- એક મંજૂર કામગીરી અને એક એવા સ્રોતનું પરીક્ષણ કરો જે અગમ્ય રહેવો જોઈએ; બીજું ડિબગિંગના અવશેષ પકડે છે.
- કોઈપણ split-tunnel રૂટ ફેરફાર પછી ફરી કનેક્ટ કરો, કારણ કે ચાલુ ટનલ નવો રૂટ સેટ લેશે નહીં.
બે લક્ષણો યાદ રાખવા યોગ્ય છે. B સુધી પહોંચીને જવાબ વિનાનું SYN લગભગ હંમેશા ખૂટતું રિટર્ન રૂટ હોય છે. પૂર્ણ થઈને પછી રીસેટ થતું કનેક્શન સામાન્ય રીતે ગ્રુપ, ACL કે એપ્લિકેશન હોય છે. બંનેય endpoint લોગમાં કારણ તરીકે દેખાતા નથી, તેથી ચાર એન્ટ્રી દરેકની બાજુમાં માલિક સાથે રાખો.
જો ત્રણમાંથી કોઈ ટ્રિગર લાગુ ન પડે, તો રૂટેડ માર્ગ પૂરો કરો અને તે ચાર એન્ટ્રી નોંધો. જો એક લાગુ પડે, તો bastion ફક્ત તે સીમા માટે રાખો અને જે સેવાઓને સામે સેશનની જરૂર નથી તેમને endpoint રૂટ આપો.