એક AWS VPN ટનલ પર અનેક LAN: SA મર્યાદાનો અર્થ શું છે
AWS પ્રતિ ટનલ એક IPsec SA જોડીની મંજૂરી આપે છે, અને આ એક-સબનેટ મર્યાદા નથી. પહેલા સુરક્ષા વ્યાપને રૂટિંગ અને ઍક્સેસથી અલગ કરો.
AWS Site-to-Site VPN માં બીજું શાખા LAN ઉમેરવા માટે તે ટનલની અંદર બીજું સ્વતંત્ર IPsec સંગઠન જરૂરી નથી. લોકો જે મર્યાદા પર ઠોકર ખાય છે તે વાસ્તવિક છે, પણ સાંભળવામાં આવે તેના કરતાં સાંકડી છે: AWS દસ્તાવેજ કરે છે પ્રતિ ટનલ એક અનન્ય IPsec SA જોડી, એક આવક અને એક જાવક, અને એક જોડાણની બે ટનલને દરેકને પોતાની જોડી મળે છે. આ સેવાનો ગુણધર્મ છે, એ નિયમ નથી કે IPsec એક સમયે એક સબનેટનું રક્ષણ કરે છે. આ ભેદ સૌથી વધુ ત્યારે મહત્વનો છે જ્યારે નીતિ-આધારિત ગ્રાહક ગેટવે દરેક નીતિ નોંધને તેના પોતાના સંગઠનમાં ફેરવે છે.
LAN યાદી સાથે નહીં, જોડાણ સાથે શરૂ કરો
કન્સોલમાં જોડાણ ખોલો અને તે કેવી રીતે રૂટ થાય છે તે નોંધો. સ્થિર જોડાણ તમે જાહેર કરેલા દૂરસ્થ પ્રીફિક્સ વહન કરે છે. BGP જોડાણ તેમને ગ્રાહક ગેટવેથી શીખે છે.
ગમે તે રીતે, ટનલ રૂટ-આધારિત છે. તેની અંદર શું જાય તે તમારા ઉપકરણ દ્વારા વાટાઘાટ કરાયેલા સિલેક્ટર નક્કી કરે છે, ફોર્મમાં લખી શકાય તેવા સબનેટની સંખ્યા નહીં.
ગ્રાહક ગેટવે શું વાટાઘાટ કરે છે તે જુઓ
નીતિ-આધારિત ઉપકરણ દરેક નીતિ નોંધને તેના પોતાના SA માં ફેરવી શકે છે. બે LAN એટલે બે નોંધ, એટલે બે SA, અને અહીંથી જ પ્રતિ-ટનલ મર્યાદા મહત્વની થવા લાગે છે. ગ્રાહક ગેટવેની આવશ્યકતાઓ બરાબર આ વર્તન અંગે ચેતવણી આપે છે અને તે ઉપકરણો પર એકીકૃત નિયમો સૂચવે છે. બોક્સ પરના ACL ગણતરીને બદલે વાટાઘાટ કરાયેલા સિલેક્ટર તપાસો.
ઉપકરણને એક જ નીતિ હેઠળ બંને પ્રીફિક્સ રજૂ કરવા માટે ગોઠવવું પડશે, નહીં તો દૂરનો છેડો પરિણામ સાચવી શકશે નહીં.
ત્રણ ઇન્વેન્ટરી, અલગ રાખેલી
આ ત્રણ યાદીઓ ભેળવો અને દરેક ફેરફાર અનુમાન બની જાય છે. તેમને અલગ કૉલમ તરીકે રાખો અને દરેકને તમારા પોતાના નેટવર્ક માટે ભરો.
| Inventory | What belongs there |
|---|---|
| Required networks | 10.20.10.0/24 and 10.20.30.0/24, as presented after any deliberate translation |
| Protection agreement | the selectors the tunnel actually negotiated for those prefixes |
| Delivery and permission | VPC routes, return routes, security groups and any filtering |
ફક્ત મધ્યમ કૉલમ SA મર્યાદાથી મર્યાદિત છે. પ્રથમ કૉલમ વ્યાવસાયિક હકીકત છે, અને ત્રીજી કૉલમ એ છે જે એપ્લિકેશનને કામ કરાવે છે. તમે લખેલી ACL લાઇનની સંખ્યા પરથી કવરેજ અનુમાન કરવાને બદલે ઉપકરણ પર સ્વીકૃત સિલેક્ટર વાંચો.
પરવાનગી વિસ્તાર્યા વિના એકીકૃત કરો
સારાંશ રૂટ એ એક નીતિ નોંધ મેળવવાનો સ્પષ્ટ રસ્તો છે, અને તે એ પણ છે કે સંરક્ષિત સમૂહ શાંતિથી કેવી રીતે વધે છે. બંને /24 ને આવરી લેતો /20 એવા સરનામાં પણ આવરી લે છે જે બંનેમાંથી કોઈ શાખા વાપરતી નથી, અને ટનલ તેમને ખુશીથી વહન કરશે. જો તમારે સારાંશ આપવો જ પડે, તો તેને પ્રાપ્તિ બાજુ પર ફિલ્ટરિંગ સાથે જોડો જેથી વધારાની જગ્યા માત્ર જાહેર ન થવા પરંતુ નકારવામાં આવે. નકારાયેલ પેકેટ પુરાવો છે. જાહેર ન કરાયેલ સરનામું ફક્ત પુરાવાની ગેરહાજરી છે.
સુરક્ષા નીતિને એકીકૃત કરવી એ શું એન્ક્રિપ્ટ કરી શકાય તેમાં ફેરફાર છે. તે ઍક્સેસની અનુદાન નથી અને તેને એ રીતે ગણવી ન જોઈએ.
બંને LAN નું પરીક્ષણ કરો, પછી બંને ટનલ રાખો
સંકલિત ફેરફાર પછી સક્રિય સુરક્ષા વ્યાપનું નિરીક્ષણ કરો અને પછી દરેક LAN થી વાસ્તવિક એપ્લિકેશન ચલાવો. એક સબનેટ કામ કરે તે બીજાની સિલેક્ટર કવરેજ વિશે કંઈ સાબિત કરતું નથી, અને તેના જવાબ માર્ગ વિશે તો વધુ નહીં જ.
ડિઝાઇનમાં બંને ટનલ રાખો. નીતિ એકીકૃત કરવી એ રિડંડન્સી ફેંકી દેવાની પરવાનગી નથી, અને દરેક શાખા LAN વહન કરતી એક ટનલ આગલી જાળવણી વિન્ડોને વિક્ષેપમાં ફેરવે છે.
વાટાઘાટ કરાયેલા સિલેક્ટર, બે પ્રીફિક્સ અને રૂટ માલિકોને એક જ ફેરફાર રેકોર્ડમાં લખો. ત્રીજી LAN આવે ત્યારે તે રેકોર્ડ તમને કહેશે કે તમે સિલેક્ટર ઉમેરી રહ્યા છો કે શરૂઆતથી શરૂ કરી રહ્યા છો.