Bir LAN alt ağını OpenVPN üzerinden yönlendir ve varsayılanı koru

Bir LAN için yönlendirme yapan ve aynı zamanda VPN’e bağlanan kutular kendileriyle aynı tartışmaya düşer: tünel varsayılan rotaya sahip olmak ister, LAN’in ise onu geri alması gerekir. OpenVPN bağlandığında tünelden bir varsayılan rota veya bir çift yarım varsayılan rota kurabilir; bu bir dizüstü bilgisayar için doğru, komşuları LAN adresinden yanıt bekleyen bir ağ geçidi için yanlıştır. Cevap VPN’i atlamak değildir. Cevap, iki karara farklı tablolar vermektir.

Bir varsayılan rota, iki sahip

İletilen trafik ile yerelde oluşan trafik aynı yolu izlemek zorunda değildir. LAN istemcileri tünele yalnızca seçtiğiniz hedefler için ihtiyaç duyar, oysa ana makinenin kendi yönetim oturumları ve bu istemcilere verdiği yanıtlar LAN varsayılanına ihtiyaç duyar. İkisini ana tabloda karıştırmak, iki farklı soruya tek bir yanıt dayatır.

OpenVPN’de tam bunun için bir anahtar var. route-noexec istemcinin ana tabloya hiç dokunmasını engeller ve kullanacağı değerler bir route-up betiğine route_vpn_gateway, dev ve arayüz adresleri olarak aktarılır. Sonra hangi tablonun hangi rotayı alacağına siz karar verirsiniz, sonradan okuyabileceğiniz kodda.

Politika tablosu ile ana tabloyu yeniden yazmak

Ayrı tablo, bir alt ağın ötesine ölçeklenen tek seçenektir. Bir kez ad verin, sonra adıyla başvurun ki kimse bir sayı ezberlemek zorunda kalmasın:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Buradaki adresler yer tutucudur. Bir şey çalıştırmadan önce LAN önekini, tünel ağ geçidini ve aygıt adını kendi dağıtımınızdan değiştirin.

Kural ana makineyle de eşleşmelidir

Yalnızca LAN önekiyle eşleşen bir kural iletilen paketleri kapsar. Ağ geçidinin kendi ürettiği trafiği kapsamaz ve LAN istemcilerine geri gönderdiği, kaynak olarak ağ geçidinin LAN adresini taşıyan yanıtları da kapsamaz. Bu aramalar main’e düşer ve yine de tünelden çıkabilir.

Ağ geçidinin kendi LAN adresi için ikinci bir kural ekleyin veya ilk kuralı ikisini de içeren bir kümeye genişletin. Sıra önemlidir: daha özel kuralı öne koyun ve sonucu kaynağı açıkça adlandıran bir aramayla doğrulayın.

ip route get 203.0.113.9 from 192.168.50.1

Bu, yerel kalması gereken bir hedef için tünel aygıtını bildiriyorsa, tabloda ne olursa olsun kural kümesi yanlıştır.

NAT veya karşı tarafta bir rota

VPN sunucusu tünel alt ağını bilir, başka bir şey bilmez. LAN kaynak adresiyle gelen paketlerin, biri sağlamadıkça dönüş yolu yoktur ve bunu sağlamanın tam olarak iki yolu vardır. Sunucuda LAN öneki için rota eklemek, özgün kaynağı uçtan uca görünür tutar; denetlenmiş bir tasarımın genellikle istediği budur. Ağ geçidinde maskeleme, kaynağı tünel adresine yeniden yazar ve sunucudan hiçbir işbirliği gerektirmez.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Sunucuyu kontrol etmiyorsanız ve oraya rota ekleyemiyorsanız NAT seçin. Günlükler, erişim denetimi veya dönüş yolu simetrisi önemliyse sunucu tarafındaki rotayı seçin, çünkü maskeleme özgün adresi karşı tarafın kaydettiği her şeyden siler.

Her durumda iletim etkin olmalıdır ve katı ters yol filtresi, main o kaynak için tüneli seçmeyecekse yanıtı düşürebilir. Tüneli suçlamadan önce gerçek değeri kontrol edin.

Bölünmenin yeniden bağlanmadan sağ çıkmasını sağlayın

Elle eklenen kurallar ve rotalar arayüz yeniden oluşturulduğunda kaybolur ve eski bir tablo girdisi onu haklı çıkaran oturumdan daha uzun yaşayabilir. Tablo kuralını, tünel rotasını ve maskeleme girdisini istemcinin route-up betiğine koyun ve eski bir ağ geçidinin yeni oturuma taşınmaması için betiğin başında tabloyu boşaltın.

Her iki uçtan doğrulayın: ağ geçidinde LAN kaynağıyla bir arama ve bir LAN istemcisinden tünelden geçmesi gereken bir hedefe gerçek bir istek. Var olan ama hiç seçilmeyen bir rota, sayaçları okuyana kadar hiç rota yokmuş gibi davranır.