NAT પાછળનું FortiGate: local-gw, localid અને જાહેર IP

NAT પાછળનું FortiGate તેના WAN ઇન્ટરફેસ પર 10.0.0.2 ધરાવી શકે છે, જ્યારે ઇન્ટરનેટ તેને 198.51.100.40 તરીકે રજૂ કરે છે, અને બંને સંખ્યાઓ વાસ્તવિક છે. ઉપકરણ જે સરનામા સાથે બંધાય છે અને IKE પ્રમાણીકરણ દરમિયાન જે ઓળખ મોકલે છે તે અલગ નિર્ણયો છે, અલગ ફીલ્ડમાં, અલગ પ્રેક્ષકો માટે લેવાયેલા. NAT પસાર થતી વખતે બહારનું સરનામું ફરીથી લખે છે; પ્રમાણિત ઓળખને દૂરના પીઅરની અપેક્ષા મુજબ ફરીથી લખતું નથી. આ સ્વરૂપમાં મોટાભાગની ફેઝ 1 નિષ્ફળતાઓ સાચી કિંમત ખોટા ફીલ્ડમાં મૂકવાથી આવે છે.

ત્રણ કિંમતો, ત્રણ માલિકો

ત્રણ કિંમતો અને દરેકનો માલિક કોણ છે તે નામ આપીને શરૂ કરો. local-gw એ સરનામું છે જે FortiGate તેના બાહ્ય ઇન્ટરફેસ પર IKE માટે સ્રોત તરીકે વાપરે છે, અને તે એવું સરનામું હોવું જોઈએ જે ઉપકરણ પાસે ખરેખર હોય. જાહેર એન્ડપોઇન્ટ એ NAT ઉપકરણનું સરનામું છે, અને તે અનુવાદ કરનારની માલિકીનું છે. IKE ઓળખ એ શબ્દમાળા છે જે પીઅર તેની પોતાની રૂપરેખા સાથે મેળવે છે, અને તે IP સરનામું હોવું જરૂરી નથી.

ફીલ્ડના નામ એટલા નજીક છે કે બદલી કરવાનું આમંત્રણ આપે, અને એ જ જાળ છે. localid અને localid-type ઓળખ વર્ણવે છે; local-gw સ્થાનિક બંધન વર્ણવે છે.

એક ઉદાહરણ તફાવતને મૂર્ત બનાવે છે. FortiGate પર, config vpn ipsec phase1-interface ખોલો, પછી set interface "wan1" અને set local-gw 10.0.0.2 — એ સરનામું જે બોક્સ પાસે છે, અને એ જ IKE સોકેટને સફળતાપૂર્વક બંધાવા દે છે. local-gw ને 0.0.0.0 પર છોડી દો તો ઇન્ટરફેસનું સરનામું વપરાય છે, જે સામાન્ય રીતે એ જ વસ્તુ છે પણ ઓછું સ્પષ્ટ. local-gw ને 198.51.100.40 પર સેટ કરશો નહીં, કારણ કે ઉપકરણ પાસે એ સરનામું નથી અને સોકેટ તેની સાથે બંધાશે નહીં. બે કિંમતોને કાગળ પર સમાન દેખાડવી એ રૂપરેખા નથી.

પગલું 1: પીઅર જે ઓળખ સ્વીકારશે તે પસંદ કરો

હવે ઓળખ, જે અલગ નિર્ણય છે. set localid એ કિંમત લે છે જે પીઅર સરખાવશે, અને set localid-type FortiGate ને કહે છે કે તેને કેવી રીતે અર્થઘટન કરવું: સરનામું, FQDN, વપરાશકર્તા FQDN અથવા કી ID. auto સાથે ઉપકરણ તેને મેળવે છે, સામાન્ય રીતે બહાર જતા ઇન્ટરફેસના સરનામામાંથી, જે બરાબર એ જ કિંમત છે જે NAT ઉપકરણ બદલવા જઈ રહ્યું છે.

