تحریر: Matt Connor 2026-08-13 · اپ ڈیٹ شدہ 2026-08-16

VPS پر UniFi controller کیسے انسٹال کریں

Q: UniFi کنٹرولر اپنے خودکار بیک اپ کہاں محفوظ کرتا ہے؟

یہاں استعمال ہونے والے کنٹینر امیج میں یہ /config/data/backup/autobackup میں محفوظ ہوتے ہیں، جو ہوسٹ پر آپ کے ڈیٹا پاتھ اور data/backup/autobackup سے منسلک ہوتا ہے، جہاں یہ .unf فائلیں ورژن اور ٹائم اسٹیمپ کے نام سے محفوظ ہوتی ہیں۔ کچھ نئی تنصیبات میں autobackup ڈائریکٹری موجود نہیں ہوتی، اور شیڈول شدہ بیک اپ بغیر کسی ایرر کے کچھ بھی نہیں لکھتا، اس لیے شیڈول سیٹ کرنے کے ایک دن بعد اس ڈائریکٹری کو چیک کریں اور اگر یہ خالی ہو تو اسے خود بنائیں۔ فائلوں کو VPS سے باہر کاپی کر لیں، کیونکہ .unf میں سائٹ کی کنفیگریشن اور ایڈمنسٹریٹر اکاؤنٹس موجود ہوتے ہیں۔

UniFi Network Application کو VPS پر ہوسٹ کرنے کا مکمل طریقہ سیکھیں۔ اس گائیڈ میں Docker، MongoDB کنفیگریشن، RAM کی ضروریات، اور Layer 3 adoption کے لیے set-inform کمانڈ شامل ہے۔

VPS پر UniFi controller اصل میں کیا کرتا ہے

VPS پر موجود UniFi controller ایک ایسا انتظامی سرور ہے جو ان سائٹس کے ڈاؤن ہونے پر بھی قابل رسائی رہتا ہے جنہیں یہ manage کرتا ہے۔ یہ سافٹ ویئر Ubiquiti کی UniFi Network Application ہے: ایک Java پروگرام جس کے پیچھے MongoDB ڈیٹا بیس ہوتا ہے۔ یہ آپ کے access points اور switches کو configure کرتا ہے، ان کے اعداد و شمار (statistics) کو محفوظ کرتا ہے، اور admin interface فراہم کرتا ہے۔ یہ کلائنٹ کا ٹریفک نہیں اٹھاتا۔

یہ آخری نکتہ فیصلہ کرتا ہے کہ اسے کہاں ہونا چاہیے۔ اگر آپ controller کو اس دفتر کے اندر کسی مشین پر رکھیں جسے وہ manage کر رہا ہے، تو نیٹ ورک کے ڈاؤن ہوتے ہی آپ اسے دیکھنے والا ٹول بھی کھو دیں گے۔ اگر آپ اسے ایک مستحکم public address والے VPS پر رکھیں، تو یہ چلتا رہتا ہے، ڈیٹا اکٹھا کرتا رہتا ہے، اور ایک ہی جگہ سے کئی سائٹس پر موجود ڈیوائسز کو adopt کر سکتا ہے۔ اسے uptime کی ضرورت ہوتی ہے، نہ کہ زیادہ طاقتور ہارڈویئر کی۔

جب controller آف لائن ہوتا ہے، تو adopt شدہ access points اور switches پہلے سے بھیجی گئی configuration کے مطابق ٹریفک کو فارورڈ کرتے رہتے ہیں۔ آپ ڈیش بورڈ اور اعداد و شمار سے محروم ہو جاتے ہیں، نیز ان تمام فیچرز سے بھی جن کے لیے controller کا لائیو ہونا ضروری ہے: جیسے guest portal لاگ ان، یا RADIUS (remote authentication dial-in user service) اگر controller ہی آپ کا RADIUS سرور ہے۔ کلائنٹس کا کنکشن برقرار رہتا ہے۔

UniFi controller کو کتنی RAM درکار ہوتی ہے؟

2 GB کم از کم ضرورت ہے اور 4 GB خریدنے کے لیے مناسب مقدار ہے۔ ایک باکس میں میموری استعمال کرنے والے دو بڑے اجزاء Java اور MongoDB ہیں، اور یہ دونوں ایک دوسرے سے آزادانہ طور پر اپنی میموری کا تعین کرتے ہیں۔

Java heap کی حد MEM_LIMIT کے ذریعے مقرر کی جاتی ہے، جسے container image میں بائی ڈیفالٹ 1024 MB پر سیٹ کیا گیا ہے۔ MongoDB باقی آدھا حصہ لیتا ہے۔ اس کا WiredTiger اسٹوریج انجن اپنے کیشے کا سائز 1 GB سے اوپر والی RAM کا نصف، یا 256 MB، جو بھی زیادہ ہو، کے مطابق رکھتا ہے۔ 2 GB کے VPS پر یہ تقریباً 512 MB کیشے، 1 GB ہیپ، JVM کی اپنی نان-ہیپ میموری اور آپریٹنگ سسٹم کا مجموعہ بنتا ہے۔ یہ مصروف دن آنے تک تو ٹھیک چلتا ہے، لیکن پھر kernel کا out-of-memory killer ان دو پروسیسز میں سے ایک کو ختم کر دیتا ہے۔ کسی بھی غیر واضح ری اسٹارٹ کے بعد، یہ جاننے کے لیے کہ آیا یہی وجہ تھی، dmesg -T | grep -i 'killed process' چلائیں۔ اگر آپ کے پاس 2 GB ہی ہے تو ایک swap file شامل کریں۔

