UFW ટનલ ચાલુ થતાં જ VPN ના DNS સર્વરને કાઢી નાખે છે
UFW ની ડિફોલ્ટ નકાર નીતિ ટનલના ઇન્ટરફેસને પણ આવરી લે છે. ટ્રાફિકને દિશા પ્રમાણે ગોઠવો, tun0 પર પુશ કરેલા રિઝોલ્વરને મંજૂરી આપો, પછી બહારનો માર્ગ ખોલો.
VPN કનેક્ટ થાય તે ક્ષણે જ નામો ઉકેલાવાનું બંધ થઈ જાય છે, જ્યારે જાહેર સરનામાં પર ping હજી જવાબ આપે છે અને ફાયરવોલ સ્થિતિમાં ખોટું લાગે એવું કંઈ દેખાતું નથી. નીતિમાં કંઈ બદલાયું નથી; બદલાયું તે એ છે કે નવું ઇન્ટરફેસ આવ્યું, અને ડિફોલ્ટ નકાર તેને પહેલા પેકેટથી જ આવરી લે છે. UFW દિશા અને ઇન્ટરફેસ પ્રમાણે નક્કી કરે છે, તેથી વાયરલેસ લિંક માટે લખાયેલો નિયમ ટનલમાંથી નીકળતા ટ્રાફિક વિશે કંઈ કહેતો નથી. સુધારો એ થોડાક સાંકડા નિયમો છે જે ચોક્કસ ક્રમમાં લાગુ પડે છે.
લક્ષણ ફક્ત ટનલ ચાલુ થયા પછી જ દેખાય છે
ડિફોલ્ટ નકાર નીતિ બરાબર એ જ કરે છે જે કહેવામાં આવ્યું છે: મેળ ખાતો નિયમ ન હોય તેવું બધું નકારવામાં આવે છે, અસ્તિત્વમાં હોય તેવા દરેક ઇન્ટરફેસ પર. નિયમો લખાયા ત્યારે ટનલનું અસ્તિત્વ નહોતું, તેથી તેમાંનો કોઈ પણ તેને પકડી શકતો નથી, અને જે નકાર હંમેશા ત્યાં હતો તે હવે નામ ઉકેલવા પર લાગુ થાય છે. શાબ્દિક સરનામાં પર સીધો ટ્રાફિક ત્યારે પણ કામ કરી શકે છે જ્યારે વધુ પહોળી પરવાનગી તેને આવરી લે, અને એટલે જ જાહેર રિઝોલ્વર પર ping સફળ થાય છે જ્યારે નામની શોધ નિષ્ફળ જાય છે. ખાલી જગ્યા એ એવા ઇન્ટરફેસ માટેનો નિયમ છે જે નીતિએ ક્યારેય જોયો નથી.
એ પણ સમજાવે છે કે નિષ્ફળતા કેમ સ્વચ્છ રીતે ઊંધી થાય છે: ટનલ નીચે ઉતારો અને નામો ફરી ઉકેલાય છે, કારણ કે ક્વેરી એવા ઇન્ટરફેસ પર પાછી જાય છે જેની પાસે નિયમો છે. ફક્ત ટનલ ચાલુ હોય ત્યારે નિષ્ફળ થતી નીતિ DNS સમસ્યા નથી, અને રિઝોલ્વરને જ ટ્યુન કરવાથી અહીં સૌથી વધુ સમય બગડે છે. રિઝોલ્વર રૂપરેખા વાંચતા પહેલા ઇન્ટરફેસ યાદી વાંચો.
ત્રણ દિશાઓ, ત્રણ અલગ નિયમ-સેટ
એક સત્ર એક કરતાં વધુ દિશામાં નિયમોને સ્પર્શે છે, અને ટનલ લગભગ દરેકમાં બીજું ઇન્ટરફેસ ઉમેરે છે. ટ્રાફિકને પહેલા દિશા અને ઇન્ટરફેસ પ્રમાણે ગોઠવવાથી બાકીનું યાંત્રિક બની જાય છે, કારણ કે નીચેની દરેક પંક્તિને પોતાની જગ્યાએ પોતાનો નિયમ જોઈએ છે. ઉદાહરણો tun0 અને 10.8.0.0/24 નો પૂલ વાપરે છે, તેથી ક્લાયન્ટના પોતાના આઉટપુટમાંથી નામો અને શ્રેણીઓ મૂકો.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
બે પંક્તિઓ ઘણી વાર ગૂંચવાય છે કારણ કે બંને ટનલનો ઉલ્લેખ કરે છે. રિઝોલ્વર માટેનો નિયમ એ ટ્રાફિકને મંજૂરી આપે છે જે ક્લાયન્ટ ટનલમાં મોકલે છે, જ્યારે SSH માટેનો નિયમ એ ટ્રાફિકને મંજૂરી આપે છે જે સર્વર ત્યાંથી મેળવે છે; તેઓ અલગ મશીનો પર રહે છે અને સ્વતંત્ર રીતે નિષ્ફળ જાય છે. સૌથી વધુ ભૂલાતી પંક્તિ બીજી છે, કારણ કે સર્વરના જાહેર સરનામાં પર ક્લાયન્ટનો ટ્રાફિક મંજૂર ન થાય ત્યાં સુધી ક્લાયન્ટ ટનલ બનાવી જ શકતો નથી. ઉપરથી નીચે કામ કરો અને દરેક નિષ્ફળતાનું એક સંભવિત કારણ હોય છે.
પુશ કરેલા રિઝોલ્વરને પોતાનો નિયમ જોઈએ
ટનલ DNS વહન કરે છે કે નહીં તે સર્વર શું મોકલે છે તેના પર આધાર રાખે છે. જે સર્વર રિઝોલ્વર વિકલ્પ પુશ કરે છે તે ક્લાયન્ટની રૂપરેખામાં ખાનગી સરનામું સ્થાપિત કરે છે, અને તે સરનામું ફક્ત ટનલ દ્વારા જ રૂટ કરી શકાય છે. જો સર્વર કંઈ પુશ ન કરે, તો ક્લાયન્ટ પાસે પહેલેથી હોય તેવું રિઝોલ્વર રહે છે અને નીચેના નિયમો પાસે મંજૂર કરવા જેવું કંઈ હોતું નથી. કંઈ પણ લખતા પહેલા પુશ કરેલી સ્થિતિ અને વર્તમાન ક્વેરી પરિણામ તપાસો:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedસ્થિતિ આઉટપુટ વપરાતું રિઝોલ્વર અને તે જે લિંક સાથે જોડાયેલું છે તેનું નામ આપે છે, અને તેની પાછળની રૂટ શોધ દર્શાવે છે કે કયું ઇન્ટરફેસ તે સરનામે ક્વેરી વહન કરશે. જ્યારે રિઝોલ્વર બીજી લિંક પર હોય, ત્યારે સમસ્યા ફાયરવોલ પહેલાંની છે અને કોઈ નિયમ મદદ કરશે નહીં. જ્યારે બંને ટનલ પર સહમત થાય, ત્યારે બે નિયમો જરૂરી છે, કારણ કે મોટાભાગની ક્વેરી UDP વહન કરે છે અને જવાબ કપાઈ જાય ત્યારે TCP સંભાળે છે. બંને મૂલ્યો નોંધો, કારણ કે નિયમો ઠીક એમનાં જ નામ લેશે:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'અંદરના માર્ગ પહેલાં બહારનો માર્ગ ખોલો
ટનલ અસ્તિત્વમાં આવે તે પહેલાં ક્લાયન્ટે સર્વરના જાહેર સરનામે પહોંચવું પડે છે, તેથી તેનો નિયમ ભૌતિક લિંક પર બેસે છે અને પહેલા સ્થાને હોવો જોઈએ. જે નીતિ રિઝોલ્વરને મંજૂરી આપે પણ સર્વર ભૂલી જાય, તે ક્લાયન્ટને ટનલ બનાવવામાં સાવ અસમર્થ છોડે છે, અને આ લક્ષણ સામાન્ય રીતે kill switch પર ઢોળાય છે. પછી તમે ખરેખર ટનલ દ્વારા જે સેવાઓ ઇચ્છતા હતા તેને મંજૂરી આપો, એક સમયે એક સાંકડો નિયમ, આખું ઇન્ટરફેસ ખોલવાને બદલે. સાંકડા નિયમો એ જ કારણ છે કે નકાર સ્થાને રહી શકે છે.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'પરીક્ષણ કરતી વખતે ક્રમ મહત્વનો છે, કારણ કે પહેલો નિયમ જ ટનલને ચાલુ થવા દે છે. તેને ઉમેરો, કનેક્ટ થાઓ, અને સેવા-નિયમ ઉમેરતા પહેલા ટનલ ચાલુ છે તેની ખાતરી કરો, કારણ કે બંને એકસાથે કરવાથી નિષ્ફળતા કયો અડધો ભાગ ખોટો છે તે વિશે કંઈ કહેતી નથી. ઉપરના દસ્તાવેજી સરનામાના સ્થાને ક્લાયન્ટ જે એન્ડપોઇન્ટ વાપરવા માટે રૂપરેખાંકિત છે તે મૂકો.
જાણીજોઈને ડિસ્કનેક્ટ કરીને ક્લાયન્ટ બાજુ પૂરી કરો. નકાર હજી પણ એ ટ્રાફિક નકારવો જોઈએ જે તમે જાણીજોઈને બાકાત રાખ્યો છે, કારણ કે ટનલ ચાલુ હોય ત્યારે જવાબ આપતું રિઝોલ્વર શંકા પડે ત્યારે નકાર કરતી નીતિનો ફક્ત અડધો ભાગ આવરે છે.
કનેક્ટ થતો ક્લાયન્ટ હજી સ્વીકૃત નથી
સર્વરને પોતાની દિશા ધ્યાનમાં લેવાની હોય છે, અને હેન્ડશેક પૂરો કરતો ક્લાયન્ટ સર્વર તેને સ્વીકારે ત્યાં સુધી સર્વર પર ચાલતી કોઈ વસ્તુ સુધી પહોંચી શકતો નથી. જાહેર લિસનરનો નિયમ ફક્ત ટનલને અસ્તિત્વમાં રહેવા દે છે; તે ટનલનો ટ્રાફિક અંદર આવવા દેતો નથી. સર્વર પર તે બે નિયમો વત્તા એક ચકાસણી છે કે સેવા ખરેખર સાંભળી રહી છે:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'નિયમમાંનો પૂલ સર્વર જે શ્રેણી ફાળવે છે તેની સમાન હોવો જોઈએ, અને ટનલ નંબર સર્વરે બનાવેલા નંબર સાથે મેળ ખાવો જોઈએ, કારણ કે અલગ ઇન્ટરફેસ માટેનો નિયમ કોઈ નિયમ ન હોવાથી અલગ પડતો નથી. limit વ્યવસ્થાપક પોર્ટ માટે જાણીજોઈને છે, કારણ કે તે પુનરાવર્તિત કનેક્શનને અમર્યાદિત સ્વીકારવાને બદલે મર્યાદિત કરે છે. લિસનર ચકાસણી બંધ પોર્ટને ફેંકાયેલા પેકેટથી અલગ પાડે છે, જે ક્લાયન્ટની બાજુથી એકસમાન દેખાય છે. ક્રમાંકિત નિયમો પણ આખું ચિત્ર નથી: UFW ના before નિયમો અને હાથે લખાયેલી કોઈ પણ nftables લાઇન પહેલા મેળ ખાય છે અને યાદી મંજૂરી આપતી હોય તેવું લાગતું પેકેટ પણ હજી નકારી શકે છે.