L2TP, GRE અથવા IPsec: સેશન કયા સ્તરે લઈ જવું જોઈએ?

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

પ્રોટોકોલની યાદીમાંથી નહીં, સેશનથી શરૂ કરો

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

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

દરેક સ્તરને બરાબર એક જ કામ આપો

L2TPv2 તેના બે એન્ડપોઇન્ટ વચ્ચે PPP સેશન વહન કરે છે. PPP લિંક વાટાઘાટ ચલાવે છે અને, જ્યારે તેની વાટાઘાટ થાય ત્યારે, વપરાશકર્તાનું પ્રમાણીકરણ; L2TP કોઈ ક્રિપ્ટોગ્રાફી ઉમેરતું નથી, તેથી માત્ર L2TP ડિમન IPsec સુરક્ષા સંબંધનો કોઈ ભાગ લાગુ કરતું નથી અને ફક્ત એવી લિંકની અંદર જ રહે છે જેમાં તમે પહેલેથી વિશ્વાસ કરો છો.

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

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

કન્ફિગરેશન પહેલાં પેકેટ પાથ લખો

એક પેકેટ લો અને ઉમેરાતું દરેક હેડર, ઉમેરાય તે ક્રમમાં, અને તેને ઉમેરતું ડિવાઇસ કઈ છે તેની યાદી બનાવો. ડાયલ-ઇન વપરાશકર્તા માટે તે સામાન્ય રીતે IPsec ની અંદર L2TP ની અંદર PPP હોય છે; સાઇટ ઓવરલે માટે તે IPsec ની અંદર GRE ની અંદર આંતરિક IP પેકેટ હોય છે. જો બે ડિવાઇસ સમાન હેડર ઉમેરે, તો તમારી પાસે લૂપ અથવા નકલી ટનલ છે, અને કેટલી પણ નીતિ-સંપાદન કરો તો તે સુધારશે નહીં.

એ જ યાદી MTU નક્કી કરે છે, કારણ કે વપરાયોગ્ય આંતરિક કદ એ માપેલ પાથ MTU માંથી તમે હમણાં ગણાવેલા હેડર બાદ કરીને બાકી રહે છે, બીજું કંઈ નહીં. ફોરમ પોસ્ટમાંથી સંખ્યા નકલ ન કરો: બાહ્ય IP, UDP અને ESP ઓવરહેડ, પછી GRE અથવા L2TP, પછી જ્યાં લાગુ પડે ત્યાં PPP ઉમેરો, અને તમે ખરેખર માપેલ પાથ MTU માંથી બાદ કરો. ફક્ત મોટા ટ્રાન્સફર પર દેખાતા લક્ષણો, અથવા સ્થપાયા પછી પહેલા મોટા પ્રતિભાવ પર મરી જતા સેશન, સામાન્ય રીતે એ સરવાળો અંદાજથી કરાયો હોવાને કારણે હોય છે.

દરેક સ્તરને અલગથી, બહારથી અંદર તપાસો

તપાસ ક્રમમાં ચલાવો અને નિષ્ફળ જતી પહેલી તપાસ પર અટકો. દરેક લીટી અલગ પ્રશ્નનો જવાબ આપે છે, તેથી નિષ્ફળતા ટનલ તૂટી છે તેમ કહેવાને બદલે વર્કશીટના એક કૉલમ તરફ ઇશારો કરે છે.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Cisco બોક્સ પર સમાન વસ્તુ ભૂમિકા-આધારિત છે, અને ચોક્કસ સિન્ટેક્સ પ્લેટફોર્મ અને રિલીઝ પર આધાર રાખે છે: IPsec પીઅર માટે show crypto session, GRE કે ટનલ ઇન્ટરફેસ માટે ઇન્ટરફેસ કાઉન્ટર, અને ડાયલ-ઇન ભૂમિકા માટે VPDN કે PPP ચકાસણી. PPP સમાપ્ત કરતો કમાન્ડ સેટ GRE સપોર્ટ વિશે કંઈ સાબિત કરતું નથી, અને કાર્યરત GRE ઇન્ટરફેસ PPP સેવા વિશે કંઈ સાબિત કરતું નથી, તેથી ડાયાગ્રામમાંની ભૂમિકાને બદલે તમે ખરેખર કન્ફિગર કરેલી ભૂમિકા ચકાસો.

દરેક આઉટપુટ તે જે વર્કશીટ લીટીનો છે તેની બાજુમાં નોંધો. ખામી જીવંત હોય ત્યારે લીધેલી નોંધો, પછી યાદમાંથી ફરી દોરેલા ટોપોલોજી કરતાં વધુ મૂલ્યવાન છે.

તોડી પાડવાનો ક્રમ ગોઠવો, પછી ફરી ચકાસો

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

ફરી બનાવ્યા પછી, ચાર સ્વીકૃતિ અવલોકનો એક પછી એક પુનરાવર્તિત કરો: બાહ્ય પહોંચ, સ્થપાયેલું IPsec સંગઠન, જ્યાં ડિઝાઇનમાં સમાવેશ હોય ત્યાં સ્થપાયેલું PPP સેશન, અને વાસ્તવિક ગંતવ્ય સરનામા સુધી આંતરિક ફોરવર્ડિંગ. એક લીલી લાઇટ બાકીના ત્રણ માટે પુરાવો નથી, અને એ જ અંતર એ નિષ્ફળતા છે જે ઉત્પાદનમાં સૌથી લાંબુ ટકે છે — એવી ટનલ જે ચાલુ છે, એન્ક્રિપ્ટેડ છે, અને કંઈ ફોરવર્ડ કરતી નથી કારણ કે આંતરિક રૂટ ક્યારેય ઉમેરાયો નહીં.

ભરેલી વર્કશીટ ડિવાઇસ કન્ફિગરેશનની બાજુમાં રાખો. તમે ન ભરી શકો તે કોઈ પણ કૉલમ એ કોઈ કામ સોંપાયેલું ન હોય તેવું સ્તર છે, અને કામ વગરનું સ્તર સામાન્ય રીતે એવું સ્તર હોય છે જે સ્ટેકમાં ન જ હોવું જોઈએ.