CPU اور ڈسک کی ضروریات زیادہ نہیں ہیں۔ ایک یا دو vCPU چند درجن ڈیوائسز کو سنبھال سکتے ہیں۔ 20 GB ڈسک سے شروعات کریں اور اس پر نظر رکھیں، کیونکہ ڈیٹا بیس کا سائز آپ کے کلائنٹس کی تعداد اور اعداد و شمار کو محفوظ رکھنے کے دورانیے کے ساتھ بڑھتا ہے۔ ایک کنٹرولر اکیلے 4 GB باکس کا زیادہ تر حصہ خالی رکھتا ہے، لہذا اگر آپ اس کے ساتھ کوئی اور ایپ چلانے کا ارادہ رکھتے ہیں، تو پہلے اس دوسری ایپ کے مطابق سائز کا تعین کریں، کیونکہ PhotoPrism اور Immich کی RAM کی کم از کم ضروریات بہت مختلف ہیں اور ان میں سے کوئی بھی کنٹرولر سے زیادہ میموری مانگتا ہے۔

CPU کی ایک خصوصیت اہم ہے، اور سستے پلانز میں اسے نظر انداز کرنا آسان ہے:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 اور اس کے بعد کے ورژنز کو x86_64 ہارڈویئر پر AVX (advanced vector extensions) کی ضرورت ہوتی ہے۔ اگر یہ کمانڈ کچھ بھی پرنٹ نہیں کرتی، تو mongod اسٹارٹ اپ کے دوران بند ہو جائے گا اور کنٹینر لوپ میں ری اسٹارٹ ہوتا رہے گا، کیونکہ بائنری ایک ایسی انسٹرکشن چلاتی ہے جو CPU میں موجود نہیں ہے۔ پرانے Intel Celeron اور Pentium ہوسٹس اس کی عام وجہ ہیں، جیسا کہ وہ ہائپر وائزرز جو گیسٹ سے CPU فلیگز چھپا لیتے ہیں۔ MongoDB 4.4 کو AVX کی ضرورت نہیں ہوتی اور یہی واحد متبادل ہے، لیکن یہ ڈیٹا بیس کا وہ ورژن ہے جسے اپ اسٹریم اب پیچ (patch) نہیں کرتا۔ نئے CPU والے ہوسٹ پر منتقل ہونا بہتر حل ہے۔ ARM VPS پر یہ سوال پیدا نہیں ہوتا، کیونکہ AVX ایک x86 انسٹرکشن سیٹ ہے، اور دونوں امیجز arm64 بلڈز شائع کرتی ہیں۔ اگر آپ ان دونوں کے درمیان انتخاب کر رہے ہیں، تو ARM اور x86 VPS پلانز کے درمیان فرق صرف قیمت تک محدود نہیں ہے۔

Docker Compose کے ساتھ UniFi Network Application انسٹال کریں

Docker استعمال کرنا سب سے محفوظ طریقہ ہے، کیونکہ یہ آپ کو MongoDB کا وہ ورژن استعمال کرنے کی سہولت دیتا ہے جسے ایپلیکیشن سپورٹ کرتی ہے، بجائے اس کے کہ آپ اپنی ڈسٹری بیوشن کے فراہم کردہ ورژن پر انحصار کریں۔ اگر سرور پر Docker موجود نہیں ہے تو پہلے VPS پر Docker انسٹال کریں۔

mkdir -p ~/unifi/config ~/unifi/db
cd ~/unifi

ایپلیکیشن کے لاگ ان ہونے سے پہلے MongoDB کو ایک صارف کی ضرورت ہوتی ہے۔ آفیشل MongoDB امیج پہلی بار اسٹارٹ ہونے پر /docker-entrypoint-initdb.d میں موجود ہر اسکرپٹ کو چلاتا ہے۔ اسے ~/unifi/init-mongo.sh کے طور پر محفوظ کریں:

#!/bin/bash
if which mongosh > /dev/null 2>&1; then
  mongo_init_bin='mongosh'
else
  mongo_init_bin='mongo'
