Nmap'in ham taraması VPN üzerinden başarısız oluyor ama -sT bağlantısı çalışıyor?

Sayfa tünelden yüklenirken bağlantı noktası taraması ana makinenin kapalı olduğunu bildirir ve ilk düşünce VPN'in bir şeyi engellediğidir. Genellikle yeni bir şeyi engellemez. İki test işletim sisteminden farklı yetenekler ister ve yalnızca biri ham paket erişimine ihtiyaç duyar. Tünele dokunmadan hangi yeteneğin başarısız olduğunu belirleyin.

Yeteneği tünelden ayırın

Sıradan bir uygulama çekirdekten TCP bağlantısı açmasını ister ve çekirdek el sıkışmayı özel ayrıcalık olmadan yapar. Ham tarama paketleri kendisi kurar, bu da platforma göre ham soket veya yakalama sürücüsü gerektirir. Bunlar izin ve sürücü sorularıdır ve VPN bağlı olsun olmasın vardır.

Bu fark olağan asimetriyi açıklar. curl başarılıdır çünkü soket yolu çalışır, SYN taraması ise başarısız olur çünkü süreç tünel arabiriminde ham soket açamaz. Ters durumu da açıklar: yol sondayı düşürdüğü için ham tarama filtrelenmiş bildirir, uygulama yolu ise iyi kalır.

Sonuçların hiçbiri uzak hizmeti tanımlamaz. İkisi de tek bir yöntem altında tek bir yolu tanımlar, bu yüzden yöntemi sonuca bağlı tutun.

Bağlantı denetimini tek bir onaylı ana makinede çalıştırın

Görevinizin kapsadığı tek ana makineyi seçin, ardından ham erişim gerektirmeyen kipi kullanın. Buradaki örnek hedef 198.51.100.24, bu tür bir örnek için ayrılmış belge alanıdır.

Tek satır, tek ana makine, tek bağlantı noktası, keşif aşaması yok:

nmap -sT -Pn -p 443 --unprivileged 198.51.100.24

-sT tam TCP bağlantısı seçer, böylece uygulamanın kullandığı aynı çekirdek yolunu izler ve yakalama sürücüsü gerektirmez. -Pn ana makine keşifini atlar; nmap yine de yerel segmentteki hedefler için bağlantı katmanı çözümlemesi yapar, bu yüzden bayrak sıfır ön trafik vaadi değildir. --unprivileged nmap'a ham veya dinleme hakları olmadığını varsaymasını söyler, bu yöntemi değiştirir ve hiçbir şey vermez.

Her bayrağı tek bir değişiklik olarak okuyun, onarım olarak değil

Her seçeneği yöntem hakkında bir ifade olarak ele alın. -sT, -Pn veya --unprivileged hiçbiri rota eklemez, uzak güvenlik duvarı açmaz veya sertifika doğrulamaz. Bağlantı taraması ayrıca hizmetin kaydettiği gerçek el sıkışmayı tamamlar, bu yüzden onaylı denetim ile onaysız tarama sunucudan bakıldığında kapsam ve hız dışında aynı görünür. Çıktı değişene kadar seçenek yığmak, yöntem sorununun ağ bulgusu olarak kaydedilme biçimidir.

Çıktı kapalı dediğinde bir şey sıfırlama ile yanıt verdi ve bu sessizlikten farklı bir bulgudur. Çıktı filtrelenmiş dediğinde bir aygıt sondayı veya yanıtını düşürdü ve VPN ilgisiz olabilir. Tam ifadeyi yazın, çünkü keşif aşaması kararı ile sonda düzeyi arızası farklı katmanlara işaret eder.

Ayrıcalıklı kip gerçekten gerekliyse, ayrıcalığın, sürücünün ve arabirim düzeninin desteklenip desteklenmediğine platform sahibi karar verir. Aynı çağrıyı yükseltmek yöntemini değiştirmez.

Taşıma sonucunda durun, sonra hizmeti sınayın

Tamamlanmış el sıkışma tek bir adres, bağlantı noktası, kaynak ve an hakkında tek bir soruyu yanıtlar. Arka ucun sağlıklı olduğunu kanıtlamaz, çünkü yük dengeleyici veya ön proxy bağlantıyı kabul edebilirken arkasındaki uygulama durmuş olabilir.

Hizmetin kendi istemcisiyle devam edin, böylece TLS kimliği ve uygulama davranışı ayrı olgular olarak gözlemlenir:

openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health

Bir alışkanlık daha sonucu kullanışlı tutar. Tam komutu, kullanılan kaynak adresi ve zamanı yazın, çünkü bu bağlam olmadan taşıma sonucu yeniden üretilemez veya karşılaştırılamaz.

Sertifika beklemediğiniz bir ana makine adlandırıyorsa taşıma çalıştı ve yönlendirme hiç sorun değildi; arıza sanal barındırmada veya DNS'te. El sıkışma başarısız olursa tünel hakkında genelleme yapmak yerine yerel hata dizgesini yazın. Kapsam notunu sonucun yanında tutun, çünkü sıradaki kişi hangi yöntemin bunu ürettiğini bilmelidir.