UFW નિયમો સાથે OpenVPN ગેટવેને એક LAN સુધી મર્યાદિત રાખો

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

પહેલાં ટોપોલોજી અને પરવાનગી લખો

ઉદાહરણ Community OpenVPN સર્વર વાપરે છે જેમાં વપરાશકર્તા જગ્યાનું TUN ઉપકરણ tun0 નામનું છે, ક્લાયન્ટ પૂલ 10.77.0.0/24, અને એક જોડાયેલું સબનેટ 192.168.60.0/24 lan0 પર. IPv4 ફોરવર્ડિંગ પહેલેથી કામ કરે છે અને LAN પાસે પૂલ તરફ પરત રૂટ પહેલેથી છે, તેથી અહીં કંઈ પણ તેમની વચ્ચેના અનુવાદ પર આધારિત નથી.

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

ગાર્ડને UFW ના વહેલા સ્વીકાર પહેલાં મૂકો

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

*filter વિભાગમાં /etc/ufw/before.rules, હાલની ઘોષણાઓની બાજુમાં અને કોઈ પણ નિયમ લાઇન પહેલાં બે ચેઇન ઘોષિત કરો.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

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

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

દરેક ગાર્ડ શું સ્વીકારે અને નકારે તે વાંચો

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

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

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

સબનેટને અધિકૃત કરો અને બાજુના દરવાજા બંધ કરો

પહેલાં રૂટ પરવાનગીનું પૂર્વદર્શન કરો, પછી લાગુ કરવા માટે પૂર્વદર્શન ફ્લેગ દૂર કરો: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. પછી વપરાશકર્તા નિયમોનો ક્રમ સમીક્ષા કરો, કારણ કે વહેલું નકારણ હજી પણ પછીના સ્વીકાર પર જીતે છે. આખા સબનેટની પરવાનગી પણ ખોટો આકાર છે જ્યારે માત્ર એક હોસ્ટનું HTTPS પોર્ટ સુલભ હોવું જોઈએ.

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

પૂર્વદર્શન નહીં, લોડ થયેલી નીતિ ચકાસો

રીલોડનું પૂર્વદર્શન કરો, જાળવણી વિન્ડોમાં લાગુ કરો અને જીવંત નિયમસેટ વાંચો.

sudo ufw --dry-run reload
sudo ufw show raw

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

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

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