Her Nodetonet tüneli varsayılan olarak kullanıcı adı ve şifre kimlik doğrulamasıyla gelir. Çoğu durumda bu yeterlidir, ama kimlik bilgileri sadece byte'tır — bilerek ya da bilmeyerek paylaştığınız herkes sizinle aynı erişimi alır. Bir proxy URL'sini yanlışlıkla herkese açık bir Gist'e yapıştırın, sürüm kontrolüne commit edin ya da bir hata logundan sızdırın; anahtarlar artık herkesin elindedir.
Defence-in-depth yanıtı bir tünel başına kaynak-IP güvenlik duvarıdır. Nodetonet'e hangi istemci IP'lerin belirli bir proxy'ye bağlanabileceğini söylersiniz; geri kalan herkes auth anlaşması başlamadan TCP seviyesinde düşürülür. Doğru kimlik bilgileriyle bile yanlış IP'den gelen bir bağlantı hiçbir şey alamaz — parmak izi çıkarmaya değer bir hata mesajı bile göremiyor.
Allow-list mi deny-list mi: hangi modu seçmeli
Proxy başına yapılandırılan iki tamamlayıcı mod vardır:
| Mod | Kimler bağlanır | En iyi kullanım | Yanlış yapılandırma riski |
|---|---|---|---|
| Allow-list | Yalnızca listedeki IP'ler; geri kalanı düşürülür | Sabit-IP ofisler, CI runner'lar, stabil egress'li cloud fonksiyonları | Kendi IP'niz eksikse kendinizi kilitlersiniz |
| Deny-list | Listelenenler hariç herkes | Bilinen bir istismarcıyı veya tek bir aralığı engellerken tüneli açık tutmak | Saldırgan listedeki olmayan bir IP'ye geçer ve bloğu aşar |
| Kapalı | Tüm IP'ler (yalnızca kimlik bilgisi) | Geliştirme, dinamik residential istemciler veya IP'lerin öngörülmediği durumlar | Kimlik bilgisi sızıntısı = kısıtsız erişim |
Proxy başına bir mod seçersiniz, ikisi birden değil. Boş bir allow-list "herkesi engelle" anlamına gelir — tünel ele geçirilirse hızlı bir kill switch işlevi görür. Boş bir deny-list ise Kapalı modla aynıdır.
İstemci trafiğiniz dinamik bir ev IP'sinden veya bir CGNAT mobil ağından geliyorsa allow-list çözdüğünden fazla sorun çıkarır. Bu durumda tünelinizi sabit bir egress sağlayan bir VPN veya cloud bastion ile eşleştirin, ardından o egress adresini allow-list'e ekleyin.
Panelde ayar nerede bulunur
Kilitlemek istediğiniz proxy'yi /proxies'den açın, Settings'e tıklayın, ardından IP Restrictions sekmesine geçin. Görecekleriniz:
- Mod için bir açılır liste — Kapalı, Allow veya Deny.
- Satır başına bir girdi olacak şekilde girdi için bir textarea.
Save'e basın ve yeni kurallar birkaç saniye içinde devreye girer. Mevcut bağlantılar kesilmez — yalnızca yeni el sıkışmalar kurallara göre değerlendirilir. Yani kendinizi yanlışlıkla kilitlerseniz, devam eden bir scrape işlemi bir isteği bitirip yeniden bağlanmaya çalışana kadar çalışmaya devam eder. O pencereyi kullanarak girdiyi düzeltin ve tekrar kaydedin.
Giriş formatları: tek IP, CIDR ve IPv6
Her satır ya tek bir adres ya da bir CIDR aralığı, IPv4 veya IPv6:
# tek adresler
203.0.113.7
2001:db8::1
# CIDR aralıkları
198.51.100.0/24 # bütün bir /24 alt ağı
10.0.0.0/8 # özel VPN egress'iniz
2001:db8::/32 # IPv6 prefixBir # sonrasındaki yorumlar sıyrılır. Boş satırlar yok sayılır. Hostname kabul edilmez — panel bunları açık bir hata ile reddeder. TCP-kabul zamanında reverse DNS yavaş, taklit edilebilir ve güvenilmezdir, bu yüzden açık IP'ler gerekir. Mevcut egress IP'nizden emin değilseniz, ücretsiz IP adresim nedir aracımız bir sunucunun bağlantınızdan tam olarak ne okuduğunu gösterir.
Engellenen bağlantı nasıl görünür
Engellenen bir kaynak TCP bağlantısının başarılı olduğunu görür ama proxy müzakeresi hiç başlamaz — sunucu kabul eder ve hemen kapatır. curl'den bu şöyle görünür:
curl: (52) Empty reply from serverBir SOCKS5 istemcisinden genellikle bir connection closed before handshake mesajı görürsünüz. Neden olduğunu kasıtlı olarak söylemiyoruz — "allow-list'te değilsiniz" bilgisini sızdırmak bir saldırgana hak etmediği bilgiyi vermektir.
Bir kuralın çalıştığını doğrulamak için aynı sayfada proxy'nin istek logundan takip edin. Reddedilen denemeler kaynak IP ile birlikte BLOCKED · acl olarak görünür, kim ne zaman denedi tam bir audit kaydı elinizde olur.
REST API üzerinden programlı kural yönetimi
Aynı kontroller REST API'de de mevcuttur. Bu, özellikle bir CI/CD pipeline'ında bir işin çalışma başlangıcında mevcut egress IP'sini allow-list'e eklemesini ve sonunda kaldırmasını istediğinizde kullanışlıdır:
curl -X PATCH -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" -d '{"aclMode":"allow","aclEntries":["203.0.113.7","198.51.100.0/24"]}' https://nodetonet.com/api/v1/proxies/<id>aclMode değerleri: off, allow veya deny. aclEntries, panelin kabul ettiği formatta bir string dizisidir. Tüm kuralları temizleyip yalnızca kimlik bilgisine dönmek için boş bir aclEntries dizisiyle aclMode: "off" gönderin. Birden fazla proxy'yi kapsayan otomatik bir iş akışı kuruyorsanız özellikler paneli üzerinden de token yönetimi ve API anahtarı oluşturabilirsiniz.
İstemci başına ACL'ler ile katmanlama
Tek bir tünelde birden fazla proxy istemcisi çıkardıysanız — alt tüketici başına farklı kimlik bilgileri — her istemci de kendi ACL'sini taşır. Değerlendirme sırası şöyledir:
- Tünel başına ACL — kaynak IP önce bunu geçmek zorunda.
- İstemci başına ACL — kaynak IP tünel seviyesi kontrolünü geçerse istemci seviyesi kurallar daha da daraltır.
Bu, her biri kendi ofis IP aralığına kilitlenmiş birkaç müşteri için her biri için ayrı proxy oluşturmadan tek bir tünel çalıştırabileceğiniz anlamına gelir. Tam yalıtılmış çok-kiracılı bir kurulum için bunu istemci başına kota ve thread limitleri ile birleştirin.
IP kısıtlamalarını alan adı kısıtlamalarıyla birleştirme
IP kısıtlamaları tünelinize kimin bağlanabileceğini kontrol eder. Tünelin çıkış trafiğinin nereye gideceği üzerinde tamamlayıcı bir kontrol için alan adı allow- ve deny-list'leri'ne bakın. İkisi birlikte iki taraflı bir güvenlik duvarı sağlar: girişte kaynağı kilitleyin, çıkışta hedefi kilitleyin.
Yaygın hatalar
- Kendi IP'nizi unutmak. Kısıtlayıcı bir allow-list kaydetmeden önce ikinci bir bağlantıdan test edin, tamamen kilitlenemeyesiniz.
- Dinamik ev veya mobil IP'ler. Mobil ağdaki CGNAT, her yeniden bağlanmada IP'nizin değiştiği anlamına gelir. Sabit-IP VPN egress kullanın ya da yalnızca kimlik bilgisiyle kalın.
- Deny-list'e fazla güvenmek. Kararlı bir saldırgan IP'yi değiştirebilir. Deny-list'ler bir tamamlayıcıdır, ikame değil — istemci IP'leriniz öngörülebilir olduğu her yerde allow-list kullanın.
- Proxy checker'ı unutmak. Kuralları kaydettikten sonra proxy uç noktanızı izin verilen IP'nizden proxy checker'ımızla test edin, bağlantının geçtiğini doğrulayın; farklı bir bağlantıdan da bloğun çalıştığını teyit edin.
Sırada ne var
- Alan adı allow- ve deny-list'leri — tünelin hedef tarafını güvenlik duvarıyla koruyun.
- Müşteri başına proxy istemcileri — kendi IP kuralları olan kapsamlı kimlik bilgileri.
- İstemci başına kota limitleri — erişim kurallarının yanında bant genişliği kullanımını sınırlayın.
- Audit log'ları — engellenen kaynak önemli olduğunda kimin olduğunu öğrenin.
- Nodetonet quickstart — tüneliniz henüz kurulmadıysa.
- Ücretsiz hesap açın ve ilk güvenli tünelinizi dakikalar içinde oluşturun.