સાઇટ-થી-સાઇટ વિરુદ્ધ રિમોટ એક્સેસ VPN: બંને શું જોડે છે
એક ગેટવે જોડે છે, બીજું ઉપકરણો જોડે છે. ટ્રાફિક સિલેક્ટરોને રૂટ સાથે સરખાવો, એડ્રેસિંગની યોજના કરો, પછી વાસ્તવિક હોસ્ટમાંથી ફોરવર્ડિંગ અને પોલિસી ચકાસો.
બંને ડિઝાઇનને VPN કહેવાય છે અને તે જુદી જુદી સમસ્યાઓ હલ કરે છે. સાઇટ-થી-સાઇટ ટનલ બે ગેટવે જોડે છે, તેથી તેમની પાછળનું દરેક હોસ્ટ કંઈપણ ઇન્સ્ટોલ કર્યા વિના બીજી બાજુના માન્ય સરનામાં સુધી પહોંચી શકે છે. રિમોટ-એક્સેસ ટનલ વ્યક્તિગત ઉપકરણોને નેટવર્ક સાથે જોડે છે, એક સમયે એક ક્લાયંટ. આ સરખામણી મહત્ત્વની છે કારણ કે મોટાભાગની ડિપ્લોયમેન્ટ ભૂલો એકને કન્ફિગર કરીને બીજાના વર્તનની અપેક્ષા રાખવાથી થાય છે, અને લક્ષણ સામાન્ય રીતે એવી સેવામાં ટાઇમઆઉટ હોય છે જ્યાં ટનલ ખરેખર પહોંચી હતી.
બે ડિઝાઇન, બે સીમાઓ
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
કોઈપણ ડિઝાઇન LAN પ્રસારણ ડોમેનને લંબાવતી નથી. દૂરની બાજુના ઉપકરણો સ્થાનિક શોધ યાદીમાં દેખાતા નથી, અને તે દેખાશે એવી અપેક્ષા રાખવી એ પ્રથમ ધારણા છે જે છોડવી પડે. તમે ઇરાદાપૂર્વક પ્રકાશિત કરો છો તે ખાનગી DNS નામો કોઈપણ શોધ પ્રોટોકોલ કરતાં વધુ અનુમાનક્ષમ છે, અને તે સપ્લાયર બદલાવમાં ટકી રહે છે.
એક સાઇટ પર 10.10.0.0/24 અને બીજી પર 10.20.0.0/24 લો. ગેટવે A ને એવો રૂટ અથવા ટ્રાફિક સિલેક્ટર જોઈએ છે જે 10.20.0.0/24 પ્રીફિક્સને ટનલમાં મોકલે, અને ગેટવે B ને તેની અરીસા પ્રતિકૃતિ જોઈએ છે. પછી બંને બાજુના હોસ્ટ સામાન્ય IP કનેક્ટિવિટી વાપરે છે અને ટનલ છે તે ક્યારેય જાણતા નથી. એ અદ્રશ્યતા જ લક્ષણ છે, અને એટલે જ નિષ્ફળતાઓ ટનલની ભૂલોને બદલે સામાન્ય નેટવર્ક ભૂલો જેવી લાગે છે.
પોલિસી-આધારિત અને રૂટ-આધારિત એક જ ટનલ નથી
પોલિસી-આધારિત IPsec ડિપ્લોયમેન્ટમાં, વાટાઘાટ કરેલા ટ્રાફિક સિલેક્ટરો ચોક્કસપણે નક્કી કરે છે કે કઈ સ્રોત અને લક્ષ્ય જોડી સુરક્ષિત છે. જો એક ગેટવે પાછળ નવું સબનેટ દેખાય અને કોઈ સિલેક્ટર તેને આવરી ન લે, તો ટનલ ચાલુ રહે છે અને નવું સબનેટ ફક્ત વહન થતું નથી. રૂટ-આધારિત ડિઝાઇનમાં ઇન્ટરફેસ ટ્રાફિક મેળવે છે અને રૂટિંગ કોષ્ટક નિર્ણય લે છે, જે પ્રીફિક્સ ઉમેરવાને ટનલની ફરી વાટાઘાટને બદલે રૂટ ફેરફાર બનાવે છે.
StrongSwan બંને દૃશ્યો સીધા દર્શાવે છે, અને તેમને સાથે વાંચવાથી ખબર પડે છે કે તમે ખરેખર કયું મોડેલ ડિપ્લોય કર્યું છે.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'તમને જરૂરી પ્રીફિક્સ છોડી દેતી સિલેક્ટર યાદી કોઈપણ પેકેટ કેપ્ચર વિના નિષ્ફળતા સમજાવે છે, અને ખોટા ઇન્ટરફેસ તરફ ઇશારો કરતો રૂટ પાછા માર્ગે અરીસા-નિષ્ફળતા સમજાવે છે. કંઈપણ ફરી વાટાઘાટ કરતાં પહેલાં બંને વાંચો, કારણ કે કી નવીકરણ એવું સિલેક્ટર ઉમેરશે નહીં જે તમે ક્યારેય કન્ફિગર કર્યું ન હોય.
ટનલ પહેલાં એડ્રેસિંગની યોજના કરો
ઓવરલેપિંગ રેન્જ એ ડિઝાઇન ભૂલ છે જે કન્ફિગરેશનથી સુધારી શકાતી નથી. જો બંને સાઇટ 192.168.1.0/24 વાપરે, તો 192.168.1.50 ની જરૂર હોય તેવા હોસ્ટ પાસે બે ઉમેદવાર હોય છે અને પસંદ કરવાનો કોઈ રસ્તો હોતો નથી. ટનલ પ્રમાણીકરણ કરશે, સુરક્ષા સંકળાયેલતાઓ સ્થપાશે, અને રૂટિંગ નિર્ણય તો ખોટો કે અસ્પષ્ટ જ રહેશે.
ત્રણ પ્રામાણિક વિકલ્પોમાંથી એક પસંદ કરો: એક સાઇટનું ફરી નંબરીકરણ કરો, ગેટવે પર ઓવરલેપિંગ રેન્જનું ભાષાંતર કરો જેથી દરેક બાજુ અલગ પ્રીફિક્સ જુએ, અથવા તે હોસ્ટ માટે સીધા રૂટિંગનો ત્યાગ કરીને સેવા બીજી રીતે પ્રકાશિત કરો. દરેકનો એક ખર્ચ છે, અને બે વર્ષના ક્ષિતિજ પર પ્રથમ સામાન્ય રીતે સૌથી સસ્તું છે. ટનલ અસ્તિત્વમાં આવે તે પહેલાં નિર્ણય લો, કારણ કે પછીનો ફેરફાર જૂનું સરનામું ધરાવતા દરેક ઉપકરણને સ્પર્શે છે.
MTU પ્રશ્ન પણ વહેલો ઉકેલો. ટનલ ઉપયોગી પેલોડ ઘટાડે છે, અને ફ્રેગમેન્ટેશન પર આધાર રાખતી ડિઝાઇન ગેટવે પર MSS સ્થિર કરતી ડિઝાઇન કરતાં જુદી રીતે વર્તે છે.
ફોરવર્ડિંગ અને પોલિસી ટનલની બહાર રહે છે
ગેટવેએ ટનલ ઇન્ટરફેસ અને LAN ઇન્ટરફેસ વચ્ચે પેકેટ ફોરવર્ડ કરવા તૈયાર હોવું જોઈએ, અને બંને દિશાને સેવાને મંજૂરી આપતી પોલિસી જોઈએ છે. Linux માં આ બે અલગ સેટિંગ છે, ઉપરાંત ફાયરવોલ નિયમો જે નક્કી કરે છે કે ફોરવર્ડ થયેલો પ્રવાહ બિલકુલ માન્ય છે કે નહીં.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTપ્રાપ્ત કરનારું હોસ્ટ ત્રીજું સ્તર ઉમેરે છે: તેનું પોતાનું ફાયરવોલ હજી પણ દૂરના સબનેટમાંથી ક્લાયંટ સ્વીકારવો પડે છે. ફક્ત પોતાનું સ્થાનિક /24 મંજૂરી આપતું ફાઇલ સર્વર 10.20.0.7 તરફથી ફોરવર્ડ થયેલો ટ્રાફિક નકારશે, ટનલ કેટલી સ્વસ્થ લાગે તે ધ્યાનમાં લીધા વિના, અને એ નકારને રૂટિંગ નિષ્ફળતા તરીકે વાંચવું સહેલું છે.
ગેટવેથી નહીં, હોસ્ટથી પરીક્ષણ કરો
ગેટવે પોતે મોકલેલો ping ફોરવર્ડ થયેલા વપરાશકર્તા ટ્રાફિક કરતાં જુદું સ્રોત સરનામું અને જુદી પોલિસી અનુસરી શકે છે. તેથી તે નબળું પરીક્ષણ બને છે અને ક્યારેક ભ્રામક પણ: એપ્લિકેશન નિષ્ફળ જાય ત્યારે તે સફળ થાય છે, અથવા એપ્લિકેશન કામ કરે ત્યારે તે નિષ્ફળ જાય છે.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullવાસ્તવિક હોસ્ટ, વાસ્તવિક સ્રોત સરનામું અને એપ્લિકેશન જે વાસ્તવિક પ્રોટોકોલ વાપરે છે તે વાપરો. પછી પરત માર્ગ અલગથી વાંચો, કારણ કે પરત રૂટ વિના કામ કરતી આગળની દિશા એવો ટાઇમઆઉટ ઉત્પન્ન કરે છે જે અવરોધિત સેવા જેવો જ દેખાય છે.
તમે જે પ્રશ્નનો જવાબ આપો છો તે મુજબ ડિઝાઇન પસંદ કરો: તમે નેટવર્ક જોડો છો કે ઉપકરણો સ્વીકારો છો? બાકીનું બધું, કયો સપ્લાયર કન્ફિગર કરવો તે પણ, એ જવાબમાંથી આવે છે.