<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Dnsmasq on Morfitronik</title>
    <link>https://morfikov.github.io/tags/dnsmasq/</link>
    <description>Recent content in Dnsmasq on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Sat, 19 Sep 2020 14:13:00 +0200</lastBuildDate><atom:link href="https://morfikov.github.io/tags/dnsmasq/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Szyfrowany DNS z dnscrypt-proxy i dnsmasq na Debian linux</title>
      <link>https://morfikov.github.io/post/szyfrowany-dns-z-dnscrypt-proxy-i-dnsmasq-na-debian-linux/</link>
      <pubDate>Sat, 19 Sep 2020 14:13:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/szyfrowany-dns-z-dnscrypt-proxy-i-dnsmasq-na-debian-linux/</guid>
      <description>&lt;p&gt;Ostatnio na forum dug.net.pl jeden z użytkowników &lt;a href=&#34;https://forum.dug.net.pl/viewtopic.php?id=31524&#34;&gt;miał dość spory problem&lt;/a&gt; z ogarnięciem
zadania polegającego na zaszyfrowaniu zapytań DNS z wykorzystaniem &lt;a href=&#34;https://dnscrypt.info/&#34;&gt;dnscrypt-proxy&lt;/a&gt; i
&lt;a href=&#34;http://www.thekelleys.org.uk/dnsmasq/doc.html&#34;&gt;dnsmasq&lt;/a&gt;. Ładnych parę lat temu opisywałem &lt;a href=&#34;https://morfikov.github.io/tags/resolver/&#34;&gt;jak skonfigurować te dwa narzędzia na Debianie&lt;/a&gt;
(i też na OpenWRT), choć od tamtego czasu w świecie linux&#39;owym trochę rzeczy się pozmieniało. Dla
przykładu, dnscrypt-proxy przeszedł gruntowną przebudowę, no i też systemd jest w powszechniejszym
użyciu niż to miało miejsce w tamtych czasach, przez co w sporej części przypadków usługi takie jak
&lt;code&gt;systemd-networkd.service&lt;/code&gt; czy &lt;code&gt;systemd-resolved.service&lt;/code&gt; są już włączone domyślnie. Zatem sporo
informacji zawartych w tych napisanych przeze mnie artykułach już niekoniecznie może znaleźć
obecnie zastosowanie. Dlatego też pomyślałem, że nadszedł już czas, by ździebko zaktualizować tamte
wpisy. Ostatecznie stanęło jednak na tym, by w oparciu o te artykuły napisać kompletnie nowy tekst
na temat szyfrowania zapytań DNS na linux przy wykorzystaniu oprogramowania &lt;code&gt;dnscrypt-proxy&lt;/code&gt; oraz
&lt;code&gt;dnsmasq&lt;/code&gt; i zawrzeć w nim te wszystkie ciekawsze informacje, które udało mi się pozyskać przez te
ostatnie lata w kwestii poprawy bezpieczeństwa i prywatności przy przeglądaniu stron WWW.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak zablokować Facebook i YouTube w OpenWRT</title>
      <link>https://morfikov.github.io/post/jak-zablokowac-facebook-youtube-openwrt/</link>
      <pubDate>Tue, 10 May 2016 22:17:38 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-zablokowac-facebook-youtube-openwrt/</guid>
      <description>&lt;p&gt;Serwisy społecznościowe takie jak Facebook, Twitter czy YouTube coraz bardziej dają się we znaki
przedsiębiorcom, który muszą cały czas pilnować, by ich pracownicy nie siedzieli ciągle w
internecie, przynajmniej w czasie pracy. Problem nagminnego przebywania w tych w/w portalach można
bardzo łatwo rozwiązać przez... porozmawianie z pracownikami. No może nie zawsze ale co nam szkodzi
spróbować? W przypadku, gdy upomnienia nie są w stanie zmusić ludzi w naszej firmie do pracy, a nie
możemy przy tym ich zwolnić, to możemy pójść o krok dalej i spróbować im założyć blokadę na te
powyższe serwisy. Oczywiście blokada szeregu adresów IP nie wchodzi w rachubę. Korporacje typu
Facebook czy Google mają wiele adresów IP na których świadczą swoje usługi. Nie wszystkie z nich są
uwzględniane na różnego rodzaju listach. Niemniej jednak, tak na dobrą sprawę to nie musimy nawet
znać tych adresów. Jedyne czego nam potrzeba to nazwa domeny oraz kilka pakietów standardowo
dostępnych w repozytorium OpenWRT. Mowa o &lt;code&gt;iptables&lt;/code&gt; , &lt;code&gt;dnsmasq&lt;/code&gt; oraz &lt;code&gt;ipset&lt;/code&gt; . W OpenWRT, przy
pomocy tych narzędzi możemy zaprojektować filtr, który może zablokować ludziom z naszej sieci dostęp
do praktycznie każdego serwisu www. W tym artykule zobaczymy jak taki filtr skonstruować.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>DHCP i DNS, czyli konfiguracja sieci w OpenWRT</title>
      <link>https://morfikov.github.io/post/dhcp-dns-czyli-konfiguracja-sieci-w-openwrt/</link>
      <pubDate>Mon, 02 May 2016 16:21:20 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/dhcp-dns-czyli-konfiguracja-sieci-w-openwrt/</guid>
      <description>&lt;p&gt;Rutery WiFi są w stanie zorganizować przewodową i/lub bezprzewodową sieć w naszych domach. By taka
