Yönlendirici VPN'inden tek cihaz geçirmek üç kural ister, bir anahtar değil

Yönlendirici VPN'inde cihaz başına anahtar yoktur; aradığınız anahtar sizin adınıza politika yönlendirme kuralları yazan bir kısayoldur. Bir dizüstü bilgisayarın, bir bağlantı noktası aralığının, bir adres listesinin veya bir LAN segmentinin tüneli kullanması, geri kalan her şeyin WAN'da kalması gerektiği anda bir özelliği açmıyorsunuz, bir politika rotası kuruyorsunuz. İşin üç hareketli parçası var ve her biri farklı biçimde bozulur: rotası olmayan işaretlenmiş tablo sessizlik gibi görünür, yanlış zincire konan işaret hiçbir şey olmamış gibi görünür, eksik NAT kuralı ise bağlanan ama hiçbir şey taşımayan bir tünel gibi görünür. İki parça daha kaybolur çünkü mangle kuralında hiç görünmezler, bunlar DNS ve IPv6'dır.

Efsane: tünel bir istemci ayarıdır

Yönlendirici tarafındaki VPN istemcisi kaba bir işi iyi yapar: 0.0.0.0/0'ı ana yönlendirme tablosuna koyar ve tünele yönlendirir. WireGuard bunu AllowedIPs'ten türetir, OpenVPN sunucunun ittiği redirect-gateway'den türetir, ve ikisi de yönlendiricinin arkasındaki her ana bilgisayarın yolunu değiştirir. AllowedIPs'i daraltmak veya route-nopull eklemek istemcinin ne kurduğunu değiştirir. Kurulumun kime uygulandığını değiştirmez, çünkü istemci cihazları hiç görmez. Yalnızca paketleri görür.

Kaynağa veya hedefe göre seçim bir yönlendirme kararıdır, bu yüzden yönlendiricinin politika katmanına aittir: RouterOS'ta bir mangle kuralı artı ikinci bir tablo, OpenWrt veya DD-WRT'de MARK artı ip rule, ya da pfSense'te ağ geçidi tünel olan bir güvenlik duvarı kuralı. Netgate'in WireGuard istemci tarifi tahmin etmeden önce okunması gerekendir, çünkü o platformda kuralın ağ geçidi, arayüz ataması ve giden NAT girdisi tek bir istemci tüneli kullanmadan önce uzlaşmalıdır.

Efsanenin diğer yarısı ikinci yönlendiricidir. Başka bir kutu almak veya cihazı misafir SSID'ye taşımak çoğu zaman işe yarar ve nedeni donanım değildir: cihazı kendi alt ağına koyar, bu da size ürün yazılımının zaten anladığı kaynak seçiciyi verir. Sahip olduğunuz yönlendiricide o segmenti tanımlayabiliyorsanız, fazladan kutu sahip olmadığınız bir sorunu çözer.

Birinci parça: varsayılan rota olmayan bir tünel

RouterOS'ta istemciyi varsayılan rota olmadan ekleyin ve tünele kendi tablosunu verin. İlk rota işaretlenmiş varsayılandır; ikincisi hatanın yarısıdır.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

Ulaşılamayan rota, işaretlenmiş tablonun ana tablodaki istisna listesini neden yendiğinin cevabıdır. Tünel düştüğünde işaretli paketler sessizce WAN'a dönmek yerine anında ulaşılamaz alır, böylece arıza bir saat sonra kontrol ettiğiniz coğrafi konum sayfasında değil, uygulamanın hata iletisinde görünür.

RouterOS 7, 6.x'in bir arada tuttuğunu ayırır: tabloyu /routing table add name=vpn fib ile bildirirsiniz, sonra rotada ve mangle kuralında adıyla başvurursunuz. Tabloyu tanımlamadan routing-mark yazan 6.x parçası temiz yüklenir ve hiçbir şeyle eşleşmez. Diğer klasik iki 0.0.0.0/1 yarısı ya da tek bir tabloda aynı mesafede iki varsayılandır: çekirdek birini seçer ve yeniden başlatmadan sonra davranış değişebilir.

İkinci parça: rota aramasından önce işaretleyin

Seçici hangi paketlerin o tabloya gireceğine karar verir. RouterOS genellikle hedef politikası için bir adres listesiyle ya da cihaz politikası için kaynak adresle başlar:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Linux ürün yazılımı aynı şeyi bir netfilter işareti ve işaretli paketleri doldurduğunuz tabloya yönlendiren bir kuralla yapar:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

Zincir bir stil seçimi değildir. Bir paket FORWARD'a ulaştığında rota araması zaten yapılmıştır, dolayısıyla oradaki MARK veya DROP yalnızca yeniden yazabilir ya da atabilir. İşaret, iletilen trafik için PREROUTING'e ve yönlendiricinin kendi ürettiği trafik için OUTPUT'a düşmelidir; yönlendiricinin DNS, NTP ve güncelleme kontrolleri orada yaşar. O çıkış yolu, tamamen tünellenmiş bir kurulumun sızıntı testinde hâlâ ISS çözümleyicisinden yanıt vermesinin olağan nedenidir.

