UFW કિલ સ્વિચ તમારા VPN ને અવરોધે છે? પીઅરને મંજૂરી આપો
તમારો આઉટગોઇંગ નકારનો નિયમ ટનલનું હેન્ડશેક પાડી નાખે છે. ufw enable પહેલાં ઉમેરાયેલો એક પીઅર અપવાદ જ નીતિને કિલ સ્વિચ બનાવે છે.
તમે ચેકલિસ્ટ અનુસર્યું: આઉટગોઇંગ નકારો, ટનલને મંજૂરી આપો, ufw સક્રિય કરો. પછી ક્લાયન્ટ હેન્ડશેક પર રાહ જુએ છે અને ક્યારેય જોડાતું નથી, અથવા જોડાય છે અને કોઈ પૃષ્ઠ લોડ થતું નથી. બંને નિષ્ફળતાઓ એક જ ખાલી જગ્યામાંથી આવે છે. ટનલને અસ્તિત્વમાં રાખતો નિયમ ખૂટે છે, કારણ કે ટનલ એ ઇન્ટરફેસ નથી જેમાંથી તમારા પેકેટ બહાર જાય.
શા માટે tun0 પરની મંજૂરી શરૂઆતમાં કંઈપણ સાથે મેળ ખાતી નથી
સેશન અસ્તિત્વમાં આવ્યા પછી ક્લાયન્ટ tun0 બનાવે છે. તે સેશન બનાવતા ડેટાગ્રામ સામાન્ય UDP પેકેટ છે જે પોર્ટ 1194 પર પ્રદાતાને સંબોધાયેલા હોય છે, અને તે ભૌતિક સ્રોત સરનામા સાથે wlan0 અથવા eth0 દ્વારા બહાર જાય છે. allow out on tun0 ફક્ત એ ટ્રાફિક સાથે મેળ ખાય છે જેનું આઉટગોઇંગ ઇન્ટરફેસ tun0 છે, તેથી હેન્ડશેક દરમિયાન તે કંઈપણ સાથે મેળ ખાતું નથી.
તેની ઉપર default deny outgoing મૂકો અને બહારના પેકેટ ઇન્ટરફેસ દેખાય તે પહેલાં જ કાઢી નાખવામાં આવે છે. ક્લાયન્ટ ફરી પ્રયાસ કરે છે, સમય પૂરો થાય છે અને TLS અથવા હેન્ડશેક નિષ્ફળતાની જાણ કરે છે, જે લોકોને સર્ટિફિકેટ અને MTU માં શોધખોળ કરવા મોકલે છે જ્યારે ફાયરવોલ ચૂપચાપ કનેક્શન ખાઈ જાય છે. તમારા ટ્રાફિકને રોકવાનો હેતુ ધરાવતો નિયમ તે ટ્રાફિકને રોકાતો અટકાવે છે.
પ્રતિક્રિયાત્મક સુધારો લીકને કાયમી બનાવે છે. sudo ufw allow out on wlan0, અથવા ડિફોલ્ટને પાછું મંજૂરી પર ફેરવવું, ટનલ ઉપર લાવે છે અને મશીનને કિલ સ્વિચ વિના છોડી દે છે: આગલી વખતે ટનલ પડે ત્યારે બધું ભૌતિક એડાપ્ટર પર ફરી શરૂ થાય છે. મેં બરાબર તે જ બે ફેરફારોમાં એક બપોર ગુમાવી, તે પહેલાં કે મને સમજાયું કે હું ખરેખર કયું પેકેટ ફિલ્ટર કરી રહ્યો છું.
બે પેકેટ સમૂહોને શું જોઈએ
તમારો ટ્રાફિક બે વાર, બે આકારમાં ફાયરવોલ પાર કરે છે. અંદરનું પેકેટ ટનલ સરનામેથી tun0 દ્વારા બહાર જાય છે. બહારનું પેકેટ ભૌતિક સરનામેથી પીઅર સુધી જાય છે, અને તે જ તાર પર દેખાતી એકમાત્ર વસ્તુ છે. દરેક આકાર માટે એક નિયમ:
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'
સરનામું અને પોર્ટ તમારી પોતાની પ્રોફાઇલના સાથે બદલો. WireGuard પીઅર સામાન્ય રીતે 51820/udp પર જવાબ આપે છે; TCP 443 પર ચાલતી OpenVPN પ્રોફાઇલને તેના બદલે તે પોર્ટની જરૂર પડે છે. વિગતો અલગ છે, આકાર નહીં: બંને નિયમ સાંકડા છે, અને સાથે મળીને તેઓ એ જ ગંતવ્યો નક્કી કરે છે જ્યાં ટનલ બંધ હોય ત્યારે મશીન પહોંચી શકે.
ક્રમ બીજી દંતકથા છે. કાચા iptables સાથે તમે સાંકળ ઉપરથી નીચે વાંચો છો અને વિચારો છો કે કયો નિયમ જીતે છે. ufw એ તમે ટાઇપ કરેલી સૂચિનું પાતળું આવરણ નથી; તે તમારા નિયમોને તેની પોતાની સાંકળોમાં કમ્પાઇલ કરે છે અને દાખલ કરવાના બિંદુઓ પસંદ કરે છે. ufw status તેમને ufw ના ક્રમમાં છાપે છે, તમારા ક્રમમાં નહીં. જ્યારે કોઈ નિયમ અવગણાયેલો લાગે, ત્યારે સરખાવો ufw show added ને કમ્પાઇલ થયેલા સમૂહ સાથે iptables -S | grep ufw કંઈપણ ફરીથી લખતા પહેલાં.
અપવાદ એક સરનામા પહોળો રહેવો જોઈએ
પીઅર નિયમ ત્યારે જ સાચો છે જ્યારે તે એ સરનામું નામ આપે છે જે ક્લાયન્ટ ડાયલ કરે છે. પ્રદાતાઓ એન્ડપોઇન્ટ ફેરવે છે, અને હોસ્ટનામ ઉકેલતી પ્રોફાઇલ DNS ફેરફારને અનુસરીને નવા સરનામે જશે જ્યારે નિયમ જૂનાને જ સૂચવતો રહેશે. જ્યારે મહિનાઓ સુધી ચાલેલી ટનલ ઉપર આવવાનું બંધ કરે, ત્યારે કંઈપણ પહોળું કરતા પહેલાં નિયમના સરનામાને ક્લાયન્ટ જે સરનામું શોધી રહ્યું છે તેની સાથે સરખાવો.
આખા સબનેટ સુધી, અથવા પોર્ટ 1194 પરના દરેક ગંતવ્ય સુધી પહોળું કરવું નીતિને ફરી છિદ્રવાળી ફાયરવોલમાં ફેરવે છે. અપવાદ એ કિલ સ્વિચ છે; એકવાર તે પહોળો થાય, પછી બંધ કરવા જેવું કંઈ રહેતું નથી. તેને એક સરનામા પર રાખો અને જે પ્રોફાઇલ અને પ્રદાતાનો તે છે તે નામ આપતી ટિપ્પણી છોડો, કારણ કે છ મહિના પછી સરનામું મનમાન્યું લાગશે.
નામ ઉકેલવું પોતાની અલગ લાઇનને લાયક છે. શોધ ટનલ અસ્તિત્વમાં આવે તે પહેલાં, ભૌતિક ઇન્ટરફેસ પર થાય છે, તેથી કડક આઉટગોઇંગ નકાર નીતિ ક્લાયન્ટને પોતાનું સર્વર શોધી ન શકે તેમ છોડી શકે છે. તમારા રિઝોલ્વરના સરનામા પર પોર્ટ 53 ને મંજૂરી આપો, અથવા એક વાર ઉકેલીને સરનામું પ્રોફાઇલમાં પિન કરો. દરેક ઇન્ટરફેસ પર DNS ની મંજૂરી એ નિર્ણય છે, ડિફોલ્ટ નહીં.
ટનલની જરૂર પડે તે પહેલાં નીતિ બનાવો
ufw enable આખી નીતિ એકસાથે લાગુ કરે છે અને તેની સાંકળો ફરી લોડ કરે છે, અને ચાલુ ફાયરવોલ પર ડિફોલ્ટ નીતિ બદલવાથી પણ તે ફરી લોડ થાય છે. ufw મેન્યુઅલ ચેતવે છે કે આ SSH જેવા હાલના કનેક્શન પાડી શકે છે. તેથી આદેશો આ ક્રમમાં જાય છે, SSH નિયમ સક્રિય કરવાના પહેલાં અને કન્સોલ સેશન ખુલ્લું રાખીને:
sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose
ufw reset જાણી જોઈને તે બ્લોકની બહાર રાખવામાં આવ્યું છે. તે દરેક નિયમ કાઢી નાખે છે અને ફાયરવોલ નિષ્ક્રિય કરે છે, અને દૂરસ્થ હોસ્ટ પર તે પછીનું સક્રિયકરણ જ તમારું સેશન પાડે છે. જો તમે ખરેખર રીસેટ કરો, તો SSH નિયમ ઉમેરો અને આગળ વધતા પહેલાં કન્સોલ દ્વારા પાછા આવવાનો બીજો રસ્તો ખાતરી કરો.
ક્રમ દેખાવનો નથી. ufw ચાલુ હોય ત્યારે ઉમેરાયેલા નિયમો કંઈ ફ્લશ કરતા નથી, પણ જે ક્ષણે તમે ડિફોલ્ટ નીતિ ફેરવો છો ત્યારે સાંકળો ફરી લોડ થાય છે, અને જૂની નીતિએ મંજૂરી આપેલું સેશન તેમની સાથે જાય છે. ડિફોલ્ટ, મંજૂરીઓ અને સક્રિયકરણ એક જ પાસમાં કરો, જ્યારે તમારી પાસે મશીન પર આધારિત ન હોય તેવો પ્રવેશમાર્ગ હજી હોય.
અવરોધિત સ્થિતિ ચકાસો, અને પૂર્વવત્ કરવાનું રાખો
ન ચકાસાયેલ કિલ સ્વિચ એ અનુમાન છે. ક્લાયન્ટને જાણી જોઈને ડિસ્કનેક્ટ કરો અને પૃષ્ઠ લોડ કરવાનો પ્રયાસ કરો: તે નિષ્ફળ જવું જોઈએ. ફરી જોડાઓ અને કોઈ નિયમને સ્પર્શ કર્યા વિના તે પુનઃપ્રાપ્ત થવું જોઈએ. sudo ufw status verbose ડિફોલ્ટ અને લોગિંગ સ્થિતિની પુષ્ટિ કરે છે, અને ufw status numbered બતાવે છે કે જ્યારે પરીક્ષણ નિયમ તેના હેતુથી વધુ જીવે ત્યારે કયો કાઢી નાખવો.
ઉલટી સ્ક્રિપ્ટને આગળની સ્ક્રિપ્ટની બાજુમાં રાખો. આઉટગોઇંગ નકાર અને મૃત ટનલ ધરાવતું મશીન પોતાનું સમારકામ ડાઉનલોડ કરી શકતું નથી, તેથી પૂર્વવત્ કરવાનું ડિસ્ક પર હોવું જોઈએ અને કન્સોલથી વાંચી શકાય તેવું હોવું જોઈએ:
sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
જ્યારે ટનલ પહેલેથી નીચે હોય અને નિયમો દૂર કરવાના હોય ત્યારે તેને ચલાવો, નિયમિત પગલા તરીકે નહીં. ટર્મિનલ બંધ કરતા પહેલાં ચાર વસ્તુઓ સાચી હોવી જોઈએ: પીઅર નિયમ બરાબર એક સરનામું નામ આપે છે, DNS પાસે નામ આપેલો અપવાદ છે, સક્રિયકરણ મંજૂરીઓ પછી આવ્યું છે, અને ટનલ ખેંચવાથી સામાન્ય ટ્રાફિક મરે છે પણ ક્લાયન્ટ કાયમ માટે મરતું નથી.