IKE ઓળખ કે એન્ડપોઇન્ટ સરનામું: આ બેને ભેગા ન કરો
FQDN પ્રકારની IKE ઓળખ એ શાબ્દિક પ્રમાણીકરણ મૂલ્ય છે, રિવર્સ-DNS શોધ નહીં. એન્ડપોઇન્ટ સરનામું, સ્થાનિક ઓળખ અને અપેક્ષિત peer અલગ રાખો.
FQDN ઓળખ તરીકે લેબલ કરેલા ફીલ્ડને શાબ્દિક શબ્દમાળા તરીકે વાંચો, તમારા જાહેર સરનામાના રિવર્સ-DNS નામની વિનંતી તરીકે નહીં. strongSwan ના પાર્સરમાં તે બરાબર એ જ છે, એક શબ્દમાળા, અને તેને વાંચવાથી તે ક્યારેય એન્ડપોઇન્ટમાં ઉકેલાતું નથી. એ હકીકત જ સૌથી સામાન્ય વિક્ષેપ દૂર કરે છે જ્યારે તમે peer માટે ઓળખકર્તા પસંદ કરો છો. નીચેની ચકાસણીઓ ત્રણ સંબંધિત મૂલ્યોને એકમાં ભળતા અટકાવે છે.
લેબલ એ શોધ નથી
વેન્ડર ઇન્ટરફેસ FQDN અને hostname જેવા શબ્દો ઢીલા રીતે વાપરે છે, અને બોક્સ પરનું લેબલ તેની પાછળના એન્કોડિંગ વિશે કંઈ કહેતું નથી. Client FQDN કહેતું ઉપકરણ FQDN, ઈમેલ આકારની શબ્દમાળા કે નક્કર સરનામું મોકલી શકે છે. ટેક્સ્ટ અને પ્રકારને બે અલગ નિર્ણય તરીકે ગણો અને બંને નોંધો.
શાબ્દિક ઓળખમાં કંઈપણ DNS ની જરૂર માંગતું નથી. તે એક દાવો છે જે બીજો છેડો ચકાસે છે, એવું નામ નહીં જે નેટવર્કે ઉકેલવું પડે.
ત્રણ અલગ મૂલ્યો, અલગ લખાયેલા
એક કન્ફિગરેશન સ્ક્રીન પાછળ ત્રણ કામ છે, અને તેમને ભેગા કરવું એ મોંઘી ભૂલ છે. એક મૂલ્ય છે એન્ડપોઇન્ટ સરનામું, જે નક્કી કરે છે કે પેકેટ ક્યાં જશે. બીજું એ સ્થાનિક ઓળખ છે જે આ peer રજૂ કરે છે, અને ત્રીજું એ ઓળખ છે જે તમે પ્રમાણીકરણ પહેલાં દૂરના છેડેથી અપેક્ષા રાખો છો. તેમને ચેન્જ ટિકિટમાં ત્રણ લીટી તરીકે લખો, કારણ કે તેનાથી ઓછું કંઈક VPN વર્ણવે છે, સંબંધ નહીં.
| Job | Example | What it decides |
|---|---|---|
| Where the packets go | 198.51.100.7 | The endpoint address |
| What this peer claims | gw.branch.internal | The local IKE identity |
| Who should answer | ike.hub.internal | The expected remote identity |
ઉદાહરણની ઓળખોને ડિપ્લોયમેન્ટના ભાગ રૂપે પસંદ અને અધિકૃત કરવી પડે. તે દાવાઓ છે જે પ્રમાણીકરણ ચકાસે છે, એવા ઓળખપત્રો નહીં જે કોઈપણ peer ને વિશ્વસનીય બનાવે, તેથી વિશ્વાસપાત્ર દેખાતી શબ્દમાળા કંઈપણ અધિકૃત કરતી નથી.
પ્રકાર મૂલ્યનો ભાગ છે
strongSwan ઓળખ સંદર્ભ FQDN, ઈમેલ આકારનાં મૂલ્યો, IP સરનામાં અને અન્ય એન્કોડિંગને અલગ પાડે છે, તેથી એન્કોડિંગ અક્ષરો જેટલું જ મહત્વનું છે. બે ઉપકરણો એકસરખું ટેક્સ્ટ જુદા જુદા પ્રકાર હેઠળ સ્વીકારી શકે અને તેમ છતાં એકબીજાને નકારી શકે. પ્રકાર વગર મૂલ્ય નોંધતી નોંધ અડધું કન્ફિગરેશન છે.
વેન્ડરને પૂછો કે ઉપકરણ ખરેખર કયો પ્રકાર મોકલે છે, અને ઇન્ટરફેસ લેબલને બદલે ડીકોડ સામે ખાતરી કરો. અનુમાનિત પ્રકાર એ આગલા ફેરફારની રાહ જોતી અસંગતિ છે.
દરેક બાજુએ બીજી બાજુને સંતોષવી પડે
દરેક બાજુની સ્થાનિક ઓળખે બીજી બાજુની પ્રમાણીકરણ નીતિ પાસ કરવી પડે. આ બંને ઉપકરણોના દરેક ઓળખ બોક્સમાં એક શબ્દમાળા પેસ્ટ કરવા જેવું નથી, જે એ શોર્ટકટ છે જે એવું કન્ફિગરેશન બનાવે છે જેને કોઈ ડિબગ કરી શકતું નથી.
પ્રમાણપત્ર પ્રમાણીકરણ પોતાની જરૂરિયાતો ઉમેરે છે, કારણ કે પ્રમાણપત્રની ઓળખ અને વિશ્વાસની શરતો તમે ટાઇપ કરેલી IKE ઓળખની બાજુમાં બેસે છે. ફક્ત IKE ઓળખ મેળ ખાવાથી પ્રમાણપત્રવાળા peer ને અધિકૃત કરતું નથી.
DNS ક્યાં મહત્વનું છે, અને તમારી આવૃત્તિ શું ફરજિયાત કરે છે
શોધ માટે વપરાતા ગેટવે hostname ને ખરેખર ચાલતું DNS જોઈએ, અને એ જરૂરિયાત એન્ડપોઇન્ટ શોધવાની છે, ટાઇપ કરેલી ઓળખની કોઈ રિવર્સ શોધની નહીં. ટિકિટમાં બંનેને અલગ રાખો, કારણ કે શોધ નિષ્ફળતા અને ઓળખ અસંગતિ ક્લાયન્ટ લોગમાં સરખી રીતે વંચાય છે અને જુદી જુદી જગ્યાએ સુધારાય છે.
પ્રકાર ફરજિયાત કરતું સિન્ટેક્સ કોપી કરતા પહેલાં તમે ખરેખર ચલાવો છો તે ઉત્પાદન અને આવૃત્તિનું પાર્સર વાંચો, કારણ કે જૂની strongSwan આવૃત્તિઓ અલગ વર્તતી હતી અને અન્ય વેન્ડર પોતાની મર્યાદાઓ ઉમેરે છે. જ્યારે તમે બંને છેડા સરખાવો, ત્યારે ચાર વસ્તુઓ સાથે રાખો: અપેક્ષિત ઓળખ, રજૂ કરેલી ઓળખ, પ્રકાર અને પ્રમાણીકરણ ભૂલ. એ સમૂહ અસંગતિને મતને બદલે પુરાવો બનાવે છે.