Sunucuyu yeniden başlattınız ve site açılmıyor. ip a komutunu çalıştırıyorsunuz ve dün ip addr add ile ayağa kaldırdığınız ek IP kaybolmuş. Ya da daha kötüsü: IP yerinde duruyor, ping yanıt veriyor, ancak tarayıcı o alan adında SSL_ERROR_NO_CYPHER_OVERLAP veya NET::ERR_CERT_COMMON_NAME_INVALID hatası veriyor. Bu iki sorunun ortak bir kökeni var: Ek IP, ağ kartı üzerinde sadece bir adres değil, birkaç katmanda kaydedilmesi gereken bir varlıktır.
Bu metinde tüm yolu kat edeceğiz: Ek IP'yi kalıcı olarak ayağa kaldırmaktan, servisi ona bind etmeye, SSL sertifikasına ve e-posta kayıtlarına kadar. Odak Linux üzerinde çünkü neredeyse tüm web sunucuları burada bulunuyor.
Ek IP'yi yeniden başlatmadan sonra da kalacak şekilde ayağa kaldırın
Çoğu kişinin yaptığı ilk şey şudur:
ip addr add 203.0.113.45/29 dev eth0Bu komut çalışır ve IP anında yanıt verir. Ancak geçicidir. İlk reboot ile veya ağ servisi yeniden başlatıldığında bile silinir ve tekrar aynı hatanın arkasında kalırsınız. Ubuntu'da netplan ile çalışıyorsanız, bloğu YAML dosyasına yazmalısınız:
network:
version: 2
ethernets:
eth0:
addresses:
- 203.0.113.44/29
- 203.0.113.45/29
routes:
- to: default
via: 203.0.113.41RHEL, AlmaLinux ve Rocky'de /etc/sysconfig/network-scripts/ifcfg-eth0 dosyasını IPADDR1=203.0.113.45 ve PREFIX1=29 ile düzenlersiniz. Saf Debian'da /etc/network/interfaces içindeki iface eth0 inet static bloğunu tekrarlarsınız. Dağıtımlar arasındaki fark burada gerçektir ve yanlış tahmin ederseniz, yeniden başlatmadan sonra sunucuyu kaybedersiniz; ağ dosyasına dokunmadan önce Linux sunucu dağıtımı seçimi yazısına bir göz atın.
Veri merkezinde farklılaşan nokta
Sağlayıcıdan aldığınız ek IP genellikle aynı ana alt ağdadır, bu nedenle ayrı bir gateway'e ihtiyaç duymaz. Ancak farklı bir alt ağdaysa (örneğin başka bir VLAN üzerinde ayrı bir /29), belirli bir route eklemelisiniz, aksi halde paketler sunucudan çıkar ve geri dönmez. Belirtisi şudur: sunucunun kendisinden ping 8.8.8.8 yanıt verir ama dışarıdan kimse yeni IP'ye ulaşamaz. Bunu sunucuda tcpdump -i eth0 icmp ile kontrol edin: gelen paket görüyorsanız ama giden yoksa, sorun güvenlik duvarı değil route'tur.
Ek IP'yi web sunucusuna bağlama
Artık IP kalıcı olduğuna göre, servisin onu dinlemesi gerekir. Nginx'iniz varsa ve yapılandırmayı listen 80; üzerine koyduysanız, Nginx tüm adresleri dinler ve ek IP de otomatik olarak hizmet verir. Bu varsayılan davranıştır ve çoğu site için doğrudur. Ancak ek IP'nin yalnızca belirli bir siteye hizmet etmesini istediğinizde, açıkça yazmalısınız:
server {
listen 203.0.113.45:443 ssl;
server_name shop.example.com;
ssl_certificate /etc/letsencrypt/live/shop.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/shop.example.com/privkey.pem;
}Apache biraz farklıdır. Orada ports.conf içine Listen 203.0.113.45:443 eklersiniz ve ardından VirtualHost'ta <VirtualHost 203.0.113.45:443> ile ona işaret edersiniz. Bu satırı atlarsanız, Apache yeni IP'de hiçbir yanıt vermez ve logda hiçbir şey görmezsiniz, çünkü o sokete hiç bind edilmemiştir. Her servisin hangi portta ve hangi adreste oturduğunu bulmak için Yaygın servis portları referansı iyi bir başlangıç noktasıdır.
Burada hata yapıyorlar
Sıkça gördüğüm yaygın hata: Kişi ek IP'yi ayağa kaldırır, siteyi ona ayarlar, her şey çalışır ve birkaç saat sonra kullanıcılar "site mobilde açılmıyor ama şirket Wi-Fi'sinde açılıyor" diye bildirir. Nedeni genellikle ek IP'nin güvenlik duvarında açılmamış olmasıdır. ufw status komutunu çalıştırın; eğer yalnızca 443 portu ana IP'de allow edilmişse, yeni IP üzerindeki trafik drop edilir ve kullanıcı açısından net bir hata değil, sessiz bir timeout olarak görünür. Adres belirtmeden ufw allow 443/tcp komutu tüm IP'leri kapsar. Ham iptables ile çalışıyorsanız, zincirlerin tam sözdizimi için Linux güvenlik duvarı komutları yazısına bakın.
Ek IP üzerinde SSL sertifikası: SNI'nin sürpriz yaptığı yer
İşte birçok kişinin takıldığı nokta burasıdır. SSL sertifikası IP'ye değil, alan adına bağlanır. Dolayısıyla ek IP aldığınızda, alan adının A kaydının yeni IP'ye işaret ettiğinden emin olmalı ve sonra sertifika almalısınız. Certbot ile çalışıyorsanız:
certbot certonly --webroot -w /var/www/shop -d shop.example.comCertbot, vermeden önce alan adına bir challenge dosyası koyar ve onu dışarıdan okur. DNS hâlâ eski IP'ye işaret ediyorsa, challenge başarısız olur ve Timeout during connect mesajı alırsınız. Daha hızlı yayılması için başlamadan önce A kaydının TTL'sini 300 saniyeye düşürün.
Daha önemli nokta: Bir IP üzerinde farklı sertifikalarla birden fazla alan adına hizmet veriyorsanız, SNI'ye bağımlısınız. SNI göndermeyen eski istemciler, o IP'deki ilk sertifikayı görür ve alan adı hatası alır. Temiz çözüm, her hassas alan adının kendi özel IP'sine sahip olmasıdır. Burada paylaşımlı ve özel IP arasındaki seçim gerçektir: Normal siteler için paylaşımlı IP yeterlidir ve daha az maliyet ve yönetim gerektirir, ancak kurumsal müşteriniz varsa veya ödeme ve işlemsel e-posta gibi servisler sunuyorsanız, özel IP'yi seçin. Bulut altyapısında bu yükü ayırmak daha kolaydır; bulut sunucu IP'yi makineden ayrı yönetmenize izin verir ve taşınma sırasında yeniden yapılandırmanız gerekmez.
Ek IP ve e-posta: SPF kaydını unutmayın
Ek IP'yi e-posta göndermek için kullanıyorsanız, sadece ayağa kaldırmak yeterli değildir. Alan adının SPF kaydına kaydedilmelidir, aksi halde alıcılar e-postanızı sahte olarak görür ve spam'e düşer:
example.com. IN TXT "v=spf1 ip4:203.0.113.44 ip4:203.0.113.45 -all"DKIM kullanıyorsanız, imza anahtarı da yeni IP'den gönderen aynı alan adında ayarlanmalıdır. Yaygın bir hata: Ek IP'yi gönderim için ayarlarsınız ama rDNS'sini yapılandırmazsınız. Çoğu sağlayıcı PTR'yi panelden ayarlamanıza izin verir; bunu yapmazsanız, Gmail e-postanızı "bu gönderici doğrulanmamış" uyarısıyla gösterir. PTR, HELO'da bildirdiğiniz aynı alan adına işaret etmelidir.
Her şeyin doğru oturduğundan nasıl emin olursunuz
Bitti demeden önce, bu kontrol listesini sunucunun kendisinden değil, dışarıdan çalıştırın:
- Başka bir makineden
ping 203.0.113.45. Yanıt vermezse, sorun route veya upstream güvenlik duvarıdır. curl -I --resolve shop.example.com:443:203.0.113.45 https://shop.example.comile web sunucusunun aynı IP'de yanıt verdiğinden emin olun.openssl s_client -connect 203.0.113.45:443 -servername shop.example.comile doğru sertifikayı görün.- SPF'yi doğrulamak için
dig +short TXT example.com.
Ve son olarak, sunucuyu bir kez yeniden başlatın. Şimdi, trafiğin az olduğu gece değil. IP yeniden başlatmadan sonra geri gelmezse, bunu yarın sabah müşteri aradığında değil, şimdi öğrenmek daha iyidir. Otomatik olarak ayağa kalkması gereken servisler için, ilgili unit'in enabled olduğundan emin olun; systemd'de unit dosyası hangi bölümün bağımlılık ve otomatik yeniden başlatmadan sorumlu olduğunu açıklar. Yeniden başlatmadan sonra servis ayağa kalkmazsa ve nedenini anlamazsanız, hangi dosyayı açacağınızı bilmek için Linux log konumları yazısına bakın.
Paylaşımlı hostingdeyseniz ve özel IP'ye ihtiyacınız varsa, bu işlem yönetim panelinden yapılır ve root erişimi gerekmez; Linux hosting özel IP seçeneğini aynı panelde sunar. Ancak özel sunucuda, yukarıdaki tüm adımlar sizin sorumluluğunuzdadır.
Sıkça sorulan sorular
Ek IP neden yeniden başlatmadan sonra kaybolur?
Çünkü ip addr add komutuyla yalnızca kernel belleğine kaydedilir ve hiçbir yapılandırma dosyasına yazılmaz. İşletim sistemi önyükleme sırasında yalnızca netplan, ifcfg veya interfaces içinde yazılı olanı ayağa kaldırır. Kalıcı olması için aynı IP'yi dağıtımın yapılandırma dosyasına eklemelisiniz.
Ek IP için ayrı bir SSL sertifikasına ihtiyacım var mı?
Hayır, sertifika IP'ye değil alan adına bağlanır. Alan adınız A kaydıyla yeni IP'ye işaret ediyorsa, aynı sertifika çalışır. Yalnızca web sunucusunun o IP'de dinlediğinden ve güvenlik duvarının 443 portunu açık bıraktığından emin olmalısınız.
Ek IP'nin gerçekten dışarıdan erişilebilir olduğunu nasıl anlarım?
Başka bir sunucudan veya çevrimiçi bir servisten, aynı IP'ye ping ve ardından curl çalıştırın. Sunucunun kendisinden yanıt alıyorsanız ama dışarıdan alamıyorsanız, sorun neredeyse her zaman route veya güvenlik duvarıdır, web sunucusu yapılandırması değil.
E-posta için sadece ek IP'yi ayarlamak yeterli mi?
Hayır. SPF kaydını yeni ip4: ile güncellemeli, rDNS'yi sağlayıcı panelinden ayarlamalı ve DKIM'iniz varsa anahtarı aynı gönderen alan adında tutmalısınız. rDNS olmadan, çoğu büyük e-posta servisi mesajınızı şüpheli görür.