Tek Pi'de hostapd ve OpenVPN: varsayılan yol kimin?

Telefonlar erişim noktasına bağlanır, bir adres alır ve tünel açılır açılmaz hiçbir yere ulaşamaz. hostapd bu durumda genellikle sağlıklıdır ve OpenVPN de öyle; bozulan şey varsayılan yoldur, ya köprüde hiç var olmamıştır ya da tünel onu VPN sunucusunun kendisine giden bir yol bırakmadan değiştirmiştir. Bu kılavuz o yolu olması gereken yere geri koyar ve sonucu Pi'den değil bir istemciden kanıtlar. Her adım geri alınabilir ve burada hiçbir şey, içinde hangi trafiği istediğinizi bilene kadar tünel yapılandırmasını değiştirmez.

Herhangi bir şeyi düzenlemeden önce arayüzleri envanterleyin

Bilinen düzen, kablosuz radyoyu ve kablolu bağlantı noktasını br0 içine koyar, hostapd'yi köprüye karşı başlatır ve dnsmasq'den kiralama dağıtır, bir OpenVPN istemcisi ise tun0 oluşturur. Sonra üç ayrı gereksinim tek gibi görünür: erişim noktası istemcileri ağ geçidi olarak Pi'ye ihtiyaç duyar, Pi kendi sunucusuna ulaşmak için internete bir yol gerekir ve köprü o istemcilerin kullanabileceği bir ağ geçidi adresine ihtiyaç duyar.

Değiştirmeden önce mevcut durumu okuyun, çünkü bu dört komut bir arayüz sorununu bir yönlendirme sorunundan ayırır.

ip -br addr
ip route show
ip link show master br0
bridge link show

br0 bir adres taşıyor ancak varsayılan yolu yoksa, istemciler Pi'ye ulaşır ve ötesine geçemez. Tünel kapalıyken varsayılan yol tun0 işaret ediyorsa, Pi'nin çalışan hiçbir yolu yoktur ve istemci belirtisi tamamen aynı görünür. Her iki durum da telefondan aynı görünür, bu yüzden yönlendirme tablosu doğrudan okunmalıdır.

Köprüye kendisine ait bir varsayılan yol verin

Raspberry Pi OS, arayüz dosyası yazıldıktan sonra oluşan köprüyü sıklıkla varsayılan yolsuz bırakır. Blok /etc/dhcpcd.conf içinde olmalıdır ve Pi'yi değil, üst yönlendiriciyi adlandırmalıdır.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

Bu örnekte 192.168.50.1 mevcut yönlendiricidir ve 192.168.50.2 aynı alt ağdaki Pi köprüsünün adresidir, bu yüzden sayıları kopyalamak yerine kendi planınızı koyun. Köprü üyeleri de yönlendirici istememelidir, aksi halde Pi'de kazananı niyetten değil metrik ve zamandan bağlı olan rakip varsayılanlar kalır.

systemctl restart dhcpcd sonrasında ip route show default br0 bir kez listelemeli ve kablolu bağlantı noktasından yinelenen olmamalıdır. Tabloyu değil aramayı doğrulayın, çünkü eski bir girdi kazanan bir girdinin yanında oturabilir: ip -4 route get 203.0.113.10 br0 adını vermelidir. Bu adres TEST-NET-3 belge aralığından gelir, bu nedenle bunu okurken gerçek bir sunucuyla çakışamaz.

Tünelin kendi sunucusuna giden yolu kaçırmasını engelleyin

redirect-gateway kabul eden bir OpenVPN istemcisi varsayılan yolu devralır ve tünele yönlendirir. Her erişim noktası istemcisinin VPN kullanması gerektiğinde bu doğrudur ve yalnızca bazı hedeflerin kullanması gerektiğinde yanlıştır. Her halükârda, Pi'nin sunucuya kendi bağlantısı hâlâ kurduğu tünelin içinden geçmemelidir. OpenVPN varsayılanı yönlendirdiğinde özgün ağ geçidi üzerinden uzağa bir ana makine yolu ekler ve tam olarak bu davranış taşımayı canlı tutar; bu yol yoksa tünel kurulur kurulmaz çöker.

O taşıma yolunun bağlanmadan önce ve sonra hızlı bir karşılaştırması o on saniyeye değer. ip -4 route get 203.0.113.10 her iki durumda da alt katman aygıtını adlandırmalıdır, yalnızca metrik değişir. Tünel açıldıktan sonra tun0 adını veriyorsa, ana makine yolu hiç yüklenmedi ve sonraki yeniden bağlantı başarısız olacak.

Yalnızca seçili önekler tüneli geçmeliyse, route-nopull kullanın ve istediğiniz yolları elle ekleyin ya da sunucudan daha dar bir küme gönderin. Bu tasarımda köprü varsayılan yolu korur ve DNS bir sonraki karar olur: dnsmasq'nun bir ev çözümleyicisine iletilmesi yalnızca gerçekten orada yaşayan adlar için anlamlıdır.

İletme ve NAT konusuna karar verin

Tam tünel, Pi'de etkin iletme ve erişim noktası alt ağını yönlendirmeye istekli bir karşı taraf ağ geçidi gerektirir. İletmeyi her şeyden önce kontrol edin, çünkü sıfır her yol değişikliğini anlamsız kılar.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NAT kuralı, sunucu erişim noktası önekini kabul etmediğinde işe yarayan kısa yoldur; bedeli, karşı taraf günlüklerinde her istemcinin Pi'nin tünel adresi olarak görünmesidir. Öneki NAT olmadan yönlendirmek adresleri görünür tutar ve ev tarafında 192.168.50.0/24 için bir dönüş yoluna bağlıdır.

Seçimi güvenlik duvarı kurallarının yanına yazın, çünkü tasarımda görünmeyen bir NAT kuralı altı ay sonra açıklanamaz hale gelir. IPv6'yı aynı kararda tutun; bozuk bir IPv6 yolunun yanındaki çalışan bir IPv4 yolu tarayıcıda hâlâ yarı bozuk olarak okunur.

Bir istemciden doğrulayın, sonra temiz bir şekilde geri alın

Erişim noktasındaki bir telefondan veya dizüstü bilgisayardan bu sırayla test edin: dnsmasq'den bir kiralama, köprü adresine ping, ardından tünelin diğer tarafında bir hedef. Her adım tek bir katmanı yalıtır, tek bir işe yaramaz hataya yol açmak yerine.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Ardından Pi'nin hâlâ kendi çıkış yolu olduğunu doğrulayın: ip route get 203.0.113.10 alt katman aygıtını adlandırmalı ve sunucu ICMP'ye izin veriyorsa ping -c 3 -I br0 203.0.113.10 yanıt vermelidir. İlk iki istemci adımı geçer ve üçüncüsü başarısız olursa, hata iletmede veya NAT'tadır. İkinci adım başarısız olursa, köprü veya DHCP hâlâ eksiktir.

Geri alma bir dosya düzenlemesi ve iki komuttur: bloğu kaldırın, dhcpcd'yi yeniden başlatın ve varsayılan yolu açıkça ip route replace default via 192.168.50.1 dev br0 ile değiştirin. Bunu bakım penceresi kapanmadan önce yapın, sonra değil, çünkü varsayılan yolunu kaybeden bir Pi, onu onarmak için kullanacağınız ağdan erişilemez olur.