Bir webpack geliştirme sunucusu VPN adresinde nasıl sunulur

Bağlama adresini geliştirme sunucusuna kimin erişmesi gerektiğine göre seçin, ardından ana bilgisayar adı denetimini sınırlayın ve hem sayfanın hem de canlı yeniden yükleme soketinin bağlandığını doğrulayın.

Yalnızca dizüstü bilgisayarda yanıt veren ve başka hiçbir yerde yanıt vermeyen bir geliştirme sunucusu genellikle yanlış adrese bağlanmıştır. Bağlantıyı kabul eden ama sayfayı reddeden bir sunucu genellikle bir ana bilgisayar adı denetiminde başarısız olur. Bunlar farklı düzeltmeleri olan farklı arızalardır ve doğru yapılandırmayı seçmek, çalışma alanına kimin erişmesi gerektiğine ve nasıl geldiğine bağlıdır.

Üç soru yanıtı belirler: kim bağlanıyor, hangi adrese ulaşabiliyor ve canlı yeniden yükleme onun için çalışmalı mı.

Yapılandırma dosyasından değil, soketten başlayın

Çalışan sürecin gerçekte neye bağlandığını, onu başlatan aynı ağ bağlamı içinde okuyun, çünkü bir kapsayıcı veya ad alanı, ana makine kabuğunun göremediği bir sokete sahip olabilir. Dinleme sütunu ilk soruyu yanıtlar: yalnızca yerel yol, belirli bir arabirim veya tüm arabirimler.

ss -ltn '( sport = :8080 )'
ss -ltnp | grep node

Geri döngü adresi güvenli varsayılandır ve uzak bir istemci için işe yaramaz. Joker karakterli bağlama kullanışlıdır ve bağlantı noktasını rotası olan her arabirimde açığa çıkarır; bu, aynı zamanda tünel taşıyan bir makinede çoğu insanın amaçladığından daha geniştir. Belirli bir adres orta seçenektir ve yalnızca soket oluşturulduğu anda arabirim o adrese sahipse çalışır. Ayrım önemlidir çünkü bu üç bağlamadan ikisi tarayıcıda aynı görünür ve ikinci bir arabirim olduğunda tamamen farklı davranır.

Rotalara veya güvenlik duvarı kurallarına dokunmadan önce bu gözleme uyun. Süreç yanlış adreste dinliyorsa, hiçbir ilke yönlendirmesi istemciyi oraya ulaştıramaz.

Bağlama adresini ona kimin ulaşması gerektiğine göre seçin

Bu makinede yalnızca sizin sayfaya ihtiyacınız varsa geri döngü bağlamasını koruyun ve durun. Aynı tüneldeki bir iş arkadaşınızın ihtiyacı varsa tünel arabiriminin adresini bağlayın ve güvenlik duvarının yalnızca o kaynağa izin vermesini sağlayın. Geliştirme sunucusunu onu etkin biçimde test edenlerin ötesinde yayımlamak sonunda çalışma alanını internete açan bir alışkanlıktır.

Bir kapsayıcının içindeki tarayıcının sunucuya ulaşması gerekiyorsa, bağlama adresi kapsayıcının ağının yönlendirebildiği bir adres olmalıdır ve bu genellikle ana makinenin kendisi için çözdüğü adres değildir. Yapılandırmayı düzenlemeden önce duruma karar verin, çünkü üç durum üç farklı değer üretir ve yalnızca biri doğrudur. Burada tahmin etmek kurulumun diğer herhangi bir bölümünden daha çok zaman kaybettirir.

Ardından adresi başlatıcınızın gerçekten okuduğu biçimde ayarlayın. Bir yapılandırma dosyası ile sunucuyu programlı olarak kuran bir betik aynı seçenekleri tüketmez:

devServer: {
  host: "10.77.0.20",
  port: 8080,
  allowedHosts: ["dev.corp.example"],
}

O parçadaki adres örnektir ve ana makinenin sahip olduğu VPN adresini temsil eder. Proje sunucuyu new WebpackDevServer(options, compiler) ile kuruyorsa seçenekleri bunun yerine kurucu bağımsız değişkeni üzerinden geçirin, çünkü webpack yapılandırmasındaki ayrı devServer özelliği o yolda dikkate alınmaz. Yapılandırma dosyası ile Node API arasındaki bu fark, parçayı hiç okumayan bir projeye kopyalayanları yakalar. dev-server belgeleri iki başlatma stilini ayırır ve kullanılan sürümle karşılaştırılması gereken referanstır.

Ana bilgisayar adı denetimini onayladığınız adlarla eşleştirin

Ana bilgisayar adı denetimi, bir saldırganın denetlediği bir addan sunulan sayfanın tarayıcı üzerinden geliştirme sunucunuzla konuşmasını engellemek için vardır. Bunu allowedHosts: "all" ile devre dışı bırakmak bu korumayı kaldırır ve rahatlık, iç hizmetlere ulaşabilen bir makinede nadiren buna değer. Tarayıcının hangi adları göndereceğini bildiğinizde denetimi doğru biçimde karşılamak ucuzdur.

Kullanacağınız tam adları, tünel adresine çözümlenen özel ad dahil olmak üzere listeleyin. İstemci bir adı bağladığınız adresten farklı bir adrese çözümlüyorsa, sunucu yapılandırması değil ad çözümleme sorununuz var ve adı izin listesine eklemek bunu düzeltmez. Çözümlemeyi sunucudan değil istemciden doğrulayın.

Üç denetimi kafanızda ayrı tutun: bağlama adresi hangi arabirimlerin bağlantıyı kabul ettiğine, izin listesi hangi Host başlıklarının kabul edildiğine, kimlik doğrulama ise kimin içeri alındığına karar verir. Yalnızca üçüncüsü erişim denetimidir ve bir geliştirme sunucusunda genellikle hiçbiri yoktur. Tünel adresi de bir kimlik doğrulama mekanizması değildir, çünkü oraya yönlendirme yapabilen herkes güvendiğiniz sınırın zaten içindedir.

Sayfayı ve canlı yeniden yükleme soketini birlikte doğrulayın

Amaçlanan istemciden yapılandırılmış şemayla taze bir istek yükleyin ve önbelleği değil sonucu okuyun. HTTPS için beklenen ana bilgisayar adını ve sertifika doğrulamasını koruyun, çünkü tarayıcı uyarısı başarılı bir kabul testi değildir. Canlı yeniden yükleme sessizce başarısız olurken sayfanın görüntülenmesi burada en yaygın kısmi başarıdır ve hızlı bir kontrolde gözden kaçması kolaydır.

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" http://dev.corp.example:8080/
curl -sS -i http://10.77.0.20:8080/ | head -n 5

Ardından tarayıcının ağ tanılamasını açın ve WebSocket bağlantısını izleyin. Bir sayfa bir ana bilgisayar adı, bağlantı noktası ve şema üzerinden yüklenirken yeniden yükleme soketi başka birini kullanabilir, bu yüzden ikisi ayrı ayrı denetlenmelidir. Belgelenmiş istemci URL'sini yalnızca dağıtılan yol gerçekten farklı bir değer gerektirdiğinde yapılandırın ve istemciye bir geçici çözüm öğretmek yerine yolu düzeltmeyi tercih edin.

Dinleyici adresini, kabul edilen adı, izin verilen kaynağı ve her iki sonucu proje notlarına kaydedin. Bu kayıt, çalışma alanını başlatıp sayfanın neden yüklendiğini ama hiç yenilenmediğini merak eden bir sonraki kişiye kalır.

İlgili makaleler