OpenVPN istemcilerini Cloudflare üzerinden yönlendirmek? Önce rolü denetleyin
Bir cihaz istemcisi yönlendirici değildir. Cloudflare rolünün diğer ana makinelerin paketlerini ilettiğini doğrulayın ve sunucunun kendi tünelini eski yolunda tutun.
Çalışan bir OpenVPN sunucunuz ve Cloudflare'in cihaz yazılımını da çalıştıran bir ana makineniz var ve bir sonraki apaçık adım istemci trafiğini oraya yönlendirmek gibi görünüyor. Bir makinedeki iki çalışan bağlantı bir aktarma geçidi oluşturmaz. Eksik olan, başkasına ait paketleri iletmek için belgelenmiş bir rol ve bu paketleri geldiklerinde sınıflandıran bir ilkedir.
Her kuraldan önce dört soru gelir: hangi trafik girer, sonra nereye gider, yanıtlar dönüş yolunu nasıl bulur ve o ikinci yol başarısız olduğunda tasarım ne yapar. İlk ikisi yetenek sorularıdır.
Tek ana makinedeki iki hizmet aktarma yolu değildir
Bir cihaz istemcisi, çalıştığı makinede doğan trafiği işlemek için yapılmıştır. Ad çözümlemesini veya seçili uygulama trafiğini yakalar ve kendi tünelinden gönderir; ilkesi o cihazın kullanıcısı ve o cihazın süreçleri için yazılmıştır. Bir OpenVPN istemcisinden iletilen paket yerel çıktı değildir, bu yüzden aynı kurallar onu sınıflandırmaz. Bu, daha geniş bir kuralla örtülebilecek bir yapılandırma ayrıntısı değildir, çünkü yazılımın paketi görüp görmeyeceğine bu karar verir.
Bu yüzden tasarım sorusu bir yetenek sorusudur. Ya kurulu ürünün diğer ağlar için trafik ileten belgelenmiş bir rolü vardır ya da aktarma işlevi tamamen başka bir yere aittir.
Cloudflare'in hangi rolü iletmeye izinlidir
Cloudflare'in cihaz istemcisi kapsamları farklı kipler sunar: yalnızca ad çözümlemesi, cihazdan gelen trafik ve bazen ikisi de. Bu kiplerin hiçbiri, başka bir tünelden gelen özel bir aralık için ana makineyi yönlendirici yapmaz. Özel yönlendirme rolü, kendi bağlayıcısı, kaydı ve ağ modeli olan ayrı bir üründür.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
Çevresinde yollar tasarlamadan önce kurulu rolü denetleyin. Bağlayıcının hangi arayüzü oluşturduğunu, belirli önekleri mi yoksa varsayılan bir yolu mu duyurduğunu ve yerel ilkenin ilet ilen paketler için de geçerli olup olmadığını okuyun. Yalnızca yerel trafik işleniyorsa, çeviri kuralı nasıl yazılırsa yazılsın OpenVPN sunucusu aktarma noktası olamaz.
Burada ayrıca genel çıkış gereksinimi kesin biçimde ifade edilmelidir. İletilen istemci trafiği için Cloudflare'in sağladığı çıkış belirli bir kullanım durumudur ve gerçekten sahip olduğunuz hizmete karşı doğrulanmalıdır.
Dış tüneli yeni yoldan bağımsız tutun
Yeni arayüze bir varsayılan yol eklediğiniz anda sunucunun kendi giden trafiği onun için yarışmaya başlar; buna OpenVPN istemcilerine verilen yanıtlar ve makineye SSH oturumunuz da dahildir. Olağan belirti, kurulup sonra ölen bir tünel veya değişiklik işe yaramış görünürken dışarıda kilitlenen bir yöneticidir. Uç nokta için ip route get çıktısını önce ve sonra karşılaştırın; sunucunun kendi taşımasını eski yerinde tutmak için ilke tabanlı yönlendirme veya bir ana makine yolu kullanın. Bu karşılaştırmayı makinenin kendisinden çalıştırın, çünkü sunucunun kendi yoluna ilişkin kendi görüşü önemli olandır.
Sunucunun genel adresi için bir istisna tek başına yeterli değildir, çünkü her uzak yöneticinin dönüş yolu farklı bir akıştır. Bu akışlardan hangilerinin değişikliği atlatması gerektiğine karar verin, sonra birincinin gerisini kapsadığını varsaymak yerine her birini doğrulayın.
İletmeyi ve çeviriyi tek bir akışla sınırlayın
Alınan paketler yerel çıktı yolunu değil iletme yolunu izler, bu yüzden önemli olan kural forward kancasında yaşar. Sonraki arayüzün çeviriye ihtiyacı olduğunda kaynağı istemci havuzuna, hedefi izin verilene ve çıkışı o tek arayüze sınırlayın. Yalnızca bir arayüze bağlı masquerade kuralı kendi başına yol seçmez ve başka hiçbir filtrenin ötesine iletmeye izin vermez.
Başarısızlıkta kapanma davranışını önceden kararlaştırın, sonra test edin. Sonraki yolu durdurun ve istemcilerin sessizce olağan üst bağlantıya dönmek yerine amaçlanan çıkışı kaybettiğini doğrulayın, çünkü trafik yanlış kapıdan çıkmaya başlayana kadar kimsenin fark etmediği sonuç budur. Ad çözümlemesi ve IPv6 için denetimi yineleyin, çünkü yalnızca v4 için bir kural kümesi v6 yolunu açık bırakır.
Vardığınız dört yanıtı ve her birini kanıtlayan gözlemi yazın. Anlatabildiğiniz bir aktarma yolu, bir sonraki olay incelemesinde savunabildiğiniz yoldur.