શા માટે nftables OpenVPN ના ક્લાયન્ટ વચ્ચેનો ટ્રાફિક જોઈ શકતું નથી
પીઅર વચ્ચેનો ટ્રાફિક VPN પ્રોસેસની અંદર પહોંચાડવામાં આવે છે, તેથી ફોરવર્ડ કાઉન્ટર ક્યારેય ખસતા નથી. તેને ગણવા માટે કર્નલ માર્ગ અને પ્રોસેસ માર્ગ વચ્ચે પસંદગી કરવી પડે છે.
એક જ સર્વર પરના બે ક્લાયન્ટ ફાઇલોની આપલે કરે છે, ટ્રાન્સફર સફળ થાય છે, અને ટનલ તરફ દોરેલો દરેક ફોરવર્ડ નિયમ શૂન્ય પેકેટ જણાવે છે. નિયમો તૂટ્યા નથી અને ચેઇન ખોટી જગ્યાએ નથી. પીઅર-ટુ-પીઅર ફોરવર્ડિંગ ચાલુ હોય ત્યારે પેકેટ સર્વર પ્રોસેસની અંદર જ પહોંચાડવામાં આવે છે અને હોસ્ટ સ્ટેક ક્યારેય રાઉટર બનતો નથી, તેથી કર્નલ ફાયરવોલ પાસે ગણવા જેવું કંઈ રહેતું નથી. આ વિભાજન સમજવું એ નક્કી કરે છે કે તમે શોર્ટકટ રાખશો કે કર્નલ દ્વારા માર્ગ ફરી બનાવશો.
સર્વરમાંથી એક પેકેટને અનુસરો
રાઉટેડ ટનલમાં ડિમન દરેક ક્લાયન્ટનું ડિક્રિપ્ટ થયેલું પેકેટ ટનલ ઉપકરણને આપે છે. ત્યાંથી હોસ્ટ તેને રાઉટ કરે છે, ફોરવર્ડ હૂક ચાલે છે, અને ટનલ ઉપકરણ સાથે મેળ ખાતો નિયમ ટ્રાફિક ગણી શકે છે અથવા ફેંકી શકે છે. મોટા ભાગના ફાયરવોલ ઉદાહરણો આ જ માર્ગ ધારે છે.
| Forwarding path | Who decides | What the host firewall sees |
|---|---|---|
| Kernel routing between clients | Host routing table and forward rules | Every inner packet, with interface names |
| Peer forwarding inside the server process | The VPN daemon's own peer table | Only the outer encrypted transport |
શોર્ટકટ હોસ્ટને વચ્ચેથી દૂર કરે છે. એક સેશનનું ડિક્રિપ્ટ થયેલું પેકેટ ડિમનની અંદર બીજા સેશનને આપવામાં આવે છે, અને અંદરનું પેકેટ ક્યારેય ટનલ ઉપકરણ પર બહાર જતું નથી કે હોસ્ટ દ્વારા રાઉટ થતું નથી. એન્કેપ્સ્યુલેટેડ ટ્રાફિક હજી ભૌતિક ઇન્ટરફેસ પાર કરે છે, તેથી બહારનું કેપ્ચર વ્યસ્ત દેખાય છે જ્યારે અંદરના નિયમો શાંત રહે છે. ટનલ ઉપકરણ પર લીધેલું કેપ્ચર બિલકુલ કંઈ દેખાડતું નથી, જે ત્યાં ટ્રાન્સફર જોવાની અપેક્ષા રાખનારને આશ્ચર્યમાં મૂકે છે. આ અસમપ્રમાણતા ડિમનની બહારથી શોર્ટકટ ઓળખવાનો સૌથી ઝડપી રસ્તો છે.
કયો માર્ગ ચાલ્યો તે નક્કી કરતી કાઉન્ટર કસોટી
જે નિયમ લાગુ પડવો જોઈએ તેમાં કાઉન્ટર જોડો, જે બે ક્લાયન્ટ વચ્ચે તે નિયમે અવરોધવું જોઈએ તેમની વચ્ચે ટ્રાન્સફર ચલાવો, અને પછી કાઉન્ટર વાંચો.
sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forwardજો ટ્રાન્સફર સફળ થાય અને કાઉન્ટર શૂન્ય પર જ રહે, તો કર્નલે તે પેકેટ ક્યારેય સંભાળ્યા નથી, અને કોઈ પણ નિયમ સંપાદન તેને બદલશે નહીં. એ જ કસોટી સર્વર પરની કોઈ સેવા સામે પુનરાવર્તિત કરો, કારણ કે તે ફ્લો હોસ્ટ સ્ટેક પાર કરે છે અને તેનું કાઉન્ટર ખસે છે. બે પરિણામોની તુલના જ જવાબ આપે છે.
બે વિગતો ખોટું વાંચન અટકાવે છે. ચેઇન લેબલમાં લખેલું ઇન્ટરફેસ નામ પોતાના આધારે કંઈ ફિલ્ટર કરતું નથી, કારણ કે મેળ નિયમોની અંદરના ઇન્ટરફેસ ક્ષેત્રો પર થાય છે. અને બ્રિજ કરેલી સ્તર-2 રચના ફરી અલગ રીતે વર્તે છે: ત્યાં ક્લાયન્ટ એક બ્રોડકાસ્ટ ડોમેન વહેંચે છે, તેથી પીઅર શોધ અપેક્ષિત છે, રાઉટિંગ ખામી નહીં.
સ્વિચ એક્સેસ લિસ્ટ નથી
આ તે ભાગ છે જે એક બપોર ખાઈ જાય છે. પીઅર ફોરવર્ડિંગ એ એક જ ચાલુ-બંધ સેટિંગ છે, અને જ્યાં સુધી તે ચાલુ છે ત્યાં સુધી ડિમન જ એકમાત્ર ફોરવર્ડિંગ પોઇન્ટ છે. હોસ્ટ ફાયરવોલ કહી શકતું નથી કે કોણ કોના સુધી પહોંચી શકે, અને પ્રતિ-ક્લાયન્ટ ફાઇલો સ્વિચને નીતિ મેટ્રિક્સમાં ફેરવતી નથી.
જો તમને પ્રતિ-પીઅર નિયમોની જરૂર હોય, તો પસંદગી શોર્ટકટ છોડવા અને નિયંત્રણ તરીકે હોસ્ટ ફાયરવોલ છોડવા વચ્ચે છે. તેને બંધ કરવાથી કર્નલ ફોરવર્ડિંગ પાછું આવે છે, જે માટે સર્વર પર IP ફોરવર્ડિંગ ચાલુ અને તમે ઇચ્છો તે ફ્લો માટે સ્પષ્ટ નિયમો જરૂરી છે. તેને ચાલુ રાખવાનો અર્થ છે કે નીતિ ડિમનના રૂપરેખાંકનમાં રહે છે, જે વ્યવહારમાં બધા પીઅર અથવા કોઈ પીઅર નહીં.
પોતાના સરનામા પૂલ અને પોર્ટ સાથેના અલગ સર્વર પ્રોસેસ એ કામ ચાલે તેવો મધ્યમ માર્ગ છે. દરેક પ્રોસેસ બરાબર એક એક્સેસ નિર્ણય ધરાવે છે, તેથી બે જૂથ નીતિ મેટ્રિક્સ વિના અલગ નિયમો રાખી શકે છે. હોસ્ટ ઇચ્છિત હોય ત્યારે પૂલ વચ્ચે રાઉટ કરી શકે છે, અને પછી ફાયરવોલ તે ફ્લો જુએ છે કારણ કે તે હોસ્ટ પાર કરે છે. કિંમત વધારાના પોર્ટ, વધારાના પ્રમાણપત્રો અને પ્રતિ જૂથ એક પ્રોફાઇલ છે.
ફોરવર્ડિંગ પોઇન્ટ પસંદ કરવો
કર્નલ ફોરવર્ડિંગ પસંદ કરો જ્યારે ફાયરવોલ નીતિ એન્જિન હોય, જ્યારે તમને પ્રતિ ફ્લો લોગિંગની જરૂર હોય, અથવા જ્યારે હિસાબ મહત્વનો હોય. કિંમત હોસ્ટ સ્ટેક દ્વારા થ્રુપુટ અને જાળવવા માટે વધુ નિયમો છે. ફાયદો એ છે કે દરેક હાલનું સાધન, કાઉન્ટરથી ફ્લો એક્સપોર્ટર સુધી, ટ્રાફિકનું ફરી વર્ણન કરે છે. નાના સર્વર પર આ કિંમત અદૃશ્ય છે; વ્યસ્ત રિલે પર નથી.
પ્રોસેસની અંદરનું ફોરવર્ડિંગ પસંદ કરો જ્યારે પીઅર ટ્રાફિક કાં તો સંપૂર્ણ મંજૂર હોય અથવા સંપૂર્ણ નિષેધ હોય અને સર્વર તે માટે માપવામાં આવ્યું હોય. કિંમત એ છે કે કાઉન્ટર, ક્યૂ શિસ્ત અને કનેક્શન ટ્રેકિંગ હવે અંદરના ફ્લોનું વર્ણન કરતા નથી; આ ફક્ત ત્યારે સ્વીકાર્ય છે જ્યારે પછી કોઈ તેમના પર આધાર ન રાખે.
તમે જે પણ પસંદ કરો, તેને ફાયરવોલ નિયમોની બાજુમાં લખો. જે નિયમ સમૂહ પીઅર ટ્રાફિકની મંજૂરી આપતો દેખાય છે જ્યારે ડિમન કોઈપણ રીતે નિર્ણય લે છે, તે આગલી વ્યક્તિને ભ્રમિત કરે છે જે નિષ્ફળ ટ્રાન્સફર ડિબગ કરશે. ફક્ત નિયમો વાંચનાર કોઈ પણ ધારશે કે કર્નલ જ દરવાજો છે.
નિયમો બદલતા પહેલા શું ચકાસવું
સર્વરે ખરેખર લોડ કરેલું રૂપરેખાંકન વાંચો, તમને યાદ હોય તે સંપાદિત ફાઇલ નહીં, અને પીઅર વિકલ્પ હાજર છે કે નહીં તેની ખાતરી કરો. જો તમે તેને બદલ્યો હોય, તો ખાતરી કરો કે સેવા ફરી લોડ થઈ છે, ફક્ત ડિસ્ક પર ફાઇલ ફરી લખી નથી.
પછી ક્લાયન્ટથી સર્વર તરફના ફ્લો સાથે કસોટી પુનરાવર્તિત કરો જેથી સાબિત થાય કે નિયમ બિલકુલ મેળ ખાય છે, અને પુશ કરેલા માર્ગો તપાસો, કારણ કે ખૂટતો માર્ગ ક્લાયન્ટની બાજુથી બરાબર ફાયરવોલ બ્લોક જેવો દેખાય છે. નિયમોનો ક્રમ ત્યારે જ બદલો જ્યારે તમે જાણો કે કયો ફોરવર્ડિંગ પોઇન્ટ નિર્ણયનો માલિક છે.