LAN yönlendiricisi ve VPN istemcisi: iki cihaz, iki yönlendirme tablosu

İki cihaz paketi iletir ve her biri kendi tablosunu tutar. LAN yönlendiricisi uzak önekin VPN istemcisine ait olduğunu bilir, VPN istemcisi de o öneke kendi tüneli üzerinden nasıl ulaşacağını bilir. Yalnızca ilk tabloyu yapılandırırsanız paket eşleşen rotası olmayan bir makineye ulaşır ve varsayılan rota üzerinden yeniden çıkar. Bütün arıza budur ve LAN tarafından bakıldığında bir yönlendirme döngüsü gibi görünür, çünkü neredeyse öyledir.

Bir rotaya dokunmadan önce iki atlamayı çizin

Örnek bir yerleşim alın: LAN ana bilgisayarları 192.168.50.0/24 üzerinde, sıradan yönlendirici 192.168.50.1 üzerinde, özel bir istemci 192.168.50.15 üzerinde ve yalnızca o istemcinin tuttuğu tünel üzerinden erişilebilen uzak bir LAN 10.60.0.0/24 üzerinde. İki özel aralıktan hiçbiri diğeriyle çakışmaz, ve tünelin kendi adres planı vardır.

İki özel aralık da önemlidir çünkü hangi cihazın yanıt verebileceğine onlar karar verir. Uzak taraf paketin istemcinin tünel adresinden geldiğini görür ve yanıtı 192.168.50.0/24 adresine geri dönecek bir yol bulmalıdır. Yalnızca giden yön yapılandırılmışsa istek çalışabilirken yanıt kaybolur.

Adım 1: yönlendiriciyi tünele değil, istemciye doğrultun

LAN yönlendiricisinde, sonraki atlaması istemcinin LAN adresi olan bir hedef rota ekleyin:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Bu kayıt “onu tünel kurabilen makineye teslim et” der. Tünelin nasıl kurulduğu hakkında hiçbir şey söylemez ve istemcinin kendi rotasının yerini tutmaz. Yönetilen bir yönlendiricide eşdeğeri cihazın statik rotalar sayfasında yaşar; bir Linux yönlendiricisinde rota, LAN'a sahip arayüzün yapılandırmasına aittir, kapatacağınız bir kabuğa değil.

İkinci komutun yanıtını kontrol edin. İstemciyi gateway, LAN arayüzünü device olarak bildiriyorsa ilk atlama doğrudur ve kalan iş diğer makinededir.

Adım 2: istemciye tünel tarafında kendi rotasını verin

İstemci artık 10.60.0.0/24 için bir paket alır ve kendi tablosuna bakar. Tünel yapılandırması o önek için bir rota kurduysa paket şifreli olarak devam eder. Kurmadıysa paket olağan varsayılanla eşleşir ve 192.168.50.1 adresine geri döner, o da onu yeniden istemciye gönderir.

Bir şey eklemeden önce bakın:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Her tabloda önek rotasının olmaması aradığınız bulgudur. Bunu tünelin kendi yapılandırması üzerinden ekleyin, böylece bir sonraki yeniden bağlanma onu yeniden kurar; elle yapılan ip route add oturumla birlikte kaybolur ve arızayı en elverişsiz anda geri getirir. Sonraki atlama tünel arayüzü ya da VPN'in eşi olarak atadığı adrestir, istemciye göre değişir, ve eş adresi eski bir nottan değil güncel profilden gelmelidir.

Döngü, oluştuğunda pratikte sonsuz değildir: TTL her geçişte düşer ve paket süre aşıldı mesajıyla ölür. Bu yüzden tekrarlanan bir traceroute bir döngü ima edebilirken, yalnızca iletmeyen bir istemci aynı paketi sessizce düşürür.

Adım 3: iletmeye izin verin ve dönüş yolunu seçin

Almak ve iletmek farklı izinlerdir. İstemcideki net.ipv4.ip_forward=1 çekirdek düzeyinde geçişe izin verir ve bir güvenlik duvarı kuralının bunu LAN arayüzü ile tünel arasında hâlâ izinlemesi gerekir. İstemcinin kendi yönetim sayfasına erişime izin veren bir kural, uzak LAN'a geçişe izin vermez ve aynı ana bilgisayar yerel olarak ping yanıtladığında bu ayrımı kaçırmak kolaydır.

Uzak tarafın ayna sorunu vardır. 192.168.50.0/24 adresinin bu kimliği doğrulanmış istemci üzerinden erişilebilir olduğunu bilmelidir. OpenVPN ile bu genellikle sunucu yapılandırmasının ittiği istemci başına bir rota ya da sunucudaki istemciye özel ve istemcinin arkasındaki LAN'ı bildiren bir dosya anlamına gelir. Bu olmadan uzak LAN ya yanıtı düşürür ya da kendi varsayılan ağ geçidine, yani internete gönderir.

Kaynak çevirisi, LAN öneki duyurulamadığında alternatiftir. İstemcide kapsamlı bir masquerade kuralı kaynağı tünel adresine yeniden yazar ve yanıtlar o zaman doğal olarak geri döner. Ayrıca hangi LAN ana bilgisayarının isteği yaptığını gizler ve tek başına uzak tarafın içeri doğru bağlantı başlatmasına izin vermez. Her şeyi kapsayan bir masquerade ekleyip yan etkiyi sonra keşfetmek yerine bu ödünleşimi bilerek seçin.

Adım 4: her iki kararı da kalıcı yapın, sonra gerçek yolu test edin

Her rotanın bir sahibi vardır ve sahibi, önyüklemede ya da yeniden bağlanmada yeniden üretilen yapılandırmadır. Yönlendiricide bu bir statik rota kaydı olabilir; istemcide VPN profili, NetworkManager ya da systemd-networkd olabilir. Tüneli yeniden bağlayıp istemciyi yeniden başlatarak doğrulayın, sonra değişikliğe güvenmek yerine tabloyu yeniden okuyun.

Tünelin dış bağlantısını taşıyan varsayılan rotayı bozulmadan bırakın. Kurulumu “basitleştirmek” için onu değiştirmek, herhangi bir iç trafik onu kullanmadan önce şifreli yolu kırar ve belirti, değişiklikten sonra bir daha asla kurulmayan bir tüneldir.

Sıradan bir LAN ana bilgisayarından test edin, istemciden değil, çünkü istemcide doğan bir istek yönlendiricinin ilk atlamasını asla kullanmaz. Yalnızca uzak LAN'da var olan bir hizmeti getirin ve yanıt gövdesini doğrulayın, sonra geçişin gerçekleştiğini görmek için istemcinin sayaçlarına veya günlüklerine bakın. Özel atlamalar gösteren iç traceroute iletmeyi kanıtlar, şifrelemeyi değil: dış yol ayrı bir gözlemdir ve yalnızca tünelin kendi arayüz sayaçları ondan neyin çıktığını gösterir.