સાઇટ-થી-સાઇટ VPN માટે શું નોંધવું: સિલેક્ટર અને વ્યાપ

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

કન્ફિગર કરેલું એ વાટાઘાટ કરેલું નથી

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

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

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

રૂટ-આધારિત ટનલ જુદી રીતે પસંદ કરે છે

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

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

અનુવાદ એ જ કોષ્ટકમાં આવે છે

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

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

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

સેવા જરૂરિયાત જોડો

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

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

રેકોર્ડને પરીક્ષણ યોજનામાં ફેરવો

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

swanctl --list-sas

પાંચ લાઇનનું ઢાંચો સામાન્ય રીતે રેકોર્ડ પ્રામાણિક રાખવા માટે પૂરતું છે. નીચેની આવૃત્તિ કાપ્યા વિના ફેરફાર ટિકિટમાં બેસે છે:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

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