Kurumsal Proxy Arkasında
Birçok fabrika ve kurumsal ağ, internete yalnızca bir kurumsal HTTP proxy üzerinden ulaşır (örneğin 3128 portunda çalışan bir Squid proxy). IronFlock Appliance bu kurulumda sorunsuz kurulur ve çalışır — proxy’nizi kurulum komutunda belirtirsiniz, gerisini yükleyici sizin için yapılandırır.
Bu sayfa, appliance ana makinesinde hiçbir proxy ortam değişkeninin ayarlı olmadığını varsayar — proxy’yi açıkça siz sağlarsınız. Yükleyicinin otomatik olarak hallettiği işlemleri ve TLS’i araya girip inceleyen proxy’ler için gereken tek ek adımı açıklar.
Bu, Appliance kılavuzunun Güvenlik Duvarı Yapılandırması bölümünün proxy karşılığıdır. Aynı IronFlock uç noktalarına erişilebilir olması gerekir — fark, burada bunlara proxy’niz üzerinden ulaşılmasıdır.
Bir Proxy Neden Dikkat Gerektirir
IronFlock platform görüntüleri Docker daemon tarafından çekilir — kabuğunuzdan ayrı, kendi ağ yapılandırmasına sahip bir arka plan hizmeti. Aksi halde proxy üzerinden internete ulaşabilen bir ana makinede bile, açıkça söylenmedikçe daemon bu proxy’den haberdar olmaz. Yapılandırılmadan bırakıldığında doğrudan bağlanmaya çalışır, ağ bunu engeller ve kurulum giriş adımında bir zaman aşımıyla durur:
Error response from daemon: Get "https://instance-registry.ironflock.com/v2/":
net/http: request canceled while waiting for connection (Client.Timeout exceeded)Yükleyicinin Sizin İçin Hallettiği İşlemler
Kurulum komutunda bir proxy belirttiğinizde yükleyici Docker daemon’ını sizin için yapılandırır — /etc/systemd/system/docker.service.d/http-proxy.conf konumuna bir proxy drop-in dosyası yazar ve IronFlock kayıt defterine ulaşabilmesi için Docker’ı bir kez yeniden başlatır. Bu adım şöyledir:
- Müdahalesiz — proxy’yi bir kez sağlarsınız (aşağıya bakın); yükleyici yapılandırmayı yazar ve Docker’ı sizin için yeniden başlatır, elle daemon kurulumu gerekmez.
- Idempotent — sonraki güncellemelerde Docker’ı yalnızca proxy gerçekten değiştiyse yeniden başlatır, böylece çalışan uygulamalarınız rahatsız edilmez.
- Hiç proxy verilmediğinde tamamen atlanır — doğrudan internet bağlantılı kurulumlar etkilenmez.
Yükleyici ayrıca appliance’ın buluta kendi bağlantısını da proxy üzerinden yönlendirir — lisans doğrulama ve örneğinize ironflock.com üzerinden ulaşmanızı sağlayan uzaktan yönetim bağlantısı. Proxy’nizi appliance yapılandırmasına kaydeder ve platform bunu otomatik olarak kullanır. Appliance’ın çevrimiçi olması için ayrı bir kuruluma gerek yoktur.
Yükleyiciyi Bir Proxy Arkasında Çalıştırma
Proxy iki yerde gereklidir: curl yükleyiciyi indirmek için, yükleyici de Docker’ı yapılandırmak için ona ihtiyaç duyar. İkisine de tek bir komutta sağlayın — proxy URL’sini bir kez ayarlayın, --proxy ile curl’e ve --http-proxy / --https-proxy ile yükleyiciye geçirin:
# Kurumsal proxy'niz — bu satırı düzenleyin
PROXY="http://proxy.your-company.com:3128"
curl -fsSL --proxy "$PROXY" \
https://instance-registry.ironflock.com/dl/appliance/install_ironflock.sh \
| sudo bash -s -- <your-instance-key> --http-proxy "$PROXY" --https-proxy "$PROXY"Proxy URL’sini ve <your-instance-key>’i kendi değerlerinizle değiştirin. Proxy’niz kimlik doğrulama gerektiriyorsa kimlik bilgilerini URL’ye ekleyin: http://user:password@proxy.your-company.com:3128.
Yükleyici proxy parametreleri:
| Parametre | Amaç |
|---|---|
--http-proxy <url> | Docker daemon’ından gelen düz HTTP trafiği için proxy. |
--https-proxy <url> | HTTPS trafiği için proxy (görüntü çekme işlemlerinde önemli olan budur). |
--no-proxy <list> | Proxy’yi atlaması gereken, virgülle ayrılmış ek ana makineler. |
Aynı değerler IRONFLOCK_HTTP_PROXY, IRONFLOCK_HTTPS_PROXY ve IRONFLOCK_NO_PROXY ortam değişkenleri olarak da sağlanabilir.
Ana makine
HTTP_PROXY/HTTPS_PROXY’yi zaten dışa aktarıyorsa, bunun yerinesudo -E bash(parametreler olmadan) çalıştırabilirsiniz; yükleyici bunları otomatik algılar — ancak yeni bir appliance’ta bunlar genellikle ayarlı değildir, bu yüzden yukarıdaki gibi açıkça geçirmek güvenilir yoldur.
Yerel trafik her zaman proxy’yi atlar
NO_PROXY’yi elle yönetmenize gerek yoktur. Yükleyici localhost, 127.0.0.1 ve appliance’ın kendi ana makine adresini her zaman proxy dışında tutar (--no-proxy ile geçirdiğiniz her şey korunur ve birleştirilir). Bu, appliance’ın yerel uygulama mağazasına ve kayıt defterine doğrudan ulaşılmasını, asla kurumsal proxy üzerinden yönlendirilmemesini sağlar.
Uç Cihazlar
Yukarıdaki her şey, cihaz kurulum aracı (ironflock-init) ile kurulan uç cihazlar için de aynı şekilde geçerlidir. Aynı proxy parametrelerini alır ve kendisini aynı şekilde yapılandırır — onu çalıştırırken proxy’yi geçirin; indirmelerini (paket yöneticisi, Docker kurulumu, ajan indirme) ve Docker daemon’ını sizin için proxy üzerinden yönlendirir:
sudo ./ironflock-init -c mydevice.flock \
--http-proxy "$PROXY" --https-proxy "$PROXY"Kurulum aracını indiren bootstrap betiği ondan önce çalışır, bu yüzden o adıma da proxy’yi verin — indirmesinin başarılı olması için önce kabukta dışa aktarın:
export HTTP_PROXY="$PROXY"
export HTTPS_PROXY="$PROXY"
curl -sSL --proxy "$PROXY" https://instance-registry.ironflock.com/dl/reswarmify/install.sh | bashCihaz, uygulama görüntülerini buluttan değil yerel bir appliance uygulama mağazasından çekiyorsa, o kayıt defterinin ana makinesini --no-proxy ile ekleyin; böylece bu çekme işlemleri yerel ağda kalır.
Windows cihazlarda aracı bir Windows hizmeti olarak çalışır; proxy’yi hizmet yükleyicisine iletin — hizmet ortamında saklanır ve platform bağlantısı ile aracının otomatik güncellemelerini kapsar:
reagent.exe service install -config path\to\config.flock -proxy "http://proxy.example.com:3128"Docker Desktop bu ayarı okumaz: imaj çekme işlemlerinin de çalışması için proxy’sini Settings → Resources → Proxies altında ayrıca yapılandırın.
TLS Araya Giren Proxy’ler (Kurumsal CA)
Birçok kurumsal proxy, HTTPS trafiğini bir şirket sertifika yetkilisiyle (CA) yeniden imzalayarak inceler. Bunlar için proxy’yi yapılandırmak gereklidir ama yeterli değildir — appliance ana makinesinin ayrıca o CA’ya güvenmesi gerekir, aksi halde buluta yapılan her bağlantı (görüntü çekme, lisans doğrulama, yönetim bağlantısı) reddedilir.
CA’yı bir kez, ana makinenin sistem güven deposuna kurun. Appliance bu güven deposunu tüm kapsayıcılarına bağlar, böylece Docker ve her IronFlock hizmeti CA’yı alır — kapsayıcı başına veya hizmet başına yapılandırılacak bir şey yoktur. Kapsayıcılar bunu başlangıçta okuduğu için, CA’yı ekledikten veya değiştirdikten sonra yığını yeniden başlatın (aşağıdaki 3. adım).
1. Kurumsal CA’yı edinin
Ağ ekibinizden proxy’nin “SSL incelemesi” / “TLS araya girme” kök CA’sını — yönetilen kurumsal makinelere zaten dağıtılmış olan aynı sertifikayı — bir .crt dosyası olarak isteyin. En temiz kaynak budur.
Tek bir ana makinenin sertifikasını değil, imzalayan CA’yı kurun. Yaygın hata, proxy’nin tek bir ana makine adı için (örneğin yalnızca
instance-registry.ironflock.com) yeniden imzaladığı sertifikayı kaydetmektir. Bu yalnızca o ana makineyi çalıştırır ve diğer tüm bulut ana makinelerinin başarısız olmasına yol açar. Size gereken, bu sertifikaları imzalayan CA’dır.
Dosyayı doğrudan edinemiyor ama proxy tüm zincirini sunuyorsa, CA’yı hattan çıkarabilirsiniz — <PROXY_HOST>:<PROXY_PORT>’u kendi proxy’nizle değiştirin:
# Zinciri yakala, sertifika başına bir PEM. c1, ana makine başına yaprak sertifikadır (atla);
# c2..cN, güvenilecek kurumsal CA zinciridir.
echo quit | openssl s_client -connect instance-registry.ironflock.com:443 \
-proxy <PROXY_HOST>:<PROXY_PORT> -showcerts 2>/dev/null \
| awk '/BEGIN CERTIFICATE/{n++; c=1} c{print > ("/tmp/proxy-c" n ".pem")} /END CERTIFICATE/{c=0}'
# İsteğe bağlı — geri gelenleri inceleyin:
for f in /tmp/proxy-c*.pem; do echo "== $f =="; openssl x509 -in "$f" -noout -subject -issuer; done2. Kurun ve güven deposunu yeniden oluşturun
BT ekibiniz size .crt’yi doğrudan verdiyse:
sudo cp corporate-root-ca.crt /usr/local/share/ca-certificates/corporate-proxy-ca.crt
sudo update-ca-certificatesYukarıdaki zincirden çıkardıysanız, yaprak (c1) dışındaki her sertifikaya güvenin:
i=0; for f in $(ls -v /tmp/proxy-c*.pem | tail -n +2); do
i=$((i+1)); sudo cp "$f" "/usr/local/share/ca-certificates/corporate-proxy-ca-$i.crt"
done
sudo update-ca-certificates3. Doğrulayın
Her IronFlock bulut ana makinesi artık proxy üzerinden doğrulanmalıdır — bir TLS hatası değil, bir HTTP durum kodu:
for H in instance-registry.ironflock.com web.ironflock.com cbw.ironflock.com; do
curl -x http://<PROXY_HOST>:<PROXY_PORT> -sS -o /dev/null -w "$H -> %{http_code}\n" "https://$H/"
doneÜçü için de 200, 401 veya 404 gibi bir kod, CA’nın doğru olduğu anlamına gelir. Ardından hizmetlerin bunu alması için yığını yeniden başlatın (veya yükleyiciyi yeniden çalıştırın):
sudo systemctl restart ironflock.serviceCihaz Kullanıcı Arayüzlerine Uzaktan Erişim
IronFlock, bir uç cihaz veya makine üzerinde çalışan bir kullanıcı arayüzünü — bir makine HMI’sini, bir PLC sayfasını, cihaz üzerindeki bir yapılandırma veya pano ekranını — herhangi bir yerden, doğrudan IronFlock içinde açmanıza olanak tanır. Bu, uzaktan servis ve destek için önemli bir imkândır: bir mühendis, sahada ya da yerel ağda olmadan bir makinenin arayüzüne ulaşabilir. Erişim her zaman IronFlock yetki sistemi tarafından aracılanır ve korunur, böylece belirli bir cihaza yalnızca yetkili kullanıcılar erişebilir.
Bu uzaktan erişim tüneli, olgun ve yaygın olarak kullanılan bir açık kaynaklı teknoloji olan frp (Fast Reverse Proxy) üzerine kuruludur. IronFlock bunu yalnızca yukarıda açıklanan cihaz arayüzü erişimini sağlamak için kullanır.
Bir kurumsal proxy neden engel olabilir
frp güçlü ağ geçiş yeteneklerine sahiptir ve bu nedenle antivirüs ve proxy güvenlik ürünleri onu çoğunlukla genel olarak riskli yazılım olarak işaretler — oysa uzun bir geçmişe sahip açık kaynaklı bir bileşen olarak güvenlidir ve burada yalnızca onaylanmış uzaktan erişim özelliği için kullanılır. Bu durumda proxy, frp’yi içeren IronFlock bileşeninin indirilmesini engeller.
Bu, appliance’ınızı bozmaz: uzaktan erişim tüneli isteğe bağlı bir özelliktir, dolayısıyla o bileşen engellendiğinde platform normal şekilde kurulur ve çalışır, yalnızca cihaz arayüzü erişimi olmadan işlev görür. Panoda, bir cihazın uzaktan erişim denetimleri bu durumda uzaktan erişimin bu appliance’ta kullanılamadığını gösterir.
Kurumsal BT’nin neye izin vermesi gerekir
Kuruluşunuz IronFlock’un uzaktan servis özelliklerinden yararlanmak istiyorsa, frp’yi içeren IronFlock bileşeninin kurumsal proxy üzerinden indirilmesine izin verilmelidir. Ağ/güvenlik ekibinizden şunları yapmalarını isteyin:
- frp bileşeni için IronFlock’un indirme trafiğini antivirüs / kötü amaçlı yazılım içerik taramasından ve dosya indirme engellemesinden muaf tutmalarını — en temiz seçenek, IronFlock’un uç noktalarını proxy’nin şifresini çözme (TLS incelemesi atlama) listesine eklemektir.
- frp tespitini onaylı bir istisna olarak değerlendirmelerini: bu, bu açık kaynaklı kütüphanenin meşru kullanımı için iyi bilinen bir yanlış pozitiftir.
Appliance için zaten listelenen aynı IronFlock uç noktaları geçerlidir — bkz. Güvenlik Duvarı Yapılandırması; burada söz konusu olan, o trafiği yalnızca yönlendirmenin ötesinde taramamak/engellememektir.
frp’ye izin verildikten sonra, yalnızca güncellemeyi yeniden çalıştırın — indirme başarılı olur olmaz özellik başka bir değişikliğe gerek kalmadan otomatik olarak etkinleşir:
sudo ironflock-updateUzaktan erişim olmadan çalıştırma
Cihaz arayüzü erişimine ihtiyacınız yoksa — ya da proxy istisnası ayarlanırken temiz bir kurulum istiyorsanız — tüneli açıkça devre dışı bırakabilirsiniz. Diğer her şey normal şekilde kurulur:
# kurulum sırasında, kurulum komutuna eklenir
... | sudo bash -s -- <your-instance-key> --no-tunnel
# veya zaten kurulmuş bir appliance üzerinde
sudo ironflock-update --no-tunnelBu tercih güncellemeler arasında hatırlanır. Daha sonra (frp’ye izin verildikten sonra) --tunnel ile yeniden etkinleştirin:
sudo ironflock-update --tunnelSorun Giderme
Kurulum, “Logging in to instance-registry.ironflock.com” adımında bir Client.Timeout hatasıyla duruyor.
Docker daemon kayıt defterine ulaşamıyor. Yükleyiciyi yeniden çalıştırın ve yukarıda gösterildiği gibi proxy’nizi --http-proxy / --https-proxy ile geçirin.
Proxy’yi yapılandırdıktan sonra giriş hâlâ başarısız oluyor. Proxy’niz büyük olasılıkla TLS’i araya girip inceliyor. Kurumsal CA’yı TLS Araya Giren Proxy’ler bölümünde açıklandığı gibi kurun ve yeniden çalıştırın.
Docker daemon’ının proxy’yi gördüğünü doğrulayın:
sudo systemctl show --property=Environment docker
sudo docker login instance-registry.ironflock.comdocker login kendi başına başarılı olursa, appliance kurulumu başarısız olan adımı geçecektir.
Diğer her şey sorunsuz kurulurken tek bir bileşen indirilemiyor.
Bu genellikle frp tabanlı uzaktan erişim bileşeninin, proxy’niz veya antivirüsünüz tarafından riskli yazılım olarak engellenmesidir. Kurulum yine de tamamlanır — yalnızca cihaz arayüzü erişimi kullanılamaz. Bunu etkinleştirmek için proxy ekibinizden, Cihaz Kullanıcı Arayüzlerine Uzaktan Erişim bölümünde açıklandığı gibi o trafiğe izin vermesini isteyin, ardından ironflock-update’i yeniden çalıştırın. Bilerek onsuz kurmak için --no-tunnel geçirin.
Güncellemeler
Bir appliance proxy arkasında kurulduktan sonra proxy ayarları hatırlanır. Hem manuel güncellemeler hem de otomatik arka plan güncellemeleri, ek bir işlem gerektirmeden proxy üzerinden çalışmaya devam eder — Appliance kılavuzundaki Bakım bölümüne bakın.
Cihaz arayüzlerine uzaktan erişim kurulum sırasında engellendiyse, her güncelleme bunu otomatik olarak yeniden dener — böylece proxy’niz frp’ye izin verdiğinde, bir sonraki güncelleme özelliği başka bir adıma gerek kalmadan açar.