એ મેળવણી એ કારણ છે કે આ ટોપોલોજીમાં સ્પષ્ટ ઓળખ કેમ મહત્વની છે. જો પીઅર સરનામા-ઓળખની અપેક્ષા રાખે, તો localid-type address અને localid ને એ જાહેર સરનામા પર સેટ કરો જે પીઅર જોશે, પછી ખાતરી કરો કે પીઅર એ કિંમતને રૂટિંગ લક્ષ્ય તરીકે નહીં પણ ઓળખ તરીકે સ્વીકારે છે. જો પીઅર FQDN ની અપેક્ષા રાખે, તો localid-type fqdn અને જે નામ સાથે તે રૂપરેખાંકિત થયું હતું તે વાપરો. ખરેખર શું મોકલાયું તે diagnose vpn ike gateway list થી ચકાસો, જે ગેટવેની સ્થિતિ અને વપરાતા ઓળખકર્તાઓ દર્શાવે છે, તમે શું લખવાનું વિચાર્યું હતું તે નહીં. એવું ન માનો કે ઓળખ-પ્રકારનો વિકલ્પ કોઈપણ બિન-સ્થાનિક સરનામું સ્વીકારે છે; પહેલા આવૃત્તિની દસ્તાવેજી અર્થઘટન તપાસો.

પગલું 2: UDP 500 અને 4500 ઉપકરણ પર ફોરવર્ડ કરો

ત્રીજી કિંમત NAT ઉપકરણની છે, અને એ જ છે જે લોકો તપાસવાનું ભૂલી જાય છે. જાહેર એન્ડપોઇન્ટે UDP 500 અને UDP 4500 FortiGate પર ફોરવર્ડ કરવા જોઈએ, કારણ કે NAT-T શોધ અને તેના પછીનું એન્કેપ્સ્યુલેટેડ ESP બંને એ પોર્ટ આવવા પર આધાર રાખે છે. આ ડિઝાઇન એક-થી-એક મેપિંગ ધારે છે; એક જાહેર સરનામાને અનેક પીઅર વચ્ચે પોર્ટ આધારિત વહેંચવું એ અલગ મર્યાદાઓવાળી અલગ ટોપોલોજી છે.

ફોરવર્ડિંગ કેપ્ચરથી ખાતરી કરો, આશાથી નહીં: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 પેકેટ આવે છે કે નહીં અને જવાબો જાય છે કે નહીં તે દર્શાવે છે.

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

પગલું 3: ફેઝ 1 શું ઉકેલતું નથી તે તપાસો

NAT ટ્રાવર્સલ ટનલ ઉપર લાવે છે, ઓળખની સંમતિ નક્કી કરે છે કે પીઅર તેને સ્વીકારશે કે નહીં, અને આંતરિક પ્રીફિક્સ રૂટિંગ નક્કી કરે છે કે ખરેખર શું પસાર થાય છે. સાચું સ્થાનિક ID ગુમ થયેલ સ્ટેટિક રૂટ કે ગુમ થયેલ ટ્રાફિક સિલેક્ટર પૂરું પાડી શકતું નથી.

તેથી સ્તરે સ્તરે ચકાસો. get vpn ipsec tunnel details ટનલ ઉપર છે કે નહીં અને કયા સિલેક્ટરની વાટાઘાટ થઈ તે દર્શાવે છે, અને રૂપરેખાંકિત દૂરના સબનેટ અને વાટાઘાટ થયેલ સિલેક્ટર વચ્ચેની અસંગતિ ફેઝ 2 ના વેશમાં રૂટિંગ સમસ્યા છે. execute vpn ike gateway clear ફરીથી વાટાઘાટ કરવાની ફરજ પાડે છે, તેથી તમે વર્તમાન રૂપરેખા ચકાસી રહ્યા છો, તમારા છેલ્લા ફેરફાર પહેલા સ્થાપિત સત્ર નહીં. પછી દૂરના પ્રીફિક્સમાંના હોસ્ટ પર ટ્રાફિક મોકલો અને ખાતરી કરો કે કાઉન્ટર ખસે છે, કારણ કે ઉપર હોય પણ કંઈ પસાર ન કરતી ટનલ ચકાસો ત્યાં સુધી કાર્યરત ટનલ જેવી જ દેખાય છે.

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

NAT ઉપકરણનું ફરી નંબરીકરણ FortiGate ના local-gw ને સ્પર્શવાનું કારણ નથી, અને ઓળખ બદલવી કંઈપણ ફરી નંબર કરવાનું કારણ નથી. બંનેને ભેગા કરવા એ જ રીત છે જેમાં કાર્યરત ટનલ અસંબંધિત જાળવણી વિન્ડો દરમિયાન ફરી બને છે. Cloud VPN NAT માર્ગદર્શિકા તે બાજુની સમર્થિત ટોપોલોજી માટેનો સંદર્ભ છે.

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