Genel, özel, statik ve özel tahsisli bağımsız adres özellikleridir. Yönlendirme, güvenlik duvarları, ileri DNS, ters DNS ve TLS'yi de kapsayan bir dağıtım haritası oluşturun ve her ayarı onu kontrol eden tarafla doğrulayın.
Adres özellikleri farklı soruları yanıtlar
Genel ve özel, bir adresin nereye yönlendirilmesinin amaçlandığını tanımlar. Statik ve dinamik, bir atamanın zaman içinde nasıl davrandığını tanımlar. Özel tahsisli ve paylaşılan, bir adresin bir hizmet içinde nasıl kullanıldığını veya tahsis edildiğini tanımlar. Bunlar ayrı özelliklerdir: kararlı bir genel adres birçok siteye hizmet edebilir ve özel bir adres kontrollü bir ağ içinde dinamik olarak atanabilir.
Her adresin dağıtımdaki rolünü yazın: genel giriş noktası, iç veritabanı, yönetim yolu veya giden bağlantı. Ardından onu kimin atadığını ve neyin değişebileceğini belirleyin. Bu, yapılandırma işinin özel tahsisli kalıcı olarak sabit anlamına gelir veya genel, hizmete erişilebilir anlamına gelir gibi bir varsayıma bağlı kalmasını önler. Erişilebilirlik ayrıca yönlendirmeye, güvenlik duvarlarına ve uygulamanın dinleyicisine bağlıdır.
Özel adresleme yine de yönlendirme ve erişim denetimi gerektirir
RFC 1918, özel ağlar için IPv4 aralıklarını 10.0.0.0/8, 172.16.0.0/12 ve 192.168.0.0/16 olarak ayırır. Adresleri küresel olarak benzersiz genel hedefler değildir. Bir ağ, giden bağlantılar için özel adresleri çevirebilir veya özel ağları açık rotalar üzerinden bağlayabilir. Çeviri arkasındaki bir gelen hizmeti kasıtlı bir yayımlama yöntemi gerektirir; tek başına bir DNS kaydını değiştirmek o rotayı oluşturmaz.
IPv6'ın bağlantı yerel adresleme ve küresel olarak yönlendirilebilir tek noktaya yayın adresleri dahil kendi adres türleri ve kapsamları vardır. Bir IPv4 güvenlik duvarı veya çeviri kuralının IPv6'yi kapsadığını varsaymak yerine onu ayrıca inceleyin. Özel bir adres bir kimlik doğrulama mekanizması değildir ve genel bir IPv6 adresi her hizmeti açığa çıkarmak için bir neden değildir. İlgili her ağdan erişimi test edin ve yönetimi uygun sınırda kısıtlayın.
Kararlı adlar ve kararlı adresler ilişkilidir
DHCP, adres yapılandırmasını bir protokol aracılığıyla tahsis eder ve kiralamalar kullanabilir. Dinamik olarak atanan bir adres bir süre değişmeden kalabilir; bu, kalıcılığını sözleşmesel bir garanti hâline getirmez. Bir uygulama kararlı bir adrese bağlı olduğunda, sağlayıcının atama ve değişiklik ilkesini dünkü bağlantıdan çıkarmak yerine doğrulayın.
Dinamik DNS, bir adres değiştikten sonra bir adı güncelleyebilir, ancak istemciler yine de önceki yanıtı önbelleğe alabilir. Ayrıca erişilemeyen bir dinleyicinin, eksik bir gelen rotanın veya operatör düzeyinde adres çevirisinin üstesinden gelemez. Ağ bağlantıya izin verdiğinde ve uygulama güncelleme gecikmelerine tolerans gösterdiğinde kullanın. Barındırılan bir dağıtım için, izin listeleri veya harici entegrasyonlar oluşturmadan önce amaçlanan adres yaşam döngüsünü belgeleyin.
| Özellik | Doğrulanacak şey | Yaygın yanlış varsayım |
|---|---|---|
| Genel veya özel | Yönlendirme kapsamı ve erişim yolu | Tek başına bir adres bir hizmeti erişilebilir kılar |
| Statik veya dinamik | Atama ve değişiklik ilkesi | Değişmeyen bir kiralama kalıcıdır |
| Özel tahsisli veya paylaşılan | Tahsis ve izin verilen kullanım | Özel tahsisli bir adres anonim kimlik sağlar |
| IPv4 veya IPv6 | Hem yönlendirme hem güvenlik duvarı yapılandırmaları | Bir protokolün ayarları diğerini kapsar |
İleri DNS ve ters DNS farklı sahiplere aittir
İleri DNS, adları A ve AAAA adres kayıtları gibi verilerle eşler. Ters DNS, bir adresi bir adla ilişkilendirmek için adresle ilgili bir ad alanı ve PTR kayıtları kullanır. İleri DNS bölgesini kontrol eden kuruluş, adres aralığı için ters DNS'ü kontrol eden kuruluş olmak zorunda değildir. Ters bir ad vaat etmeden önce doğru yapılandırma yolunu edinin.
Kaydı uygun çözümleyici aracılığıyla kontrol edin ve sonucu kaydedin. Bir ana bilgisayarı tanımlamaya yönelik bir PTR için, karşılık gelen ileri kaydın beklenen adrese işaret edip etmediğini de kontrol edin. Ters DNS, operasyonel tanımlamayı ve bazı posta sistemi kontrollerini destekleyebilir, ancak bir uygulamanın kimliğini doğrulamaz veya ileti teslimini garanti etmez. Posta gönderimi ayrıca kendi alan adı, itibar ve kimlik doğrulama incelemesini gerektirir.
Her HTTPS sitesi için özel bir adres gerekli değildir
HTTP ana bilgisayar yönlendirmesi ve TLS Sunucu Adı Belirtimi uzantısı, desteklenen istemcilerin ve sunucuların bir siteyi veya sertifikayı ada göre seçmesine olanak tanır. Bu nedenle birkaç HTTPS sitesi, alan adı başına bir genel adres gerektirmeden bir adres kullanabilir. Gerçek barındırma yapılandırması ve gerekli istemciler bu düzenlemenin uygun olup olmadığını belirler.
Ek bir adresi yalnızca belgelenmiş bir gereksinim, örneğin desteklenen bir ağ ayrımı veya farklı bir uç nokta bekleyen harici bir sistem gerektirdiğinde seçin. Bir adres, itibar sorunlarına karşı bağışıklık sağlamaz veya bir hizmeti işleten kişiyi tanımlamaz. Sertifikaları, ana bilgisayar adı yönlendirmesini ve adres tahsisini ayrı kontroller olarak tutun. Sunulan sertifikayı, kullanıcıların gerçekte ziyaret edeceği ana bilgisayar adı üzerinden doğrulayın.
Kayıtları değiştirmeden önce bir dağıtım haritası kullanın
Her ana bilgisayar adını, adres kaydını, dinleyiciyi, güvenlik duvarı yolunu ve sorumlu tarafı içeren küçük bir harita oluşturun. Yönetimi, yedeklemeleri ve tüm giden izin listelerini dahil edin. SwissOctet yapılandırmasının ihtiyacınız olan adres seçeneğini listeleyip listelemediğini kontrol edin ve ona güvenmeden önce ters DNS kontrolünü sorun. Katalog seçeneklerini hâlihazırda sağlanmış canlı bir atama olarak sunmayın.
Bir taşıma sırasında, kullanıcıları oraya yönlendirmeden önce hedef uygulamayı ve TLS ayarlarını hazırlayın. DNS önbelleklerini hesaba katın ve işleyen bir kurtarma yolu koruyun. İleri çözümlemeyi, gerçek uygulama erişilebilirliğini ve beklenen ters adı ayrı ayrı doğrulayın. Harita, hataları bulmayı kolaylaştırır çünkü yanlış bir kayıt, kapalı bir port ve uyuşmayan bir sertifika farklı sahiplere ait farklı sorunlardır.
Pratik kontrol listeniz.
- Adres rolünü, atamayı ve sahipliği haritalayın.
- IPv4 ve IPv6'i ayrı ayrı kontrol edin.
- DNS'a güvenmeden önce gelen yönlendirmeyi doğrulayın.
- PTR kayıtlarını kimin kontrol ettiğini belirleyin.
- Ana bilgisayar adını, sertifikayı ve uygulamayı birlikte test edin.
Önemli olan ayrıntılar.
Özel tahsisli bir IP bir hizmeti anonim yapar mı?+
Hayır. Bir kimlik veya gizlilik garantisi değil, bir tahsis veya kullanım düzenlemesini tanımlar. Hesaplar, trafik ve uygulama verilerinin ayrı sonuçları vardır.
Alan adımın DNS panelinden PTR kayıtlarını ayarlayabilir miyim?+
Yalnızca ilgili ters bölgeyi de kontrol ediyorsa. Adres sağlayıcısı genellikle o bölgeyi kontrol eder veya ayrı bir talep süreci sunar.
Her HTTPS alan adı kendi adresine ihtiyaç duyar mı?+
Gerekli değildir. Desteklenen istemciler ve sunucular ad tabanlı yönlendirme ve TLS SNI kullanabilir. Gerçek barındırma ve istemci gereksinimlerini doğrulayın.
Kaynağa gidin.
Bu kaynaklar, bu kılavuzdaki teknik kavramları destekler. Bir üretim sistemini değiştirmeden önce güncel belgeleri izleyin.
- RFC 1918: Özel İnternetler için Adres Tahsisi www.rfc-editor.org
- RFC 2131: Dinamik Ana Bilgisayar Yapılandırma Protokolü www.rfc-editor.org
- RFC 1035: DNS uygulaması ve belirtimi www.rfc-editor.org
- RFC 4291: IPv6 Adresleme Mimarisi www.rfc-editor.org
- RFC 6066: Sunucu Adı Belirtimi dahil TLS uzantıları www.rfc-editor.org
SwissOctet tarafından editoryal rehberlik. Örnekler açıklayıcıdır. Hizmet spesifikasyonları, mevcut seçenekler ve sözleşme koşulları ayrıca doğrulanmalıdır.