UFW ના before.rules માં VPN NAT ક્યાં જાય છે અને તેને કેવી રીતે ચકાસવું

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

શેલ આદેશ રિસ્ટોર ફાઇલ નથી

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

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

ટુકડાને હાલના ટેબલ વિભાગની અંદર મૂકો

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

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

ઉપરનો પૂલ અને ઇન્ટરફેસ તમારા માટે પ્લેસહોલ્ડર છે; કૉપી કરવા યોગ્ય ભાગ બંધારણ છે. જો ફાઇલમાં પહેલેથી *nat વિભાગ હોય, તો બીજો ખોલવાને બદલે તે જ વિભાગની અંદર નિયમ ઉમેરો, કારણ કે ફોર્મેટ દરેક ટેબલ માટે એક COMMIT ની અપેક્ષા રાખે છે અને એક જ ટેબલ માટે બે વિભાગો એ થવાની રાહ જોતી મરામત છે. ડિસ્ટ્રિબ્યુશનની ચેઇન વ્યાખ્યાઓ અકબંધ રાખો, વેન્ડર તેના પોતાના એકીકરણ માટે ઉમેરેલી કોઈપણ વ્યાખ્યા સહિત. UFW ફ્રેમવર્ક મેન્યુઅલ before, user અને after ફાઇલો તેમજ મેળ ખાતા COMMITની જરૂરિયાતનું દસ્તાવેજીકરણ કરે છે.

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

ઉમેદવારને લાગુ કર્યા વિના ચકાસો

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

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

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

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

ફોરવર્ડિંગ, NAT અને એક્સેસ પોલિસી અલગ રાખો

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

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

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

રીલોડ, નકાર અને VPN ગુમાવવાની ચકાસણી કરો

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

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

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

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