VPN ના સમર્પિત સરનામા પર ખરેખર કોણ જવાબ આપે છે?

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

સરનામા પાછળનો પેકેટ માર્ગ

સહભાગી પોતાને મળેલા સરનામા પર IKE મોકલે છે, UDP 500 પર અથવા NAT ટ્રાવર્સલ ચાલુ હોય ત્યારે UDP 4500 પર. માર્ગમાં તે સરનામું ધરાવતું જે પણ ઉપકરણ હોય, તે ડેટાગ્રામ સ્થાનિક રીતે સ્વીકારીને જવાબ આપે છે, અથવા તેને બીજે મોકલી આપે છે. આ જ બે શક્યતાઓ છે, અને આ લેખમાંનું બાકીનું બધું તેમાંથી કઈ સાચી છે તેના પરથી નીકળે છે.

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

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

મોડેલ A: ગેટવે સરનામાનો માલિક છે

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

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

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

સાંભળતું સોકેટ જ પુરાવો છે. જો સરનામા સાથે કંઈ બંધાયેલું ન હોય, તો રૂટિંગ ટેબલ શું કહે તે ગમે તે હોય, ગેટવે સમાપક નથી, અને પેકેટ કેપ્ચર બતાવશે કે ડેટાગ્રામ આવે છે પણ તેમને જવાબ આપનાર કોઈ નથી.

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

મોડેલ B: અપસ્ટ્રીમ ઉપકરણ તેનું ભાષાંતર કરે છે

બીજા મોડેલમાં અપસ્ટ્રીમ ફાયરવોલ સમર્પિત સરનામું ધરાવે છે અને ટ્રાફિકને બીજા VPN ગેટવે તરફ મોકલે છે. તે પરત માર્ગ સાથેનું ગંતવ્ય ભાષાંતર છે, અને જ્યાં સુધી તેને એ રીતે દસ્તાવેજીકૃત કરાય ત્યાં સુધી તે સંપૂર્ણ માન્ય ડિઝાઇન છે.

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

બંને સરનામાં નોંધો: જેની સાથે સહભાગીઓ સંપર્ક કરે છે અને જે ગેટવે ખરેખર જુએ છે. પછી પરિવહન અને પરત માર્ગ નોંધો, કારણ કે UDP 500 માટે કામ કરતું પણ કેપ્સ્યુલેટેડ ESP માટે ન કામ કરતું ભાષાંતર જોડાશે અને પછી ટ્રાફિક વહન કરવામાં નિષ્ફળ જશે, જે પછી ડિબગ કરવા માટે મૂંઝવણભરી નિષ્ફળતા છે.

ઓળખ બહારનું સરનામું નથી

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

પ્રમાણિત ઓળખ ફરી અલગ છે. IKEv2 ઓળખ પેલોડ અને પ્રમાણીકરણ વિનિમય વહન કરે છે જે બહારના પેકેટ સરનામા સાથે મેળ ખાવાની જરૂર નથી, અને એટલે જ ભાષાંતરિત ડિઝાઇન હજી પણ યોગ્ય રીતે પ્રમાણીકરણ કરી શકે છે.

એ સ્વતંત્રતા ઉપયોગી છે અને સાથે સાથે ફાંદો પણ છે. એક સામાન્ય શ્રોતા તરફ ઉકેલાતાં બે DNS નામ જુદા VPN બેકએન્ડ પસંદ કરતાં નથી, અને એક ઓળખનું નામ આપતું પ્રમાણપત્ર બીજી ઓળખની અપેક્ષા રાખતા સહભાગીને સંતોષશે નહીં. ફક્ત સરનામું જ તે નક્કી કરે છે એમ ધારવા પહેલાં સહભાગી શું ચકાસે છે તેની ખાતરી કરો.

એક જોડાણ જોઈને ડિઝાઇન સ્વીકારો

નવું અધિકૃત જોડાણ ખરેખર ક્યાં પહોંચાડાય છે, કઈ ઓળખ જવાબ આપે છે અને પછી કયો ખાનગી પ્રવાહ મંજૂર થાય છે તે તપાસો. ત્રણ અવલોકનો, ત્રણ અલગ સ્તરો, અને સરનામાની સફળ જાહેર શોધ તેમાંનું એક પણ ચકાસતી નથી.

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

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