UFW ටනලය ඉහළ ගිය පසු VPN හි DNS සේවාදායකය ඉවත් කරයි
UFW හි පෙරනිමි ප්‍රතික්ෂේප ප්‍රතිපත්තිය ටනල අතුරුමුහුණත ද ආවරණය කරයි. රථවාහනය දිශාව අනුව පිළිවෙළට සකසා, tun0 මත තල්ලු කළ resolver ට අවසර දී, පසුව පිටත මාර්ගය විවෘත කරන්න.
VPN සම්බන්ධ වන මොහොතේ නම් විසඳීම නතර වේ, එහෙත් පොදු ලිපිනයකට ping තවමත් පිළිතුරු දෙන අතර firewall තත්ත්වයේ වැරදි ලෙස පෙනෙන කිසිවක් නොපෙනේ. ප්‍රතිපත්තියේ කිසිවක් වෙනස් වී නැත; වෙනස් වූයේ නව අතුරුමුහුණතක් පෙනී ආ බවයි, සහ පෙරනිමි ප්‍රතික්ෂේපය පළමු පැකට්ටුවේ සිට එය ආවරණය කරයි. UFW තීරණය කරන්නේ දිශාව සහ අතුරුමුහුණත අනුව බැවින්, රැහැන් රහිත සබැඳිය සඳහා ලියූ නියමයක් ටනලයෙන් පිටවන රථවාහන ගැන කිසිවක් නොකියයි. ප්‍රතිසංස්කරණය වන්නේ නිශ්චිත අනුපිළිවෙලකින් යෙදෙන පටු නියම කිහිපයකි.
රෝග ලක්ෂණය පෙනෙන්නේ ටනලය ඉහළ ගිය පසුව පමණි
පෙරනිමි ප්‍රතික්ෂේප ප්‍රතිපත්තිය කරන්නේ එයට කී දේ හරියටමය: ගැළපෙන නියමයක් නැති සියල්ල ප්‍රතික්ෂේප වේ, පවතින සෑම අතුරුමුහුණතකම. නියම ලියන විට ටනලය නොතිබුණි, එබැවින් ඒවායින් කිසිවකට එය අල්ලා ගත නොහැක, සහ සැමවිටම තිබූ ප්‍රතික්ෂේපය දැන් නම් විසඳීමට අදාළ වේ. වචනාර්ථ ලිපිනයකට සෘජු රථවාහනය පුළුල් අවසරයක් එය ආවරණය කරන විට තවමත් ක්‍රියා කළ හැක, එබැවින් පොදු resolver එකකට ping සාර්ථක වන අතර නමක් සෙවීම අසාර්ථක වේ. හිඩැස වන්නේ ප්‍රතිපත්තිය කිසිදා නොදුටු අතුරුමුහුණතක් සඳහා වන නියමයකි.
මෙය අසාර්ථකත්වය පිරිසිදු ලෙස ප්‍රතිලෝම වන්නේ මන්දැයි ද පැහැදිලි කරයි: ටනලය පහත දමන්න, නම් නැවත විසඳේ, මන්ද විමසුම නියම ඇති අතුරුමුහුණතකට නැවත යයි. ටනලය ඉහළ ඇති විට පමණක් අසාර්ථක වන ප්‍රතිපත්තියක් DNS ගැටලුවක් නොවේ, සහ resolver එකම සීරුමාරු කිරීම මෙහි වැඩිපුරම කාලය නාස්ති කරයි. resolver වින්‍යාසය කියවීමට පෙර අතුරුමුහුණත් ලැයිස්තුව කියවන්න.
දිශා තුනක්, වෙනස් නියම කට්ටල තුනක්
එක් සැසියක් දිශාවකට වඩා එකක නියම ස්පර්ශ කරයි, සහ ටනලයක් ඒවායින් සියල්ලම පාහේ වෙත දෙවන අතුරුමුහුණතක් එකතු කරයි. රථවාහනය මුලින්ම දිශාව සහ අතුරුමුහුණත අනුව පිළිවෙළට සැකසීම ඉතිරිය යාන්ත්‍රික කරයි, මන්ද පහත එක් එක් පේළියට තම ස්ථානයේ තම නියමය අවශ්‍ය වේ. උදාහරණ tun0 සහ 10.8.0.0/24 තටාකය භාවිතා කරයි, එබැවින් නම් සහ පරාස client ගේම ප්‍රතිදානයෙන් ආදේශ කරන්න.
| 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 |
පේළි දෙකක් බොහෝ විට ව්‍යාකූල වේ, මන්ද දෙකම ටනලය සඳහන් කරයි. resolver සඳහා වන නියමය client ටනලය තුළට යවන රථවාහනයට අවසර දෙයි, එහෙත් SSH සඳහා වන නියමය server එයින් ලබා ගන්නා රථවාහනයට අවසර දෙයි; ඒවා විවිධ යන්ත්‍රවල ජීවත් වන අතර ස්වාධීනව අසාර්ථක වේ. වඩාත්ම අමතක වන පේළිය දෙවැන්නයි, මන්ද server ගේ පොදු ලිපිනයට client ගේ රථවාහනයට අවසර ලබා දෙන තුරු client ටනලය ගොඩනැගීමට පවා නොහැක. ඉහළ සිට පහළට වැඩ කරන්න, සහ සෑම අසාර්ථකත්වයකටම එක් සම්භාව්‍ය හේතුවක් ඇත.
තල්ලු කළ resolver ට තමන්ගේම නියමයක් අවශ්‍යයි
ටනලය DNS ගෙන යනවාද නැද්ද යන්න රඳා පවතින්නේ server යවන දෙය මතය. resolver විකල්පය තල්ලු කරන server එකක් client ගේ වින්‍යාසයේ පෞද්ගලික ලිපිනයක් ස්ථාපනය කරයි, සහ එම ලිපිනය මාර්ගගත කළ හැක්කේ ටනලය හරහා පමණි. server කිසිවක් තල්ලු නොකරන්නේ නම්, client ට කලින් තිබූ resolver රඳවා ගනී, සහ පහත නියමවලට අවසර දීමට කිසිවක් නැත. කිසිවක් ලිවීමට පෙර තල්ලු කළ තත්ත්වය සහ වත්මන් විමසුම් ප්‍රතිඵලය පරීක්ෂා කරන්න:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedතත්ත්ව ප්‍රතිදානය භාවිතා වන resolver සහ එය බැඳී ඇති සබැඳිය නම් කරයි, සහ එහි පිටුපස ඇති මාර්ග සෙවීම එම ලිපිනයට විමසුමක් ගෙන යන්නේ කුමන අතුරුමුහුණතද යන්න පෙන්වයි. resolver වෙනත් සබැඳියක වාඩි වී ඇති විට, ගැටලුව firewall ට පෙර එකකි, සහ කිසිදු නියමයක් උදව් නොකරනු ඇත. දෙකම ටනලය ගැන එකඟ වන විට, නියම දෙකක් අවශ්‍ය වේ, මන්ද බොහෝ විමසුම් 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'ඇතුළත මාර්ගයට පෙර පිටත මාර්ගය විවෘත කරන්න
ටනලයක් පැවතීමට පෙර client ට server ගේ පොදු ලිපිනයට ළඟා විය යුතුය, එබැවින් ඒ සඳහා වන නියමය භෞතික සබැඳියේ වාඩි වන අතර මුලින්ම එහි තැන තිබිය යුතුය. resolver ට අවසර දී server අමතක කරන ප්‍රතිපත්තියක් client ට ටනලය ගොඩනැගීමට නොහැකි තත්ත්වයක තබයි, සහ එම රෝග ලක්ෂණය සාමාන්‍යයෙන් 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'පරීක්ෂණයේදී අනුපිළිවෙල වැදගත් වේ, මන්ද ටනලය ඉහළ එන්නට ඉඩ දෙන්නේ පළමු නියමයයි. එය එකතු කර, සම්බන්ධ වී, සේවා නියමය එකතු කිරීමට පෙර ටනලය ඉහළ ඇති බව තහවුරු කරන්න, මන්ද දෙකම එකවර කිරීම යනු අසාර්ථකත්වය කුමන අර්ධය වැරදිද යන්න කිසිවක් නොකියන බැවිනි. ඉහත ලේඛන ලිපිනය වෙනුවට client සංරචක කර ඇති අන්ත ලක්ෂ්‍යය දමන්න.
හිතාමතා සම්බන්ධතාවය විසන්ධි කර client පැත්ත අවසන් කරන්න. ප්‍රතික්ෂේපය තවමත් ඔබ හිතාමතා බැහැර කළ රථවාහනය ප්‍රතික්ෂේප කළ යුතුය, මන්ද ටනලය ඉහළ ඇති විට පිළිතුරු දෙන resolver එකක් සැකයේදී ප්‍රතික්ෂේප කරන ප්‍රතිපත්තියේ අඩක් පමණක් ආවරණය කරයි.
සම්බන්ධ වන client තවමත් ඇතුළත් කර නැත
server ට සැලකිය යුතු තමන්ගේම දිශාවක් ඇත, සහ අත් සෙල්ලම අවසන් කරන client ට server එය පිළිගන්නා තුරු server මත ධාවනය වන කිසිවකට ළඟා විය නොහැක. පොදු සවන්දෙන්නාගේ නියමය ටනලය පැවතීමට පමණක් ඉඩ දෙයි; එය ටනලයේ රථවාහනය ඇතුළට නොයවයි. server මත මේවා නියම දෙකක් සහ සේවාව ඇත්තටම සවන් දෙන බවට එක් පරීක්ෂාවකි:
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'නියමයේ තටාකය server වෙන් කරන පරාසයට සමාන විය යුතුය, සහ ටනල අංකය server නිර්මාණය කළ අංකයට ගැළපිය යුතුය, මන්ද වෙනත් අතුරුමුහුණතක් සඳහා වන නියමයක් නියමයක් නොමැති වීමෙන් වෙන් කළ නොහැක. limit පරිපාලන වරායක් සඳහා හිතාමතා ය, මන්ද එය පුනරාවර්තන සම්බන්ධතා සීමා කරයි, සීමාවකින් තොරව පිළිගැනීම වෙනුවට. සවන්දෙන්නා පරීක්ෂාව වසා ඇති වරායක් සහ ඉවතට දැමූ පැකට්ටුවක් වෙන් කරයි, ඒවා client ගේ පැත්තෙන් එකම ලෙස පෙනේ. අංකිත නියම ද සම්පූර්ණ පින්තූරය නොවේ: UFW හි before නියම සහ අතින් ලියූ ඕනෑම nftables පේළියක් කලින් ගැළපෙන අතර ලැයිස්තුව අවසර දෙන බව පෙනෙන පැකට්ටුවක් පවා තවමත් ප්‍රතික්ෂේප කළ හැක.