હબ પર WireGuard પીઅર જૂથો: સ્રોતની માલિકી અને નીતિ

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

બે કામ, અલગ રાખેલા

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

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

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

દરેક પીઅરને ફક્ત તેનું પોતાનું સરનામું આપો

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

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

જૂથોને અલગ પાડતી ફોરવર્ડ નીતિ લખો

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

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

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

ક્રમ નક્કી કરે છે કે નીતિ લાગુ પડે છે કે નહીં

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

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

ફાઇલોની સંખ્યા નહીં, મેટ્રિક્સની કસોટી કરો

અપેક્ષિત પરિણામોનું નાનું મેટ્રિક્સ બનાવો અને દરેક કોષ તપાસો. જૂથ A થી જૂથ A સુધી કામ કરવું જોઈએ, જૂથ B થી જૂથ B સુધી કામ કરવું જોઈએ, અને A થી B સુધી નહીં, બંને દિશામાં અને જો તમે સમર્થન આપો તો બંને સરનામા કુટુંબો માટે.

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

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

હબ પરના યજમાન સેવાઓ અને તેની પાછળના LAN સુધીની ઍક્સેસ અલગ નીતિ સાથેના અલગ માર્ગો છે. નોંધો કે મેટ્રિક્સ તેમાંથી કયાને આવરે છે, કારણ કે ફક્ત પીઅર-થી-પીઅર ટ્રાફિક તપાસતી કસોટી તેમાંથી કોઈના વિશે કંઈ કહેતી નથી.