Pi erişim noktası, Pi-hole ve VPN: her hizmete bir görev atayın
Tek bir Pi'de üç yardımcıyı etkinleştirmeden önce DHCP, DNS ve paket yönlendirmenin sahibini belirleyin. Yinelenen sahipler rekabet eden kiralamalar ve çözümleyici döngüleri üretir.
Bir telefon Pi'nin erişim noktasına bağlanır, adres alır ve sayfa yine de açılmaz. Pi bir erişim noktası yardımcısı, Pi-hole ve bir VPN istemcisi çalıştırır ve her biri yolun bir bölümüne sahip olduğunu sanır. Bu kurulumların çoğu bir bileşen bozuk olduğu için değil, iki bileşen aynı işi yaptığı için başarısız olur. Herhangi birini ayarlamadan önce her işleve tek bir sahip atayın.
Her işleve tek bir sahip atayın
Burada dört işlev önemlidir ve her biri tam olarak bir sahip gerektirir. Aşağıdaki tablo işlevi, işe yarar bir sahibi ve iki hizmet onu talep ettiğinde neyin ters gittiğini gösterir.
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
Örtüşme genellikle her seferinde bir paket olarak gelir. Erişim noktası yardımcısı kendi dnsmasq örneğini kurar, Pi-hole 53 numaralı bağlantı noktasını ister ve VPN istemcisi rotalar ekler. Her adım tek başına makul görünür ve birlikte, başlatılan ikinci hizmetin birincinin davranışını sessizce değiştirdiği bir makine üretirler.
Başka bir şeyi etkinleştirmeden önce sahipleri yazın. Derleme notlarındaki kısa bir tablo, daha sonraki bir kurulumun zaten sahibi olan bir işlevi devralmasını önler.
Tek bir aralık seçin ve onu tünelden uzak tutun
Erişim noktası aralığını, bu aralıktaki Pi adresini, DHCP havuzunu ve istemcilerin aldığı çözümleyiciyi seçin. Bu aralığı yukarı akış LAN'ından ve VPN tüneli aralığından ayrı tutun, çünkü çakışan alt ağlar bir yönlendirme sorununu adres çevirisi projesine dönüştürür. Tünelle çakışan bir aralık, Pi'yi iki aynı önek arasında kazara bir yönlendirici yapar. Aralığı ve havuzu varsayılana bırakmak yerine erişim noktası yapılandırmasına yazın.
Erişim noktasının sahibi NetworkManager'ın paylaşımlı moduysa, bir DHCP sunucusu eklemeden önce etkin bağlantıyı inceleyin. Paylaşımlı mod kendi yardımcılarını başlatır ve yönlendirmeyi etkinleştirir, bu nedenle o arabirim için adres planının sahibi zaten odur. Kullanılabilir olduğu için ikinci bir sunucu eklemek yedeklilik değil, rekabet eden teklifler yaratır.
IPv6'ya bilinçli karar verin. Yönlendirici duyuruları ve DHCPv6 birçok kurulumda DHCPv4'ten farklı bir yardımcıdan gelir ve VPN ilkesi yalnızca IPv4'ü kapsarken IPv6'yı açık bırakmak istemcilere tüneli atlayan bir yol verir. Ya IPv6 tarafını planlayın ya da yazılı bir gerekçeyle erişim noktası arabiriminde devre dışı bırakın.
53 numaralı bağlantı noktasında gerçekte kim yanıt veriyor
Bir yapılandırmayı değiştirmeden önce 53 numaralı bağlantı noktasını dinleyen her süreci listeleyin. Yerel bir çözümleyici stub'ı, Pi-hole ve bir paylaşım yardımcısı çalıştıran bir Pi'de, dinleyici listesi sorguları kimin yanıtladığının tek güvenilir haritasıdır:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routePi-hole'un arabirim kılavuzu, tek bir arabirimle sınırlı bir alma modunun yine de joker karakterli bir soket kullanabileceğini ve başka yere gelenleri atabileceğini açıklar. Bu, yalnızca seçili arabirimlere bağlanmakla aynı şey değildir; başka bir DNS hizmetinin makineyi paylaşması gerektiğinde amaçlanan düzen budur.
İki süreç normalde aynı adrese ve bağlantı noktasına bağlanamaz, ancak SO_REUSEPORT paylaşılan bir bağlamayı başarılı kılabilir; o zaman bile joker karakterli bir dinleyici, daha dar hizmete yönelik gelenleri alabilir. İstediğiniz rol için belgelenmiş modu seçin ve hizmetleri amaçlanan sırayla yeniden başlatın.
Pi-hole'un yönetim sayfasını erişim noktası ağından uzak tutun. İstemcilerin bir çözümleyiciye ihtiyacı vardır, çözümleyicinin yapılandırmasını değiştirebilen web arabirimine veya API'ye değil.
İki DNS bacağı, her birine bir ilke
Bir istemci sorgusu telefondan Pi'ye gider ve ayrı bir sorgu Pi'den yukarı akış çözümleyicisine gider. Yönlendirilen erişim noktası trafiğiyle eşleşen bir yönlendirme kuralı ikinci bacağa otomatik olarak uygulanmaz, çünkü Pi bu trafiği yerel olarak üretir. VPN'in DNS taşıması gerekiyorsa yerel yolun kendi ilkesine ihtiyacı vardır.
Döngüye dikkat edin. Pi-hole'un yukarı akışını Pi'nin kendi sunduğu bir adrese yönlendirmek, doğrudan veya bir bağlantı noktası yönlendirmesiyle, zaman aşımına uğrayana kadar dönen sorgular üretir. Ona gerçek bir yukarı akış ya da yanıtlayamadığı alan adları için koşullu bir iletici verin.
Tünel düştüğünde ne olacağına karar verin. Yerel çözümleyiciye geri dönmek gezinmeyi canlı tutar ama adları VPN dışına sızdırabilir; engellemek ilkeyi bozulmadan korur ve kesintiyi görünür bir hataya dönüştürür. Her iki seçim de savunulabilir, ancak varsayılandan devralınmak yerine seçilmelidir.
Yolu ve kesinti davranışını kanıtlayın
Katmanlar halinde test edin: istemci adres alır, istemci bir adı Pi üzerinden çözer, Pi amaçlanan yukarı akış üzerinden çözer ve bir uygulama isteği tamamlar. Başarılı bir ping DNS hakkında hiçbir şey söylemez ve başarılı bir arama yönlendirme hakkında hiçbir şey söylemez.
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1Sonra tüneli durdurun ve yineleyin. Amaçlanan davranış birkaç saniye içinde görünmelidir, Pi-hole veya erişim noktası hizmetinin elle yeniden başlatılmasından sonra değil. Kesinti sırasında istemcinin çözümleyici ayarını kontrol edin, çünkü ikincil bir genel çözümleyici, ilke hata beklerken bile yanıtlamaya devam eder.
Yönlendirme ve NAT için tek bir sahip tutun ve bunu Pi'nin kendisinden değil bir istemciden doğrulayın. Pi'den başarıyla çıkan bir istek dönüş yolunda yine de düşürülebilir ve tüm yolun görülebildiği tek yer istemcidir.