AWS NAT ગેટવે દ્વારા GRE અને ESP કેમ નિષ્ફળ જાય છે

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

નિયમોનો સમૂહ પ્રોટોકોલનો સમૂહ નથી

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

AWS નું NAT ગેટવે પ્રોટોકોલ સ્પેસિફિકેશન મેનેજ્ડ સેવા માટે TCP, UDP અને ICMPની સૂચિ આપે છે. તે આખો સમર્થિત સમૂહ છે. બીજા IP પ્રોટોકોલ માટેનો પરવાનગી નિયમ તેને વિસ્તારી શકતો નથી, કારણ કે નિયમ ગેટવેના ફોરવર્ડિંગ પાથ સુધી પહોંચતા ઘણા પહેલાં મૂલ્યાંકન કરવામાં આવે છે.

આ તફાવત મહત્વનો છે કારણ કે બંને નિષ્ફળતા ક્લાયન્ટની દ્રષ્ટિએ સમાન દેખાય છે અને તેમના સંપૂર્ણપણે અલગ ઉકેલો છે.

PPTP બતાવે છે કે પોર્ટ પરીક્ષણ કેમ ખોટું બોલે છે

PPTP એ પોર્ટ ચકાસણીનું સૌથી સ્પષ્ટ જૂનું ઉદાહરણ છે જે કંઈ સાબિત કરતું નથી. તે પોર્ટ 1723 પર TCP નિયંત્રણ જોડાણ ખોલે છે અને પછી ટનલ ડેટા GRE પર વહન કરે છે, જે IP પ્રોટોકોલ 47 છે. પ્રોટોકોલ 47 એ TCP પોર્ટ 47 નથી, અને આ બે સંખ્યાઓનો એકબીજા સાથે અંક વહેંચવા સિવાય કોઈ સંબંધ નથી.

જે ઓપરેટર 1723 સાથે જોડાણ ચકાસે છે અને પૂર્ણ થયેલું હેન્ડશેક જુએ છે તે તારણ કાઢે છે કે માર્ગ કામ કરે છે. પછી ડેટા ચેનલ ક્યારેય એક પણ પેકેટ પસાર કરતી નથી, કારણ કે ગેટવે પાસે આપવા માટે કોઈ GRE આધાર નથી. આ જૂના પ્રોટોકોલની જરૂરિયાતોનું અર્થઘટન છે, PPTP લાગુ કરવાની સલાહ નથી, જે વર્ષોથી અપ્રચલિત છે.

એ જ તર્ક કોઈપણ પ્રોટોકોલને લાગુ પડે છે જેની નિયંત્રણ ચેનલ TCP કે UDP છે જ્યારે તેનો ડેટા માર્ગ એવો નથી.

IPsec ફક્ત UDP તરીકે ટકી રહે છે

IPsec એ કિસ્સો છે જ્યાં જવાબ સપાટ ના નહીં પરંતુ શરતી છે. AWS NAT ગેટવે દ્વારા IPsec માટે NAT ટ્રાવર્સલને સમર્થિત ગોઠવણી તરીકે દસ્તાવેજીકૃત કરે છે. NAT-T વાટાઘાટ થયા પછી, ESP UDPની અંદર એન્કેપ્સ્યુલેટ થાય છે અને ગેટવે પ્રોટોકોલ 50ને બદલે સામાન્ય UDP જુએ છે.

UDP 4500 મંજૂર કરવાથી એન્ડપોઇન્ટ NAT ટ્રાવર્સલનો ઉપયોગ કરવા લાગતા નથી. તે પેકેટને ફક્ત ત્યારે મંજૂર કરે છે જ્યારે તે પહેલેથી તે આકારમાં હોય. ક્લાયન્ટના પોતાના વાટાઘાટ આઉટપુટમાંથી ખાતરી કરો કે કયું એન્કેપ્સ્યુલેશન પસંદ થયું, અને પ્રાપ્ત કરનારી બાજુ પર ખાતરી કરો કે સાથીએ તેને સ્વીકાર્યું. નેટિવ ESP માટે ગોઠવાયેલા બે એન્ડપોઇન્ટ નિયમોનો સમૂહ શું કહે તે ધ્યાનમાં લીધા વિના નેટિવ ESP મોકલવાનું ચાલુ રાખશે.

TCP કે UDP આધારિત VPN દસ્તાવેજીકૃત પરિવહન સમૂહમાં બંધ બેસે છે અને તેમ છતાં રૂટિંગ, ફિલ્ટરિંગ કે પ્રમાણીકરણના કારણોસર નિષ્ફળ થઈ શકે છે. સમૂહમાં બંધ બેસવું જરૂરી છે, પર્યાપ્ત નથી.

નીતિ વિસ્તારતા પહેલાં માર્ગ ચકાસો

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

પછી પ્રયાસ કરેલ એન્ડપોઇન્ટ, એડ્રેસ ફેમિલી, બાહ્ય પ્રોટોકોલ અને પોર્ટ જ્યાં પ્રોટોકોલમાં હોય ત્યાં નોંધો. સફળ બ્રાઉઝર વિનંતીને બદલે ક્લાયન્ટની ડાયગ્નોસ્ટિક્સ અને નેટવર્ક માલિકના ફ્લો અવલોકનોનો ઉપયોગ કરો, જે ફક્ત એ સાબિત કરે છે કે TCP અને UDP કામ કરે છે. તે પછી, ફ્લોની બંને દિશાઓ માટે સિક્યુરિટી ગ્રુપ, સબનેટ ACL, ગેસ્ટ ફાયરવોલ અને સેવા નીતિની સમીક્ષા કરો.

સેવા જે પરિવહન વહન કરી શકતી નથી તેની ભરપાઈ માટે બધો ટ્રાફિક ખોલશો નહીં. નિયમ ફેરફાર તેને સુધારશે નહીં, અને તે ઘટનાને ટકી રહેશે.

જ્યારે પરિવહન બંધ ન બેસે

જો બાહ્ય પ્રોટોકોલ સમર્થિત સમૂહની બહાર હોય, તો ઉકેલ સ્થાપત્યગત છે: એવું પરિવહન પસંદ કરો જે માર્ગ વહન કરી શકે, અથવા એગ્રેસને એવી વસ્તુ પર ખસેડો જે તમને જરૂરી હોય તે વહન કરે. OpenVPN UDP પર, UDP પર WireGuard અને TLS આધારિત ટનલ બધા દસ્તાવેજીકૃત સમૂહમાં બંધ બેસે છે. ગ્રાહક-સંચાલિત NAT ઇન્સ્ટન્સ એ વિકલ્પ છે જ્યારે ચોક્કસ પ્રોટોકોલ પસાર થવો જોઈએ અને તેને ચલાવવાનો ઓપરેશનલ ખર્ચ સ્વીકાર્ય હોય.

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

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