Cihaz politikası kaymayan bir eşleşme ister. Adresi DHCP'de ayırın ya da özel bir segment için arayüzü eşleştirin; sonradan başka bir cihaza geçen adres tüneli sessizce yanlış istemciye uygular. Kendi alt ağı olan SSID başına köprü aynı fikrin daha dayanıklı sürümüdür ve IPv6 kurallarına da yaşayacak yer verir.

Üçüncü parça: NAT, DNS ve LAN istisnası

Tünelden çıkan trafik, karşı tarafın yanıt vereceği bir kaynak adrese gereksinim duyar. Çeviriyi tünel arayüzüyle sınırlayın: RouterOS'ta out-interface=VPN_NAME, Linux'ta -o tun0, pfSense'te eşleşen giden NAT girdisi. Bu kapsam olmadan bir masquerade kuralı, dokunmadan bırakmak istediğiniz trafiği yeniden yazar ve belirti, tünelde olmayan cihazın genel adresini kaybetmesidir.

LAN istisnası, tünelin kendisinden daha çok destek konusu üretir. İşaretli tablo yalnızca varsayılan bir rota tutuyorsa, seçili cihazdan bir yazıcı veya NAS hedefi o varsayılanla eşleşir ve tünelin içinde kaybolur. Aynı tabloya LAN rotasını ekleyin ya da seçicide yerel alt ağı hariç tutun; ikisi de çalışır ve sonradan VLAN eklediğinizde hariç tutmayı doğru tutmak daha kolaydır.

DNS ayrı bir yol izler. Yönlendiricinin ilettiği sorgular yönlendiriciden kaynaklanır ve OUTPUT'u izler, iletilen işareti değil, bu yüzden tamamen tünellenmiş bir dizüstü bilgisayar hâlâ ISS üzerinden ad çözebilir. İstemcileri tünel üzerinden erişilebilen bir çözümleyiciye yönlendirin ya da yönlendiricinin kendi port-53 trafiğini işaretleyin, sonra yanıtın web isteğiyle birlikte yolculuk ettiğini varsaymak yerine çözülen adresi kontrol edin.

Kural eşleştiğinde ama uygulama hâlâ WAN kullandığında

Hedef listeleri kötü yaşlanır. Bir ad, listede olmayan bir adrese çözülür, bu yüzden istek WAN'a çıkar, oysa listelenen adrese yaptığınız her test çalışıyordu. Listeyi istemcinin kullandığı aynı çözümleyiciden yenileyin ve gerçekten tek bir cihazdan tüm trafiği istiyorsanız kaynak tabanlı bir seçiciyi yeğleyin.

IPv6 sessiz dolanma yoludur. Cihazın kendi varsayılan rotası ve kendi kural kümesi olan ikinci bir adres ailesi vardır ve yalnızca IPv4 adresiyle eşleştirmek politikanın yarısıdır. Aynı seçiciyi ip6tables ya da nftables eşdeğerine uygulayın veya o segmentte IPv6'yı kazayla değil bilerek kapatın.

Kurulmuş bağlantılar da önemlidir. Değişiklikten önce oluşturulmuş bir conntrack girdisi süresi dolana kadar eski yolu izlemeye devam eder, bu yüzden düzenleme sırasında açık kalan bir tarayıcı hiç uygulanmamış bir kural gibi görünür. Politikayı değerlendirmeden önce yeni bir bağlantı açın veya durumu temizleyin.

İki cihaz ve bir yeniden başlatmayla doğrulayın

Tünelde olması gereken cihazı ve olmaması gereken cihazı test edin, hız sayısı yerine ikinci atlamayı karşılaştırın. Her birinden traceroute, ikinci atlamada ya tünel ağ geçidini ya da ISS ağ geçidini gösterir; ikisi de aynı görünüyorsa işaret veya tablo kuralın söylediğini yapmıyordur. Test için yeni bağlantılar kullanın.

Sonra yeniden başlatın. Önyükleme sırası, çalışan bir politikanın bozulduğu yerdir, çünkü ulaşılamayan rota kurulmadan önce istemcinin ayakta olması gerekir ve eski kural kümesini geri yükleyen kayıtlı bir anlık görüntü tablonuzun üzerine yazar. Her kuralın kayıtlı yapılandırmada olduğunu ve işaretlenmiş varsayılanın önyüklemeden sonra var olduğunu, yalnızca siz yazdıktan sonra değil, kontrol edin.

Bir şey başarısız olursa önce işareti kaldırın ve normal trafiğin geri gelip gelmediğine bakın, sonra tabloyu kaldırın. Bu sıra, bir yönlendirme mi yoksa güvenlik duvarı sorunu mu kovaladığınızı söyler ve işi bitirirken evde çalışan bir yazıcı bırakır.