એક Linux ગેટવે પર બે OpenVPN ક્લાયન્ટ: નીતિ વિભાજિત કરો

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

કર્નલ નક્કી કરે છે, ડિમન નહીં

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

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

દરેક ઇન્સ્ટન્સને તેનો પોતાનો સંસાધન સમૂહ આપો

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

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

મેટ્રિક્સ લખો: સ્રોત, કોષ્ટક, ઉપકરણ

દરેક ક્લાયન્ટ જૂથ માટે, સ્રોત સરનામા દ્વારા કોષ્ટક પસંદ કરતો નિયમ ઉમેરો, પછી ઇચ્છિત માર્ગ તે કોષ્ટકમાં મૂકો:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

ટનલનું પોતાનું પરિવહન ક્લાયન્ટ જૂથમાં નથી

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

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

માર્ગ પસંદ કરવો તેની પરવાનગી આપતો નથી

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

સ્રોત અનુવાદ ત્રીજો નિર્ણય છે, અને તે સ્રોત જૂથ અને ખરેખર તેને વહન કરતા ટનલ ઉપકરણ સુધી મર્યાદિત હોવો જોઈએ. postrouting શૃંખલા ખાલી કરવાને બદલે બે ઇન્સ્ટન્સ માટે સમર્પિત શૃંખલા ઉમેરો, કારણ કે અસંબંધિત સેવાઓની ત્યાં નોંધો હોઈ શકે છે અને ખાલી કરવાથી તે શાંતિથી દૂર થઈ જાય છે.

એક ટનલ પડે ત્યારે શું થાય છે

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

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