sieć działała bez zarzutu, potrzebna jest odpowiednia adresacja wszystkich komputerów wewnątrz niej.
W obecnych czasach już praktycznie nie stosuje się statycznej konfiguracji, bo to zadanie zostało
zrzucone na barki serwera DHCP. W OpenWRT do tego celu oddelegowane jest &lt;a href=&#34;http://www.thekelleys.org.uk/dnsmasq/doc.html&#34;&gt;oprogramowanie
dnsmasq&lt;/a&gt;. Zapewnia ono nie tylko wspomniany wyżej serwer DHCP ale także serwer cache&#39;ujący
zapytania DNS. Ten drugi z kolei jest niezastąpiony w przypadku przekazywania zapytań o nazwy domen
do upstream&#39;owego serwera DNS, który zajmuje się rozwiązywaniem tych nazw na odpowiadające im adresy
IP. Bez &lt;code&gt;dnsmasq&lt;/code&gt; ogarnięcie naszej sieci przerodziłoby się w istne piekło. Dlatego też w tym
artykule przybliżymy sobie nieco konfigurację tego narzędzia.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Aero2 w połączeniu z dnsmasq i dnscrypt-proxy</title>
      <link>https://morfikov.github.io/post/aero2-w-polaczeniu-z-dnsmasq-dnscrypt-proxy/</link>
      <pubDate>Sat, 02 Apr 2016 18:47:47 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/aero2-w-polaczeniu-z-dnsmasq-dnscrypt-proxy/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://aero2.pl/&#34;&gt;Aero2&lt;/a&gt; już od dość dawna oferuje darmowy dostęp do internetu w technologi LTE ale jakoś
wcześniej nie byłem tym tematem zainteresowany. Parę dni temu złożyłem jednak wniosek o kartę SIM,
tak by posiadać zapasowe łącze na wypadek, gdyby mój obecny ISP z jakiegoś powodu padł. Aero2
oferuje wersję komercyjną jak i tę za free i każda z nich ma swoje wady i zalety. Jako, że to łącze
ma robić jedynie za zapas, to korzystam z wersji FREE, a jest ono dość poważne ograniczenie, tj.
występuje tutaj &lt;a href=&#34;https://pl.wikipedia.org/wiki/CAPTCHA&#34;&gt;kod CAPTCHA&lt;/a&gt;, który trzeba wpisywać tak co godzinę, po czym należy resetować
modem. Ten kod może zostać zaserwowany jedynie w przypadku korzystania z DNS Aero2 i pozornie
odpada możliwość używania własnego systemu DNS opartego o &lt;a href=&#34;http://www.thekelleys.org.uk/dnsmasq/doc.html&#34;&gt;dnsmasq&lt;/a&gt; i &lt;a href=&#34;https://dnscrypt.org/&#34;&gt;dnscrypt-proxy&lt;/a&gt;. Po
kilku dniach eksperymentów udało mi się wypracować przyzwoitą konfigurację, która potrafi obejść to
ograniczenie, poprawiając tym samym prywatność i bezpieczeństwo w internecie korzystając z
darmowego LTE za sprawą Aero2. W tym wpisie postaramy się zaimplementować ten mechanizm na debianie.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Cache DNS, czyli włączenie buforowania zapytań</title>
      <link>https://morfikov.github.io/post/cache-dns-buforowania-zapytan/</link>
      <pubDate>Mon, 16 Nov 2015 20:13:06 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/cache-dns-buforowania-zapytan/</guid>
      <description>&lt;p&gt;Większość z nas wie, że standardowe instalacje systemu linux nie buforują żadnych zapytań do
serwerów DNS. Dzieje się tak dlatego, że te systemy domyślnie nie mają zainstalowanego żadnego
oprogramowania, które by im to umożliwiało. Niesie to ze sobą zwiększenie opóźnień transakcji
krótkoterminowych, np. tych w protokole http czy https. Za każdym razem gdy odwiedzamy jakiś serwis
www, musimy wykonać szereg zapytań DNS, by rozwiązać nazwy domen na adresy IP. W przypadku gdybyśmy
mieli cache DNS, to te nazwy nie musiałyby być za każdym każdym razem rozwiązywane na nowo,
przynajmniej nie przez odpytywanie zdalnego serwera DNS, do którego RTT wynosi jakieś 20-40ms.
Przydałoby się zatem nieco poprawić wydajność stron www i w tym wpisie postaramy się zaimplementować
prosty cache DNS z wykorzystaniem &lt;a href=&#34;http://www.thekelleys.org.uk/dnsmasq/doc.html&#34;&gt;narzędzia dnsmasq&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
