İstemciniz UDP'ye ayarlı, Nginx sunucusunda VPN bağlantı noktasına işaret eden bir location bloğu var ve hiçbir şey gelmiyor. Bu beklenen bir durum: bir HTTP location UDP veri birimini taşıyamaz, ön uç ne diye adlandırılırsa adlandırılsın. Nginx'in bunun için bir stream dinleyicisine ihtiyacı var ve yapılandırmayı oraya taşıdığınızda oturumun hayatta kalıp kalmayacağına ikinci bir ayrıntı kümesi karar verir.

Proxy katmanı adresten önce gelir

Nginx'in stream modülü HTTP'yi ayrıştırmadan TCP ve UDP'yi proxy'ler. HTTP modülü bir istek satırı, başlıklar ve bir yanıt bekler; bunların hiçbiri yerel bir OpenVPN veri biriminde yoktur. Bu nedenle katman seçimi ilk karardır ve dinleyicinin IPv4 mü IPv6 mı olduğundan bağımsızdır.

TCP OpenVPN ile çalışıyor görünen bir yapılandırma UDP durumu hakkında hiçbir şey söylemez. Taşıma burada protokolün parçasıdır, dağıtımın ayrıntısı değildir.

Dinleyici ve backend

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

Herhangi bir şeyi düzenlemeden önce derlemenin stream modülünü içerdiğini doğrulayın; bir dağıtım paketi onu ayrı bir modüle bölebilir ve eksik modül tünel yerine yapılandırma hatası üretir. Bloğu ana yapılandırma bağlamına koyun, http içine değil, ve belge adresini gerçek backend ile değiştirin.

Hem iki yol hem de iki güvenlik duvarı veri birimlerine izin vermelidir: dinleyiciye giden yol ve proxy'den backend'e giden yol. IPv6 dinleyicisi de IPv4 yolu oluşturmaz, bu nedenle bazı istemciler hâlâ IPv4 kullanıyorsa o dinleyici kendi testine sahip ayrı bir girdidir. Backend'in kendi güvenlik duvarını proxy'nin adresinden kontrol edin, dizüstü bilgisayarınızdan değil.

Oturum zaman aşımları istek zaman aşımları değildir

Stream proxy'si bir UDP oturumu için durum tutar ve bunu zaman aşımı ile yanıt ayarlarına göre atar. Bir DNS aktarıcısından kopyalanan kısa zaman aşımı, saatlerce veri birimi alışverişi yapmayı bekleyen bir VPN'e kötü uyar ve arıza, başlamayı reddeden bir bağlantı değil sessizce ölen bir bağlantı olarak görünür.

Dağıtımın etkin proxy_timeout değerini ve varsa yanıt sayısı ayarını okuyun, sonra bunları VPN'in gerçekte kullandığı keepalive davranışıyla karşılaştırın. Farklı insanların farklı dosyalara yazdığı iki sayı çalışan bir sistemin normal durumudur. Hiç karşılaştırılmamış iki sayı aralıklarla aksayan bir sistemin normal durumudur. Karşılaştırma bir kez, gün ışığında olsun diye ikisini de servis kaydına yazın.

Aktarım neyi değiştirir, neyi değiştirmez

Stream proxy'si OpenVPN'in TLS denetim kanalını sonlandırmaz ve onu HTTPS'e dönüştürmez. Backend VPN hizmeti olarak kalır ve sertifika ilişkisi istemci ile o hizmet arasında kalır. Amaçlanan backend kimliğini korumak hâlâ istemcinin ve sunucunun işidir.

Sıradan proxy'leme, backend'in gördüğü kaynak adresini de değiştirir. Günlükler proxy'yi gösterecek ve VPN sunucusundaki IP tabanlı her erişim kuralı istemcinin adresi yerine o adresi değerlendirecektir. Kaynağın saydam şekilde korunması ayrı bir yönlendirme ve yetki tasarımıdır, dinleyiciye udp eklemekten doğan bir şey değildir. İstemci adresine bağlı bir politika yazılmadan önce bunu planlayın.

Bağlantı noktasından değil, istemciden doğrulayın

UDP bağlantı noktasının açık olduğuna dair yerel bir kontrol dinleyicinin var olduğunu kanıtlar. Bir istemcinin bunun üzerinden kimlik doğrulayabildiğini veya trafik alışverişine devam edebildiğini kanıtlamaz. Onaylı bir istemciden gerçek bir bağlantı tamamlayın, sonra oturumun anlamlı olacak kadar uzun süre ayakta kaldığını doğrulayın.

Biri Nginx'in UDP yapamadığını, çünkü basit bir aktarım aracının onun yerine çalıştığını bildirdiğinde, bu iki olgu birbiriyle ilişkili değildir. Araç backend'in yanıt verdiğini kanıtladı; ön ucun neyi desteklediği hakkında hiçbir şey söylemedi. İkisi de doğru olabilir ve yalnızca biri bu dağıtım için bir yapılandırmadır.

İlgili makaleler