બે ક્લાયન્ટ જૂથો, એક સર્વર: નીતિ ક્યાં લાગુ કરવી

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

સબનેટ લેબલ છે, નિયમ નહીં

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

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

પીઅર ટ્રાફિક વહન કરતો માર્ગ પસંદ કરો

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

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

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

નિયમો લખતા પહેલા મેટ્રિક્સ લખો

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

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

નિયમો ત્યાં મૂકો જ્યાં તેઓ ટકી રહે

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

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

ફાયરવોલના બાકીના ભાગનો માલિક જે પદ્ધતિ છે તેના દ્વારા નિયમોને ટકાઉ બનાવો, અને તેમની બાજુમાં મેટ્રિક્સ નોંધો. નોંધ ન કરેલી નીતિ આગલી ઘટનામાં સ્મૃતિમાંથી ફરી મેળવવામાં આવે છે, સામાન્ય રીતે ઉતાવળમાં હોય તેવી વ્યક્તિ દ્વારા.

બંને બાજુથી સાબિત કરો

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

ટનલ IPv6 વહન કરે તો તેના પર પરીક્ષા પુનરાવર્તિત કરો, અને સામાન્ય એપ્લિકેશન પ્રમાણીકરણ ચાલુ રાખો. સ્રોત પ્રીફિક્સ એકાઉન્ટ નથી, તેથી નેટવર્ક નીતિ પસાર કરવાનો અર્થ એ નથી કે સેવાએ કૉલ કરનાર પર ભરોસો રાખવો જોઈએ.