રૂટ-આધારિત vs નીતિ-આધારિત સાઇટ-ટુ-સાઇટ VPN: શું અલગ પડે છે
નીતિ-આધારિત IPsec સિલેક્ટરથી ટ્રાફિક પસંદ કરે છે; રૂટ-આધારિત તેને ટનલ ઇન્ટરફેસ દ્વારા મોકલે છે. બંનેને હજી ફાયરવોલ નિયમો અને પરત રૂટની જરૂર છે.
બંને ડિઝાઇન સમાન ટ્રાફિકને સમાન IPsec મશીનરીથી સુરક્ષિત કરે છે, અને તેમાં એ અલગ પડે છે કે કયો પેકેટ ટનલમાં પ્રવેશે તે કોણ નક્કી કરે છે. નીતિ-આધારિત કનેક્શનમાં વાટાઘાટ કરેલા ટ્રાફિક સિલેક્ટર આ કામ કરે છે; રૂટ-આધારિતમાં ટનલ ઇન્ટરફેસ તરફ ઇશારો કરતો રૂટ આ કામ કરે છે. બંનેને મિશ્ર કરવાથી પરિચિત સપોર્ટ થ્રેડ બને છે જેમાં ટનલ સ્થાપિત હોવાનું જણાવે છે જ્યારે એપ્લિકેશન ક્યાંય પહોંચતી નથી. આ ભેદ સૌથી વધુ ત્યારે મહત્ત્વનું છે જ્યારે તમે નેટવર્ક ઉમેરો છો, રૂટિંગ પ્રોટોકોલ ચલાવો છો અથવા ખોટા આઉટલેટમાંથી ચૂપચાપ નીકળતા માર્ગને ડિબગ કરો છો.
ટનલમાં શું પ્રવેશે તે નક્કી કરવાની બે રીતો
નીતિ-આધારિત VPN સ્રોત અને લક્ષ્ય પ્રીફિક્સ સાથે મેળ ખાતી સુરક્ષા નીતિ બનાવે છે, પછી જે બંધ બેસે તેને એન્ક્રિપ્ટ કરે છે. પીઅરને સુસંગત સિલેક્ટરની વાટાઘાટ કરવી પડે છે, તેથી અસરકારક વ્યાપ બંને બાજુએ પ્રસ્તાવિત વસ્તુનો છેદ બની જાય છે. તે છેદની બહાર કંઈપણ સુરક્ષિત નથી, રૂટિંગ ટેબલ શું કહે તે ગમે તે હોય.
રૂટ-આધારિત VPN ટનલનું પ્રતિનિધિત્વ કરતું ઇન્ટરફેસ બનાવે છે અને રૂટિંગ ટેબલને તેમાં ટ્રાફિક મોકલવા દે છે. IKE ડીમન હજી પણ સ્થિતિ અને દરેક ઇન્ટરફેસની નીતિ સ્થાપિત કરે છે, અને આ એ વિગત છે જે લોકો ત્યારે છોડી દે છે જ્યારે તેઓ નક્કી કરે છે કે રૂટે એન્ક્રિપ્શનનું સ્થાન લીધું છે. બંને ડિઝાઇન IPsec સાથે એન્ક્રિપ્ટ કરે છે; ફક્ત પસંદગીની પદ્ધતિ અલગ છે.
નીચેની તુલના સ્કોરકાર્ડ તરીકે નહીં પણ નિષ્ફળતાના હસ્તાક્ષરોના સમૂહ તરીકે વાંચો, કારણ કે કોઈ પણ સ્તંભ પોતાની રીતે જીતતો નથી.
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
નીતિ-આધારિત: સિલેક્ટર એ કરાર છે
સિલેક્ટરની વાટાઘાટ થાય છે, ફક્ત ગોઠવાય છે એમ નહીં. એક બાજુ 10.10.0.0/16 અને બીજી બાજુ 10.10.1.0/24 પ્રસ્તાવ કરો, પછી સંગઠન વાટાઘાટ જેના પર સ્થિર થઈ તેને આવરી લેશે જ્યારે અન્ય દરેક યજમાન તેની બહાર રહેશે.
કન્ફિગરેશન ફાઇલને બદલે સ્થાપિત સ્થિતિ વાંચો. Linux પીઅર પર કર્નલના પોતાના ટેબલ જ ખરી સત્ય છે, અને તે દર્શાવે છે કે વાટાઘાટમાંથી શું બચ્યું. જે નીતિ યોગ્ય પ્રીફિક્સનું નામ આપે છે પણ મેળ ખાતી સ્થિતિ ધરાવતી નથી તેનો અર્થ એ છે કે સંગઠન ક્યારેય ઊભું ન થયું. ખોટા પ્રીફિક્સ માટેની નીતિ સાથે જોડાયેલી સ્થિતિ વિરુદ્ધ સમસ્યા છે, અને તે એવી ટનલ બનાવે છે જે સ્વસ્થ દેખાય છે જ્યારે એક સબનેટ ક્યાંય પહોંચી શકતું નથી.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasતમે જે પ્રીફિક્સને સુરક્ષિત કરો છો એમ માનો છો તેની સાથે બંને આઉટપુટની તુલના કરો. તે એક જ તુલના કાર્યરત ટનલ અને અપ્રાપ્ય સર્વરની મોટાભાગની ફરિયાદો ઉકેલે છે. તે એ પણ દર્શાવે છે કે કયા પીઅરને બદલવું છે, કારણ કે અસંગતિ સામાન્ય રીતે એક જ દિશામાં દેખાય છે.
રૂટ-આધારિત: ઇન્ટરફેસ એ કરાર છે
XFRM ઇન્ટરફેસ ટનલને નામ અને ઓળખ આપે છે, અને ટ્રાફિક તે સુધી પહોંચે છે કારણ કે રૂટિંગ ટેબલ એમ કહે છે. પછી ઘણા દૂરસ્થ પ્રીફિક્સ સિલેક્ટરની સમસ્યાને બદલે રૂટિંગની સમસ્યા બની જાય છે, અને રૂટિંગ પ્રોટોકોલ તેમની જાહેરાત કરી શકે છે. એ જ ખરો લાભ છે, એન્ક્રિપ્શન નહીં.
ઇન્ટરફેસ નીતિની જરૂરિયાત દૂર કરતું નથી. ડીમન ઇન્ટરફેસની ઓળખ સાથે બંધાયેલા નિયમો દરેક ઇન્ટરફેસ માટે સ્થાપિત કરે છે, તેથી ખોટા ઇન્ટરફેસ પર આવતું પેકેટ હજી પણ નિષ્ફળ જાય છે. પીઅર જે સ્વીકારશે નહીં તેવું સ્રોત સરનામું પણ નિષ્ફળ જાય છે, પૂર્ણ રૂટ હોવા છતાં. રૂટ-આધારિત એટલે કે રૂટ પ્રવેશ નક્કી કરે છે, નીતિ અદૃશ્ય થઈ છે એમ નહીં.
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10રૂટ સ્થાપિત થયા પછી ઇન્ટરફેસ કાઉન્ટર પર નજર રાખો. રૂટ અસ્તિત્વમાં છે પણ કાઉન્ટર શૂન્ય રહે છે તેનો અર્થ એ છે કે ટનલમાં કંઈ મેળ ખાતું નથી, જે સામાન્ય રીતે ખૂટતી રૂટને બદલે ખૂટતી સ્થિતિ તરફ ઇશારો કરે છે.
બે ડિઝાઇન ખરેખર ક્યાં અલગ પડે છે
નેટવર્ક ઉમેરવો એ કઈ મોડેલ તમને અનુકૂળ છે તેની સૌથી સ્વચ્છ કસોટી છે. રૂટ-આધારિત ડિઝાઇન એક રૂટ ઉમેરે છે અને વધુમાં વધુ એક વાર સિલેક્ટર પહોળો કરે છે, જ્યારે નીતિ-આધારિત ડિઝાઇન બંને પીઅર પર પ્રીફિક્સ જોડીઓ સંપાદિત કરે છે અને ફરી વાટાઘાટ કરે છે. બે સ્થિર સબનેટ તે સંપાદનને તુચ્છ બનાવે છે, અને વીસ તેને પ્રોજેક્ટ બનાવે છે.
કોઈ પણ મોડેલ ફાયરવોલનું સ્થાન લેતું નથી, અને તુલનાઓ સામાન્ય રીતે આ બિંદુ પહેલાં રોકાય છે. પહોળો સિલેક્ટર અથવા પહોળો રૂટ નક્કી કરે છે કે શું એન્ક્રિપ્ટ થાય છે, શું મંજૂર છે તે નહીં.
MTUનું વર્તન પણ વ્યવહારમાં અલગ છે. એન્કેપ્સ્યુલેશન ઉપયોગી પેલોડ ઘટાડે છે, અને રૂટ-આધારિત ઇન્ટરફેસ પોતાનું MTU ધરાવે છે, તેથી બંને ગેટવે પર MSS ક્લેમ્પ કરવાથી બ્લેક-હોલ લક્ષણ ટળે છે જ્યાં નાના જવાબો આવે છે અને મોટા અદૃશ્ય થાય છે. નીતિ-આધારિત ટનલ બીજી બાજુથી એ જ દીવાલ સાથે અથડાય છે, કારણ કે સિલેક્ટર પેકેટના કદ વિશે કંઈ કહેતું નથી. પીઅરને દોષ આપવાને બદલે ક્લેમ્પ જાણી જોઈને સેટ કરો.
પરત માર્ગ ગુમાવ્યા વિના સ્થળાંતર
કંઈપણ બદલતા પહેલાં હાલની પ્રીફિક્સ જોડીઓ નોંધો, પછી એક એપ્લિકેશન માર્ગ ખસેડો અને તેને શરૂઆતથી અંત સુધી જુઓ. સ્થપાયેલી ટનલ એ ફોરવર્ડ કરતી ટનલ નથી, અને તફાવત જવાબની દિશામાં દેખાય છે.
જ્યારે પીઅર જોડાય છે પણ LAN યજમાનો જોડાઈ શકતા નથી, ત્યારે પરત રૂટ અને દૂરના યજમાન વાપરશે તે સ્રોત સરનામું તપાસો. બે ઇન્ટરફેસ ધરાવતું યજમાન ખોટા ઇન્ટરફેસથી જવાબ આપી શકે છે, અને કોઈ સિલેક્ટર ફેરફાર તેને સુધારતો નથી. અલ્ગોરિધમ સંપાદિત કરતા પહેલાં બંને છેડે ટ્રાફિક કેપ્ચર કરો.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsકામ કરતી વખતે ટનલ પર આધારિત ન હોય તેવો મેનેજમેન્ટ માર્ગ રાખો. જ્યારે ગેટવેની પોતાની પહોંચ તમે ડિબગ કરી રહ્યા છો તે કનેક્શન પર ન હોય ત્યારે પાછું ફેરવવું સહેલું છે.