fi
"${mongo_init_bin}" <<EOF
use ${MONGO_AUTHSOURCE}
db.auth("${MONGO_INITDB_ROOT_USERNAME}", "${MONGO_INITDB_ROOT_PASSWORD}")
db.createUser({
  user: "${MONGO_USER}",
  pwd: "${MONGO_PASS}",
  roles: [
    "clusterMonitor",
    { db: "${MONGO_DBNAME}", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_stat", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_audit", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_restore", role: "dbOwner" }
  ]
})
EOF

یہ اسکرپٹ صرف تب چلتا ہے جب ڈیٹا بیس ڈائریکٹری خالی ہو۔ اگر آپ اسٹیک کو غلط پاس ورڈ کے ساتھ ایک بار اسٹارٹ کر دیں تو صارف غلط پاس ورڈ کے ساتھ بن جائے گا، اور بعد میں compose فائل میں تبدیلی کرنے سے کچھ نہیں ہوگا کیونکہ اسکرپٹ دوبارہ نہیں چلے گا۔ اس کی علامت یہ ہے کہ ایپلیکیشن کنٹینر MongoDB کی تصدیق میں ناکامی (authentication failures) کے لاگز دکھائے گا اور ویب انٹرفیس کبھی ظاہر نہیں ہوگا۔ تازہ انسٹالیشن پر اس کا حل یہ ہے کہ اسٹیک کو روکیں، ~/unifi/db کو حذف کریں، اور دوبارہ شروع کریں۔

پھر ~/unifi/compose.yaml لکھیں:

services:
  unifi-db:
    image: docker.io/mongo:8.0
    container_name: unifi-db
    environment:
      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD=change-this-root-password
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
    volumes:
      - ./db:/data/db
      - ./init-mongo.sh:/docker-entrypoint-initdb.d/init-mongo.sh:ro
    restart: unless-stopped

  unifi-network-application:
    image: lscr.io/linuxserver/unifi-network-application:10.5.67-ls141
    container_name: unifi-network-application
    depends_on:
      - unifi-db
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_HOST=unifi-db
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
      - MEM_LIMIT=1024
      - MEM_STARTUP=1024
    volumes:
      - ./config:/config
    ports:
      - "8080:8080"
      - "3478:3478/udp"
      - "127.0.0.1:8443:8443"
    restart: unless-stopped

دونوں امیج ٹیگز کو جان بوجھ کر پن (pin) کیا گیا ہے۔ 10.5.67-ls141 اگست 2026 میں ایپلیکیشن کا موجودہ ریلیز تھا، لہذا امیج کی ریلیز لسٹ چیک کریں اور انسٹالیشن کے وقت جو ورژن موجود ہو اسے پن کریں۔ ڈیٹا بیس کا ٹیگ زیادہ اہم ہے۔ MongoDB خود بخود اپنے ڈیٹا فائلز کو بڑے ورژنز (major versions) میں اپ گریڈ نہیں کرتا، اس لیے mongo:latest ایک دن نیا میجر ورژن پل (pull) کر لے گا، موجودہ فائلز کو کھولنے سے انکار کر دے گا، اور لوپ میں ری اسٹارٹ ہوتا رہے گا۔ میجر ورژن کو پن کریں اور اسے سوچ سمجھ کر اپ ڈیٹ کریں۔ UniFi Network 8.1 اور بعد کے ورژنز MongoDB 3.6 سے 7.0 تک کو سپورٹ کرتے ہیں، اور 9.0 نے MongoDB 8.0 کے لیے سپورٹ شامل کی ہے۔

PUID اور PGID کا ہوسٹ پر موجود ایک حقیقی صارف سے میل کھانا ضروری ہے، ورنہ ./config کے تحت موجود فائلز ایسی شناخت کی ملکیت بن جائیں گی جو انہیں لکھ (write) نہیں سکتی۔ اپنا یوزر آئی ڈی حاصل کرنے کے لیے id چلائیں۔ کنٹینر امیجز میں PUID اور PGID کیسے کام کرتے ہیں اس بارے میں تفصیل فراہم کرتا ہے کہ اگر یہ میل نہ کھائیں تو کیا ہوتا ہے۔

اسے اسٹارٹ کریں اور نگرانی کریں:

docker compose up -d
docker compose ps
docker compose logs -f unifi-network-application

docker compose ps کو دونوں کنٹینرز running دکھانے چاہئیں۔ unifi-db کا restarting میں پھنس جانا یا تو اوپر بیان کردہ AVX کا مسئلہ ہے یا ./db پر اجازت (permission) کا مسئلہ۔ جب لاگ مستحکم ہو جائے تو دونوں لسنرز کو چیک کریں:

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1:8443/
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/inform

کوئی بھی HTTP اسٹیٹس کوڈ ملنے کا مطلب ہے کہ لسنر بائنڈ ہو چکا ہے اور جواب دے رہا ہے۔ Connection refused کا مطلب ہے کہ ایپلیکیشن ابھی اسٹارٹ ہو رہی ہے، جس میں پہلی بار چلنے پر چھوٹے VPS پر ایک یا دو منٹ لگ سکتے ہیں، یا پھر یہ کہ ایپلیکیشن کبھی اسٹارٹ ہی نہیں ہوئی۔

انتظامی انٹرفیس تک رسائی حاصل کریں بغیر اسے ظاہر کیے

اوپر دی گئی فائل میں پورٹ 8443 کو 127.0.0.1 پر پبلش کیا گیا ہے، لہذا VPS کے باہر سے کوئی بھی انتظامی انٹرفیس تک نہیں پہنچ سکتا۔ سیٹ اپ وزرڈ چلانے کے لیے اسے SSH کے ذریعے فارورڈ کریں:

ssh -L 8443:127.0.0.1:8443 you@vps.example.com

اس سیشن کو کھلا چھوڑ دیں اور https://127.0.0.1:8443 پر براؤز کریں۔ سرٹیفکیٹ خود ساختہ (self-signed) ہے، اس لیے براؤزر ایک بار وارننگ دے گا۔ ایڈمنسٹریٹر اکاؤنٹ بنائیں، سائٹ کا نام رکھیں، اور فی الحال ڈیوائس ایڈاپشن (device adoption) کو چھوڑ دیں۔

ایک ایڈمنسٹریٹر کے لیے SSH ٹنل کافی ہے۔ ٹیم کے لیے، VPS کو ایک پرائیویٹ ایڈریس دیں اور انٹرفیس کو اس پر بائنڈ کریں۔ اپنے VPS پر WireGuard VPN اور Tailscale سب نیٹ راؤٹر دونوں آپ کو ایسا ایڈریس دیتے ہیں جس تک صرف آپ کے لوگ ہی رسائی حاصل کر سکتے ہیں۔ WireGuard کے لیے پبلش شدہ پورٹ کو 10.8.0.1:8443:8443 میں تبدیل کریں، یا اس ایڈریس پر جو Tailscale تفویض کرتا ہے۔ ایک مسئلہ یہ ہے کہ Docker ایسے ایڈریس پر پبلش نہیں کر سکتا جو ابھی موجود نہ ہو، اس لیے کنٹینر شروع ہونے سے پہلے ٹنل انٹرفیس کا فعال ہونا ضروری ہے، ورنہ کنٹینر بائنڈ ایرر (bind error) کے ساتھ فیل ہو جائے گا۔

ایک ریموٹ UniFi ڈیوائس کیوں adopt نہیں ہوتی

باکس سے باہر نکلنے پر ایک UniFi ڈیوائس اپنے controller کو لوکل نیٹ ورک پر UDP port 10001 کے ذریعے براڈکاسٹ کر کے تلاش کرتی ہے۔ براڈکاسٹ LAN سے باہر نہیں جاتا، اس لیے دوسرے شہر کے دفتر میں موجود ڈیوائس کبھی بھی VPS پر موجود controller کو دریافت نہیں کر سکے گی۔ یہ Layer 3 adoption ہے، اور یہی وہ مرحلہ ہے جہاں زیادہ تر لوگ پھنس جاتے ہیں۔ ڈیوائس ٹھیک ہے اور controller بھی ٹھیک ہے۔ کسی چیز نے ڈیوائس کو یہ نہیں بتایا کہ اسے کہاں تلاش کرنا ہے۔

سب سے پہلے، controller کو بتائیں کہ کون سا ایڈریس دینا ہے۔ Controller کی Settings میں، System سیکشن کے اندر، ایک inform host کی ترتیب ہے جس میں override کا آپشن موجود ہے۔ اسے اپنے VPS کے public hostname یا IP پر سیٹ کریں۔ اس کے بغیر controller وہی ایڈریس مشتہر کرتا ہے جو اسے اپنے انٹرفیس پر نظر آتا ہے، جو کہ Docker bridge نیٹ ورک کے اندر 172.18.0.3 جیسا ایک پرائیویٹ ایڈریس ہوتا ہے۔ ڈیوائس کو وہ ایڈریس موصول ہوتا ہے، وہ اس تک روٹ نہیں کر پاتی، اور دوبارہ تلاش شروع کر دیتی ہے۔

پھر ڈیوائس کو اس ایڈریس کی طرف پوائنٹ کریں۔ ریموٹ LAN پر موجود ڈیوائس پر SSH کریں۔ فیکٹری ڈیفالٹ ڈیوائس ubnt یوزر نیم اور ubnt پاس ورڈ قبول کرتی ہے:

ssh ubnt@192.168.1.20
set-inform http://vps.example.com:8080/inform

نئے ڈیوائس فرم ویئر آپ کو شیل کے بجائے مینو میں لے جاتے ہیں۔ وہی کام ایک سنگل کمانڈ کے طور پر چلائیں:

ssh ubnt@192.168.1.20 mca-cli-op set-inform http://vps.example.com:8080/inform

ڈیوائس اب controller میں adopt ہونے کے لیے تیار نظر آتی ہے۔ Adopt پر کلک کریں، اور اسٹیٹ Adopting میں تبدیل ہو جاتی ہے۔ یہاں وہ حصہ ہے جو سب کو حیران کرتا ہے: آپ کو عام طور پر set-inform دوسری بار چلانا پڑتا ہے۔ ڈیوائس ری اسٹارٹ ہو کر provisioning میں جاتی ہے اور اپنی کنفیگریشن میں محفوظ inform URL پر واپس آ جاتی ہے، جسے controller نے ابھی مکمل طور پر تبدیل نہیں کیا ہوتا۔ اسٹیٹ کے Adopting ہونے کے دوران کمانڈ کو دوبارہ چلانے سے ہینڈ اوور مکمل ہو جاتا ہے۔ ڈیوائس پر info ٹائپ کریں تاکہ وہ inform URL اور اسٹیٹ دیکھ سکیں جو اس وقت اس کے پاس موجود ہے۔

اگر ڈیوائس پہلے کسی اور controller کے ذریعے adopt کی گئی تھی، تو صرف set-inform کام مکمل نہیں کرے گا، کیونکہ اس کے پاس اب بھی اس پرانے controller کے اسناد (credentials) موجود ہیں۔ اسے پہلے فیکٹری ڈیفالٹ پر ری سیٹ کریں، یا تو ری سیٹ بٹن سے یا پرانے اسناد استعمال کرتے ہوئے SSH کے ذریعے set-default سے۔

چند ڈیوائسز سے زیادہ کے لیے، DHCP استعمال کریں۔ DHCP (dynamic host configuration protocol) option 43 ایک وینڈر مخصوص ویلیو لے کر جاتا ہے، اور UniFi ڈیوائسز suboption 2 سے inform URL پڑھ لیتی ہیں۔ کسی بھی Linux باکس پر ہیکس سٹرنگ بنائیں:

URL="http://vps.example.com:8080/inform"
HEX=$(printf '%s' "$URL" | od -An -tx1 | tr -d ' \n')
printf '02%02x%s\n' "${#URL}" "$HEX"

http://192.168.3.10:8080/inform کے لیے، جو کہ 31 بائٹ کی سٹرنگ ہے، یہ 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d پرنٹ کرتا ہے۔ اس نتیجے کو اپنے راؤٹر کے DHCP option 43 فیلڈ میں ہیکس ویلیو کے طور پر پیسٹ کریں۔ اس نیٹ ورک پر بوٹ ہونے والی ہر ڈیوائس پھر اپنے لیز (lease) سے controller کا ایڈریس سیکھ لیتی ہے، بغیر کسی SSH کے۔ پرانی گائیڈز suboption 1 دکھاتی ہیں، 0104 جس کے بعد IPv4 ایڈریس کے چار بائٹس ہیکس میں ہوتے ہیں، اور ڈیوائسز اب بھی اس فارمیٹ کو قبول کرتی ہیں۔

اگر آپ سائٹ پر DNS چلاتے ہیں تو ایک تیسرا راستہ بھی موجود ہے۔ ایک UniFi ڈیوائس بوٹ ہونے پر unifi ہوسٹ نیم کو ریزولو کرنے کی کوشش کرتی ہے، لہذا unifi کے لیے ایک A record جو آپ کے VPS ایڈریس کی طرف اشارہ کرے، ڈیوائسز کو بغیر کسی فی ڈیوائس کام کے adopt کر لیتا ہے۔ یہ صرف وہاں مددگار ہے جہاں آپ اس ریزورور (resolver) کو کنٹرول کرتے ہیں جسے ڈیوائسز درحقیقت استعمال کرتی ہیں۔

کون سی UniFi ports کھولنی ہیں، اور کون سی نجی رکھنی ہیں

صرف دو ports کو ریموٹ سائٹ سے قابل رسائی ہونے کی ضرورت ہے۔

TCP 8080 انفارم چینل ہے، اور ہر adopted ڈیوائس اس سے منسلک ہوتی ہے۔ اس کے اندر موجود ڈیٹا AES انکرپٹڈ ہوتا ہے جس کی کلید کنٹرولر نے adoption کے دوران ڈیوائس کو دی ہوتی ہے، اسی لیے یہاں سادہ HTTP معمول کی ترتیب ہے۔
UDP 3478 STUN (session traversal utilities for NAT) ہے، جسے ڈیوائسز کنٹرولر تک واپسی کا راستہ برقرار رکھنے کے لیے استعمال کرتی ہیں۔

باقی سب کچھ VPS پر بند رہنا چاہیے۔

TCP 8443 ایڈمن انٹرفیس ہے۔ یہ وہ پورٹ ہے جسے کبھی بھی پبلک نہیں ہونا چاہیے۔ اس میں کنٹرولر کے زیر انتظام ہر سائٹ کی کنفیگریشن ایک پاس ورڈ کے پیچھے محفوظ ہوتی ہے۔
UDP 10001 اور UDP 1900 براڈکاسٹ ڈسکوری ہیں۔ براڈکاسٹس انٹرنیٹ پار نہیں کرتیں، اس لیے انہیں کھولنے کا کوئی فائدہ نہیں ہے۔
TCP 8880 اور TCP 8843 گیسٹ پورٹل ری ڈائریکٹس ہیں۔ انہیں صرف تب کھولیں اگر آپ گیسٹ پورٹل چلا رہے ہوں۔
TCP 6789 موبائل اسپیڈ ٹیسٹ کے لیے ہے اور UDP 5514 ریموٹ syslog کے لیے ہے۔ جب آپ انہیں استعمال کریں تب ہی شامل کریں۔
TCP 27117 MongoDB ہے۔ اوپر دی گئی compose فائل میں ڈیٹا بیس کوئی پورٹ پبلش نہیں کرتا، اس لیے یہ صرف اندرونی Docker نیٹ ورک پر موجود رہتا ہے۔ اسے اسی طرح رہنے دیں۔

اگر آپ کی سائٹس کے پاس static پبلک ایڈریسز ہیں، تو صرف انہیں اجازت دیں:

sudo ufw allow OpenSSH
sudo ufw allow proto tcp from 203.0.113.4 to any port 8080
sudo ufw allow proto udp from 203.0.113.4 to any port 3478
sudo ufw enable
sudo ufw status verbose

VPS فائر وال کے لیے ufw کی بنیادی باتیں میں وہ ڈیفالٹ ڈینائی سیٹ اپ شامل ہے جسے یہ رولز فرض کرتے ہیں۔

یہاں ایک ایسی غلطی ہے جس میں لوگ اکثر پھنس جاتے ہیں۔ Docker کی پبلش کردہ ports ufw کو بائی پاس کر دیتی ہیں۔ پورٹ پبلش کرنے سے NAT اور فارورڈنگ رولز براہ راست iptables میں لکھے جاتے ہیں، اور وہ ٹریفک Docker کی اپنی چین میں فلٹر ہوتی ہے، نہ کہ ufw کے زیر انتظام INPUT چین میں۔ اس لیے ufw deny 8443، ufw status میں درست دکھائی دے سکتا ہے جبکہ پورٹ دنیا کے لیے کھلی رہتی ہے۔ اسے کسی دوسری مشین سے ٹیسٹ کریں، کبھی بھی خود VPS سے نہیں:

nc -vz vps.example.com 8443

آپ کو کنکشن ریفیوزل یا ٹائم آؤٹ درکار ہے۔ اگر یہ کنیکٹ ہو جائے، تو ufw کچھ بھی کہے، پورٹ پبلک ہے۔ قابل اعتماد حل وہی ہے جو پہلے سے compose فائل میں موجود ہے: پورٹ کو 127.0.0.1 یا ٹنل ایڈریس پر پبلش کریں، تاکہ Docker اسے کبھی بھی پبلک انٹرفیس پر بائنڈ نہ کرے۔ DOCKER-USER چین میں ایک رول بھی کام کرتا ہے، لیکن بائنڈنگ زیادہ سادہ ہے، اور رول کی ترتیب میں غلطی اسے ختم نہیں کر سکتی۔

Ubiquiti کے اپنے انسٹالرز کے بارے میں کیا خیال ہے؟

Ubiquiti نیٹ ورک ایپلیکیشن کے لیے ایک Debian پیکیج شائع کرتا ہے۔ یہ کام کرتا ہے، لیکن موجودہ Ubuntu پر یہ MongoDB کا ایسا سوال اٹھاتا ہے جس کا جواب اب ڈسٹری بیوشن کے پاس نہیں ہے: Ubuntu 22.04 اور 24.04 میں کوئی MongoDB سرور پیکیج شامل نہیں ہے، لہذا آپ کو خود MongoDB کی اپنی ریپوزٹری شامل کرنی پڑتی ہے اور ورژنز کو دستی طور پر ملانا پڑتا ہے۔ اوپر دیا گیا کنٹینر اس میچنگ کو ایک پن شدہ ٹیگ میں مکمل کرتا ہے، اسی لیے یہاں یہی طریقہ اختیار کیا گیا ہے۔

Ubiquiti کی نئی self-hosted پروڈکٹ UniFi OS Server ہے، جو UniFi ایپلیکیشنز کو Podman کنٹینرز میں چلاتی ہے اور آپ کو وہی UniFi OS فراہم کرتی ہے جو ان کے ہارڈویئر کنسولز میں ہوتا ہے۔ اگست 2026 تک، اسے x86_64 Ubuntu 22.04 یا 24.04، Podman 4.3.1 یا اس سے نیا ورژن بمعہ slirp4netns درکار ہوتا ہے، اور یہ کم از کم 2 vCPU کے ساتھ 4 GB RAM، جبکہ تجویز کردہ 4 vCPU کے ساتھ 8 GB RAM کا تقاضا کرتا ہے۔ انسٹالر ان کے ڈاؤن لوڈز کے صفحے پر ایک مفت Ubiquiti اکاؤنٹ کے پیچھے موجود ہے، لہذا گائیڈ میں پیسٹ کرنے کے لیے کوئی مستقل ایک لائن والا URL موجود نہیں ہے۔ یہ uosserver نامی ایک سسٹم صارف بناتا ہے اور کنٹینرز کو اسی صارف کے طور پر چلاتا ہے۔ اگر آپ وینڈر کی اپنی پیکیجنگ چاہتے ہیں تو اس کا انتخاب کریں۔ اگر آپ ورژنز کو خود کنٹرول کرنا چاہتے ہیں اور سرور کو دیگر کاموں کے لیے آزاد رکھنا چاہتے ہیں تو کنٹینر اسٹیک کا انتخاب کریں۔

UniFi بیک اپ کہاں محفوظ ہوتے ہیں، اور انہیں سرور سے کیسے حاصل کیا جائے

Controller آپ کی مقرر کردہ Settings کے مطابق، backup سیکشن میں شیڈول کے تحت اپنے بیک اپ خود تیار کرتا ہے، اور یہ بھی طے کرتا ہے کہ کتنے بیک اپ محفوظ رکھنے ہیں۔ یہ فائلیں کنٹینر کے اندر /config/data/backup/autobackup میں محفوظ ہوتی ہیں، جو ہوسٹ پر ~/unifi/config/data/backup/autobackup کے مقام پر موجود ہوتی ہیں، اور ان کا نام autobackup_10.5.67_20260813_1200_1755086400004.unf جیسا ہوتا ہے۔

تصدیق کریں کہ آیا وہ وہاں موجود ہیں:

ls -l ~/unifi/config/data/backup/autobackup

شیڈول سیٹ کرنے کے ایک دن بعد اگر ڈائریکٹری خالی ہو تو یہ نئے کنٹینر انسٹالیشنز میں ایک معلوم مسئلہ ہے۔ ایپلیکیشن توقع کرتی ہے کہ autobackup ڈائریکٹری پہلے سے موجود ہو، لیکن یہ اسے خود تخلیق نہیں کرتی، جس کی وجہ سے شیڈولڈ جاب خاموشی سے کچھ بھی رائٹ نہیں کرتی۔ اسے اسی صارف کے طور پر خود بنائیں جس کے تحت کنٹینر چل رہا ہے، پھر اگلی رن کا انتظار کریں:

mkdir -p ~/unifi/config/data/backup/autobackup
docker compose restart unifi-network-application

ایک .unf فائل میں سائٹ کی کنفیگریشن اور ایڈمنسٹریٹر اکاؤنٹس موجود ہوتے ہیں، لہذا اسے ایک cryptographic key کی طرح محفوظ رکھیں۔ اس کی کاپیاں اپنے کنٹرول میں موجود مشین پر منتقل کریں اور انہیں نجی رکھیں:

rsync -av you@vps.example.com:~/unifi/config/data/backup/autobackup/ ~/unifi-backups/

Restore کرنا ایک سادہ عمل ہے۔ نئی انسٹالیشن پر سیٹ اپ وزرڈ کا پہلا صفحہ بیک اپ فائل سے بحالی کی پیشکش کرتا ہے، اور چلتا ہوا کنٹرولر بھی اسی سیٹنگز پیج سے بیک اپ لیتا ہے۔ ہمیشہ اسی ورژن یا اس سے نئے ورژن میں بحال کریں۔ اگر بیک اپ کسی نئے ورژن کی ایپلیکیشن سے لیا گیا ہو اور آپ اسے پرانے ورژن میں بحال کرنے کی کوشش کریں تو وہ مسترد ہو جائے گا، اسی لیے فائل کے ساتھ ورژن نمبر کو نوٹ کرنا ضروری ہے۔

کنٹرولر اپ گریڈ سے کیا خراب ہو سکتا ہے

ہر اپ گریڈ سے پہلے دستی بیک اپ لیں اور اسے ڈاؤن لوڈ کریں۔ پھر:

docker compose pull
docker compose up -d
docker compose logs -f unifi-network-application

ڈیٹا بیس سب سے پہلے متاثر ہونے والی چیز ہے۔ ایپلیکیشن میں ترمیم کے دوران ہی mongo ٹیگ کو نئے میجر ورژن میں تبدیل کرنا کنٹرولر کے شروع نہ ہونے کا تیز ترین راستہ ہے، کیونکہ MongoDB بغیر مرحلہ وار اپ گریڈ کے مختلف میجر ورژن کی ڈیٹا فائلز نہیں کھولتا۔ ایپلیکیشن کو الگ سے اپ گریڈ کریں۔ MongoDB کو الگ سے، ایک وقت میں ایک میجر ورژن کے حساب سے، اور ہاتھ میں تازہ بیک اپ کے ساتھ اپ گریڈ کریں۔

میموری اگلی اہم چیز ہے۔ ایک بڑے ریلیز کو بڑے ہیپ (heap) کی ضرورت ہوتی ہے۔ اگر ایپلیکیشن شروع ہو کر چند منٹ چلنے کے بعد بند ہو جائے، تو MEM_LIMIT اور MEM_STARTUP کو 1536 یا 2048 تک بڑھائیں اور دوبارہ شروع کریں۔ ہوسٹ پر dmesg -T | grep -i 'killed process' سے تصدیق ہوتی ہے کہ آیا کرنل اسے بند کر رہا ہے۔

ڈیوائس فرم ویئر وہ خطرہ ہے جسے لوگ بھول جاتے ہیں۔ کنٹرولر کے خود کو اپ گریڈ کرنے کے بعد، یہ منسلک ڈیوائسز کے لیے فرم ویئر اپ گریڈ پیش کرتا ہے۔ انہیں ایک ہی سیشن میں قبول نہ کریں۔ اگر ڈیوائس اپ گریڈ اور کنٹرولر اپ گریڈ ایک ساتھ ہوں اور ان کے درمیان رابطہ منقطع ہو جائے، تو ڈیوائس آدھی کنفیگرڈ حالت میں پھنس سکتی ہے، اور آپ کو دوسری عمارت میں موجود ہارڈویئر پر SSH کے ذریعے set-inform کرنا پڑے گا۔

اپ گریڈ کا دورانیہ سننے میں جتنا لگتا ہے اس سے کہیں زیادہ پرسکون ہوتا ہے۔ کنٹرولر کے ری سٹارٹ ہونے کے دوران ڈیوائسز ٹریفک فارورڈ کرتی رہتی ہیں، اس لیے صارفین کو کچھ محسوس نہیں ہوتا۔ جو چیز رک جاتی ہے وہ گیسٹ پورٹل اور RADIUS ہے اگر کنٹرولر انہیں فراہم کر رہا ہو، لہذا ایسا وقت منتخب کریں جب ان میں سے کوئی بھی استعمال نہ ہو رہا ہو۔ رات کے 3 بجے خاموشی سے بند ہونے والے کنٹرولر کے بارے میں جاننا ضروری ہے، اس لیے Uptime Kuma سٹیٹس مانیٹر کو پورٹ 8080 پر پوائنٹ کریں اور اسے آپ کو مطلع کرنے دیں۔

ایک دیانتدار متبادل: Ubiquiti کا hosted console

Ubiquiti اسی کام کو بطور سروس فروخت کرتا ہے۔ اگست 2026 تک، Official UniFi Cloud Console کی قیمت 29 ڈالر ماہانہ سے شروع ہوتی ہے اور یہ 500 تک UniFi ڈیوائسز کو manage کر سکتا ہے، جس میں Ubiquiti خود اپ ڈیٹس اور بیک اپس کو سنبھالتا ہے۔ وہ self-hosted ایپلیکیشن جو آپ نے ابھی انسٹال کی ہے، مفت ہے اور اس پر کوئی سبسکرپشن لاگو نہیں ہوتی۔

اگر آپ ایک سائٹ manage کرتے ہیں اور پیچنگ (patching) کے بجائے ادائیگی کو ترجیح دیتے ہیں تو hosted console کا انتخاب کریں۔ اگر آپ کئی سائٹس manage کرتے ہیں، یا آپ چاہتے ہیں کہ کنٹرولر آپ کے اپنے کنٹرول والے نیٹ ورک میں ہو اور ان دیگر سروسز کے ساتھ ایک ہی باکس پر چلے جو آپ چلا رہے ہیں، تو VPS کا انتخاب کریں۔ چھوٹے پیمانے پر قیمت کا فرق حقیقی ہے، لیکن یہ واحد چیز نہیں ہے جس پر غور کیا جائے: hosted console کسی اور کی uptime ہے، اور آپ کا VPS آپ کا اپنا ہے، بشمول وہ رات جب اس کی ڈسک بھر جاتی ہے۔ اگر باکس کو بہرحال اپنی لاگت پوری کرنی ہے، تو آپ VPS پر اور کیا چلا سکتے ہیں وہ فہرست ہے جسے آپ کو آگے پڑھنا چاہیے۔

FAQ

میرا UniFi آلہ VPS پر موجود کنٹرولر کے ساتھ کیوں منسلک (adopt) نہیں ہو رہا؟

آلات UDP پورٹ 10001 پر براڈکاسٹ کے ذریعے کنٹرولر کو تلاش کرتے ہیں، اور براڈکاسٹ کبھی بھی مقامی نیٹ ورک سے باہر نہیں جاتی، اس لیے دور دراز مقام پر موجود آلہ عوامی انٹرنیٹ پر موجود کنٹرولر کو نہیں ڈھونڈ سکتا۔ کنٹرولر کی سسٹم سیٹنگز میں inform host override کو اپنے VPS کے ہوسٹ نیم پر سیٹ کریں، پھر آلے پر ssh ubnt@<device-ip> کے بعد set-inform http://vps.example.com:8080/inform کمانڈ چلائیں۔ اگر آلہ Adopting کی حالت میں پھنس جائے تو اس دوران دوبارہ set-inform چلائیں۔ اگر اسے پہلے کسی اور کنٹرولر نے adopt کیا تھا تو اسے پہلے فیکٹری ڈیفالٹ پر ری سیٹ کریں، کیونکہ اس میں پرانے کنٹرولر کی اسناد موجود ہوتی ہیں۔

سیلف ہوسٹڈ UniFi کنٹرولر کو کتنی RAM درکار ہوتی ہے؟

2 GB کم از کم ضرورت ہے اور 4 GB پر یہ آرام سے چلتا ہے۔ یہ ایپلیکیشن Java اور MongoDB پر مشتمل ہے، اور دونوں اپنی میموری کا سائز الگ الگ طے کرتے ہیں: کنٹینر امیج بائی ڈیفالٹ Java ہیپ کو 1024 MB تک محدود رکھتا ہے، جبکہ MongoDB کا WiredTiger کیشے 1 GB سے اوپر والی RAM کا نصف حصہ استعمال کرتا ہے۔ x86_64 پر یہ بھی تصدیق کریں کہ CPU میں grep -m1 -o avx /proc/cpuinfo کے ذریعے AVX سپورٹ موجود ہے، کیونکہ MongoDB 5.0 اور اس کے بعد کے ورژنز اس کے بغیر شروع نہیں ہوں گے اور ڈیٹا بیس کنٹینر ری اسٹارٹ لوپ میں پھنس جائے گا۔

کیا مجھے پورٹ 8443 کو انٹرنیٹ پر کھولنا چاہیے؟

نہیں۔ پورٹ 8443 ایڈمن انٹرفیس ہے، اور اس میں کنٹرولر کے زیر انتظام تمام سائٹس کی کنفیگریشن موجود ہوتی ہے۔ اسے 127.0.0.1 پر پبلش کریں اور ssh -L 8443:127.0.0.1:8443 you@vps.example.com کے ذریعے رسائی حاصل کریں، یا اسے WireGuard یا Tailscale ایڈریس پر بائنڈ کریں۔ صرف TCP 8080 اور UDP 3478 کو آپ کی سائٹس سے قابل رسائی ہونا چاہیے، اور اگر سائٹس کے IP ایڈریسز سٹیٹک ہوں تو آپ انہیں صرف ان تک محدود کر سکتے ہیں۔ یاد رکھیں کہ Docker کی پبلش کردہ پورٹ ufw سے فلٹر نہیں ہوتی، اس لیے ufw status پر بھروسہ کرنے کے بجائے باہر کی کسی مشین سے ٹیسٹ کریں۔

کیا VPS کنٹرولر کے بند ہونے سے میرا نیٹ ورک کام کرنا چھوڑ دے گا؟

نہیں۔ adopt شدہ ایکسس پوائنٹس اور سوئچز اس کنفیگریشن کا استعمال کرتے ہوئے ٹریفک فارورڈ کرتے رہتے ہیں جو کنٹرولر پہلے ہی بھیج چکا ہوتا ہے، اس لیے کلائنٹس منسلک رہتے ہیں اور Wi-Fi کام کرتا رہتا ہے۔ جو چیز رک جاتی ہے وہ مینجمنٹ ہے۔ آپ ڈیش بورڈ اور شماریات (statistics) تک رسائی کھو دیتے ہیں، نیز کنٹرولر کی فراہم کردہ کوئی بھی لائیو فیچر، جیسے گیسٹ پورٹل کی تصدیق یا RADIUS (اگر کنٹرولر ہی RADIUS سرور ہو) کام نہیں کرے گا۔

UniFi کنٹرولر اپنے خودکار بیک اپ کہاں محفوظ کرتا ہے؟

یہاں استعمال ہونے والے کنٹینر امیج میں یہ /config/data/backup/autobackup میں محفوظ ہوتے ہیں، جو ہوسٹ پر آپ کے ڈیٹا پاتھ اور data/backup/autobackup سے منسلک ہوتا ہے، جہاں یہ .unf فائلیں ورژن اور ٹائم اسٹیمپ کے نام سے محفوظ ہوتی ہیں۔ کچھ نئی تنصیبات میں autobackup ڈائریکٹری موجود نہیں ہوتی، اور شیڈول شدہ بیک اپ بغیر کسی ایرر کے کچھ بھی نہیں لکھتا، اس لیے شیڈول سیٹ کرنے کے ایک دن بعد اس ڈائریکٹری کو چیک کریں اور اگر یہ خالی ہو تو اسے خود بنائیں۔ فائلوں کو VPS سے باہر کاپی کر لیں، کیونکہ .unf میں سائٹ کی کنفیگریشن اور ایڈمنسٹریٹر اکاؤنٹس موجود ہوتے ہیں۔

#unifi#ubiquiti#network-management#docker #self-hosting