Docker container-কে VPN-এর মাধ্যমে রুট করার সঠিক নিয়ম

কেন Docker container-কে VPN-এর মাধ্যমে রুট করলে port-গুলো অদৃশ্য হয়ে যায়

Docker container-কে VPN-এর মাধ্যমে রুট করার জন্য একটি container-কে tunnel-এর দায়িত্ব দিতে হয় এবং অন্যগুলোকে network_mode: "service:gluetun" ব্যবহার করে সেটির network namespace-এর সাথে যুক্ত করতে হয়। এই সংযোগ প্রক্রিয়াটিই ব্যবহারকারীদের বিভ্রান্ত করে। সংযুক্ত container-টির নিজস্ব কোনো network থাকে না, তাই এর published port এবং Docker service-এর নাম আর কাজ করে না। এর পরিবর্তে VPN container-টিতে port-গুলো publish করুন, তাহলে অন্য container-গুলো VPN container-টির নাম ব্যবহার করে অ্যাপটিতে পৌঁছাতে পারবে।

সংযুক্ত container-টিতে কোনো ports: ব্লক রেখে দিলে Docker সেটিকে তৈরি করতেই অস্বীকার করবে:

Error response from daemon: conflicting options: port publishing and the container type network mode

এখানে ব্যবহৃত টুলটি হলো Gluetun, যা একটি container এবং এটি WireGuard বা OpenVPN-এর মাধ্যমে কোনো বাণিজ্যিক VPN (virtual private network) প্রোভাইডারের সাথে যুক্ত হয় এবং নিজস্ব firewall পরিচালনা করে। আগস্ট 2026 অনুযায়ী v3.41.3 release-টি বর্তমান। উদাহরণগুলোতে WireGuard-সহ Mullvad ব্যবহার করা হয়েছে, তাই আপনার প্রোভাইডারের কাছ থেকে একটি account এবং key প্রয়োজন হবে। আপনি যদি নিজের হার্ডওয়্যারে tunnel terminate করতে চান, তবে VPS-এ নিজের WireGuard server চালানো অন্য প্রান্তটি তৈরি করবে এবং Docker-এ wg-easy সেটিকে একটি web interface-এর মাধ্যমে সহজ করে তুলবে।

network_mode: "service:gluetun" আসলে যা করে

প্রতিটি Docker container সাধারণত নিজস্ব network namespace পায়: নিজস্ব interface, routing table, firewall rule এবং listening socket। service: মোড সেই ধাপটি এড়িয়ে যায় এবং gluetun-এর namespace-এর ভেতরে container-টি চালু করে। একটি namespace মানে একটি IP address, যা ছয়টি বিষয় পরিবর্তন করে।

• অ্যাপটির নিজস্ব কোনো address থাকে না। এর address হয় gluetun-এর address।
• অ্যাপটি কোনো Docker network-এর সাথে যুক্ত থাকে না, তাই এর service name কখনো নিবন্ধিত হয় না এবং resolve-ও হয় না। অন্যান্য container-কে অবশ্যই gluetun ব্যবহার করতে হবে।
• namespace-এর ভেতরের container-গুলো localhost-এর মাধ্যমে একে অপরের সাথে যোগাযোগ করে।
• একটি namespace-এর ভেতরে দুটি container একই port-এ listen করতে পারে না। Gluetun-এর নথিপত্রে এ বিষয়ে স্পষ্টভাবে বলা হয়েছে: এর কোনো বিকল্প সমাধান নেই।
• Capabilities একটি container-এর নিজস্ব বিষয়, namespace-এর নয়। Gluetun-এর কাছে NET_ADMIN এবং /dev/net/tun থাকে কারণ এটি tunnel interface তৈরি করে। সংযুক্ত container এগুলো উত্তরাধিকারসূত্রে পায় না।
• Compose এমন কোনো ফাইল গ্রহণ করে না যেখানে একটি service একই সাথে network_mode এবং networks সেট করে। আপনার network-এর সাথে gluetun-কে যুক্ত করুন, তাহলেই অ্যাপটি তার সাথে যুক্ত হয়ে যাবে।

gluetun রিস্টার্ট করলে এর সাথে সংযুক্ত সবকিছু বিচ্ছিন্ন হয়ে যায়। এটি একটি নথিভুক্ত আচরণ, এবং সংযোগ বিচ্ছিন্ন হলে container থেকে বেরিয়ে না গিয়ে gluetun কেন VPN প্রক্রিয়াটি রিস্টার্ট করে, তার কারণও এটি। আপনি নিজে gluetun রিস্টার্ট বা পুনরায় তৈরি করার পর, এর সাথে সংযুক্ত container-গুলোকেও রিস্টার্ট করুন।

যে compose ফাইলটি কাজ করে

services:
  gluetun:
    image: qmcgaw/gluetun:v3
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    environment:
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - SERVER_CITIES=Amsterdam
      - TZ=Europe/Amsterdam
    env_file:
      - ./gluetun.env
    volumes:
      - ./gluetun:/gluetun
    ports:
      - 127.0.0.1:8080:8080/tcp
    restart: unless-stopped

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - WEBUI_PORT=8080
    volumes:
      - ./qbittorrent:/config
      - ./downloads:/downloads
    depends_on:
      gluetun:
        condition: service_healthy
    restart: unless-stopped

:v3 ট্যাগটি v3 সিরিজের সর্বশেষ স্থিতিশীল রিলিজ। :latest ট্যাগটি master ব্রাঞ্চের সর্বশেষ কমিট নির্দেশ করে, যা মূলত ডেভেলপমেন্ট ভার্সন। তাই এমন কোনো মেশিনে :v3 ব্যবহার করবেন না যেখানে আপনি ঝামেলা এড়াতে চান।

WEBUI_PORT=8080 অবশ্যই প্রকাশিত পোর্টের সাথে মিলতে হবে, কারণ qBittorrent সরাসরি gluetun-এর নেমস্পেসের ভেতরে বাইন্ড হয় এবং পাবলিশ রুল হোস্ট ট্রাফিককে সেখানে 8080 পোর্টে পাঠায়। একটি সংখ্যা পরিবর্তন করে অন্যটি না করলে পোর্টটি কোনো সাড়া দেবে না। 127.0.0.1:8080:8080 ওয়েব ইন্টারফেসটিকে হোস্টের লুপব্যাক অ্যাড্রেসে সীমাবদ্ধ রাখে। সাধারণ 8080:8080 ব্যবহার করলে তা প্রতিটি ইন্টারফেসে পোর্ট পাবলিশ করে এবং নিজস্ব ফায়ারওয়াল রুল তৈরি করে, যার ফলে Docker published ports slip straight past ufw-এর মতো সমস্যা হতে পারে।

সার্ভিসটি চালু করুন এবং নিচের ক্রমানুসারে পরীক্ষা করুন:

docker compose up -d
docker compose ps
docker compose logs gluetun | tail -30

docker compose ps কমান্ডটি gluetun-কে healthy এবং qbittorrent-কে running হিসেবে দেখাবে। এরপর নেমস্পেসের ভেতর থেকে এক্সিট অ্যাড্রেস নিশ্চিত করুন, যা বাকি সবকিছুর কার্যকারিতা নির্ধারণ করে:

docker run --rm --network=container:gluetun alpine:3.22 sh -c "apk add wget && wget -qO- https://ipinfo.io"

সেই JSON-এর ip ফিল্ডে আপনার VPN প্রোভাইডারের অ্যাড্রেস থাকা উচিত। যদি সেখানে আপনার সার্ভারের নিজস্ব অ্যাড্রেস দেখা যায়, তবে অ্যাপটি টানেলের ভেতরে নেই এবং পরবর্তী কোনো কিছুই বর্ণিত নিয়ম অনুযায়ী কাজ করবে না।

Compose file-এর বাইরে কী (keys) রাখুন

gluetun.env-এ ক্রেডেনশিয়াল থাকে এবং এটি git-এর বাইরে রাখা হয়:

WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU=
WIREGUARD_ADDRESSES=10.64.222.21/32

উভয় মানই আপনার প্রোভাইডারের অ্যাকাউন্ট এরিয়া থেকে জেনারেট করা একটি WireGuard কনফিগারেশন ফাইল থেকে আসে। ফাইলটির মোড 600 সেট করুন। এটি আপনাকে কী সুবিধা দেয় সে সম্পর্কে স্বচ্ছ ধারণা থাকা প্রয়োজন: কী (key) আপনার রিপোজিটরির বাইরে থাকে, কিন্তু docker inspect gluetun এখনও Docker socket-এ অ্যাক্সেস আছে এমন যে কাউকে প্রতিটি এনভায়রনমেন্ট ভেরিয়েবল দেখিয়ে দিতে পারে। Docker Compose-এ এনভায়রনমেন্ট ফাইল এবং সিক্রেটস অংশে আরও শক্তিশালী বিকল্পগুলো নিয়ে আলোচনা করা হয়েছে।

টানেলের বাইরের একটি কন্টেইনার কীভাবে ভেতরের কন্টেইনারের সাথে যোগাযোগ করে

উভয় দিক থেকেই যোগাযোগ সম্ভব এবং প্রতিটির জন্য আলাদা নাম ব্যবহার করা হয়। দুটি কন্টেইনারের একটি শেয়ারড Docker network প্রয়োজন, যার অর্থ হলো gluetun-এর নেটওয়ার্ক, কারণ সংযুক্ত কন্টেইনারটির নিজস্ব কোনো নেটওয়ার্ক থাকে না। Docker Compose নেটওয়ার্ক কীভাবে কাজ করে অংশে ডিফল্ট সেটিংস নিয়ে আলোচনা করা হয়েছে।

বাইরে থেকে ভেতরে যোগাযোগের জন্য, gluetun-এর নাম এবং অ্যাপটি যে পোর্টে লিসেন করছে তা ব্যবহার করুন। একটি রিভার্স প্রক্সি কন্টেইনার gluetun:8080 ঠিকানায় qBittorrent ওয়েব ইন্টারফেসে পৌঁছাতে পারে। এর জন্য কোনো ports: এন্ট্রির প্রয়োজন নেই, কারণ কন্টেইনার থেকে কন্টেইনারের ট্রাফিক Docker নেটওয়ার্কেই সীমাবদ্ধ থাকে এবং হোস্ট পোর্টে পৌঁছায় না।

ভেতর থেকে বাইরে যোগাযোগের জন্য, অন্য কন্টেইনারের সার্ভিস নাম ব্যবহার করুন, যেমন postgres:5432। v3.41 ভার্সন থেকে gluetun তার নেমস্পেসের ভেতর থেকে অন্য কন্টেইনারের নাম রিজলভ করতে পারে, তাই যদি কোনো নাম রিজলভ না হয় তবে সেই ভার্সন বা তার পরবর্তী ভার্সন ব্যবহার করুন।

gluetun-এর ফায়ারওয়াল নির্ধারণ করে কারা এর সাথে সংযোগ স্থাপন করতে পারবে। gluetun-এর নিজস্ব Docker নেটওয়ার্ক থেকে আসা ট্রাফিক অনুমোদিত। ভিন্ন সাবনেটের কোনো ক্লায়েন্ট, আপনার LAN-এর কোনো ল্যাপটপ বা আলাদা ব্রিজ নেটওয়ার্কের কোনো কন্টেইনারের সংযোগ ড্রপ করা হবে, যতক্ষণ না আপনি সেই সাবনেটের নাম উল্লেখ করছেন:

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

ডকুমেন্টেশনে উল্লিখিত অর্থটি সুনির্দিষ্ট: কমা দ্বারা পৃথক করা সাবনেটগুলো, যেগুলোতে gluetun এবং এর নেটওয়ার্ক স্ট্যাক শেয়ার করা কন্টেইনারগুলো অ্যাক্সেস করতে পারবে।

ইন্টারনেট থেকে ইনবাউন্ড সংযোগ একটি ভিন্ন সমস্যা। টরেন্ট ক্লায়েন্টের পিয়াররা VPN সাইড থেকে আসে, তাই হোস্টে 6881 পোর্ট পাবলিশ করলে তাদের জন্য কোনো কাজ হয় না। আপনার প্রোভাইডারের কাছ থেকে একটি ফরওয়ার্ডেড পোর্ট প্রয়োজন এবং সেই পোর্টটি FIREWALL_VPN_INPUT_PORTS-এ তালিকাভুক্ত থাকতে হবে, যা VPN সার্ভার সাইড থেকে পোর্টগুলোকে অনুমতি দেয়। এটিই সেই অংশ যা Docker Compose দিয়ে তৈরি মিডিয়া স্ট্যাকগুলোতে প্রায়শই অসম্পূর্ণ থেকে যায়।

কিল সুইচ: টানেল বিচ্ছিন্ন হলে যা ঘটে

এই প্যাটার্নটি ব্যর্থতার সময় তার জটিলতার যথার্থতা প্রমাণ করে। সংযুক্ত কন্টেইনারটির কোনো বিকল্প রুট নেই। মেশিন থেকে বাইরে যাওয়ার একমাত্র পথ হলো সেই নেটওয়ার্ক নেমস্পেস যা এটি শেয়ার করে, তাই টানেল ডাউন হয়ে গেলে ফিরে যাওয়ার আর কোনো পথ থাকে না। Gluetun-এর ফায়ারওয়াল অন্য দিক থেকেও একই নিয়ম কার্যকর করে: আউটবাউন্ড ট্র্যাফিক হয় টানেলের মধ্য দিয়ে যাবে অথবা VPN সার্ভার এন্ডপয়েন্টে যাবে, অন্যথায় সবকিছু ড্রপ করা হবে। ক্লায়েন্ট পুনরায় সংযোগ স্থাপনের সময় সাধারণ ইন্টারফেস দিয়ে প্যাকেট লিক হওয়ার কোনো সুযোগ নেই।

Gluetun তার নিজস্ব সংযোগ পর্যবেক্ষণ করে। প্রতি মিনিটে এটি HEALTH_ICMP_TARGET_IPS-এ থাকা ঠিকানায় একটি ICMP echo (পিং) পাঠায়, যার ডিফল্ট মান হলো 1.1.1.1,8.8.8.8। প্রতি পাঁচ মিনিটে এটি HEALTH_TARGET_ADDRESSES-এ একটি পূর্ণ TCP এবং TLS (transport layer security) ডায়াল করে, যার ডিফল্ট মান cloudflare.com:443,github.com:443। যখন এগুলো ব্যর্থ হয়, তখন এটি কন্টেইনারের ভেতরে থাকা VPN রিস্টার্ট করে এবং তা লগ করে:

WARN [vpn] restarting VPN because it failed to pass the healthcheck: periodic check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout

এই বিষয়টি মাথায় রেখে সংযুক্ত কন্টেইনারের লগগুলো পড়ুন। অ্যাপের ভেতরে connection refused, operation not permitted এবং i/o timeout-এর মতো লাইনগুলো মৃত টানেলের ফলাফল, কারণ নয়। Gluetun-এর ডকুমেন্টেশনে এটি স্পষ্টভাবে বলা আছে, কারণ ব্যবহারকারীরা ফলাফলের রিপোর্ট করেন এবং ঘণ্টার পর ঘণ্টা তার পেছনে সময় নষ্ট করেন।

HEALTH_RESTART_VPN=on হলো ডিফল্ট এবং এটি চালু রাখা উচিত। শুধুমাত্র কোনো নির্দিষ্ট ব্যর্থতা ডিবাগ করার সময় এটি বন্ধ করুন, কারণ এটি বন্ধ থাকলে একটি মৃত টানেল মৃতই থেকে যায়।

অর্ডার করা: টানেল চালু হওয়ার আগে স্ট্যাক চালু হওয়া বন্ধ করা

এই ইমেজে একটি Docker healthcheck দেওয়া থাকে:

HEALTHCHECK --interval=5s --timeout=5s --start-period=10s --retries=1 CMD /gluetun-entrypoint healthcheck

এই কমান্ডটি gluetun-এর একটি দ্বিতীয়, স্বল্পস্থায়ী কপি চালায় যা http://127.0.0.1:9999/-এ চলমান মূল সার্ভারের হেলথ সার্ভারে কুয়েরি পাঠায়। একটি সচল টানেল 200 OK উত্তর দেয়। একটি অচল টানেল একটি এরর স্ট্রিং সহ 500 Internal server error উত্তর দেয় এবং একটি ব্যর্থতার পরেই কন্টেইনারটিকে unhealthy হিসেবে চিহ্নিত করা হয়।

condition: service_healthy মূলত এই অবস্থার জন্যই অপেক্ষা করে। সাধারণ depends_on: [gluetun] শুধুমাত্র কন্টেইনারটি চালু হওয়া পর্যন্ত অপেক্ষা করে, যা হ্যান্ডশেক সম্পন্ন হওয়ার কয়েক সেকেন্ড আগেই ঘটে। ফলে অ্যাপটি একটি অচল নেটওয়ার্কে চালু হয় এবং প্রায়শই প্রথম সংযোগ প্রচেষ্টাতেই ব্যর্থ হয়। Docker Compose-এ হেলথচেক অংশে এর সিনট্যাক্স এবং টাইমিং ফিল্ডগুলো বিস্তারিত আলোচনা করা হয়েছে।

একটি সীমাবদ্ধতা ব্যবহারকারীদের সমস্যায় ফেলে। Compose এই শর্তটি শুধুমাত্র একবার মূল্যায়ন করে, যখন এটি কন্টেইনার তৈরি করে। gluetun পরবর্তীতে unhealthy হয়ে পড়লে এটি অ্যাপটিকে থামায় বা রিস্টার্ট করে না। gluetun-এর অভ্যন্তরীণ অটো-হিলিং এই বিষয়টি সামলায়, যে কারণে এটি কন্টেইনার রিস্টার্ট না করে শুধুমাত্র VPN প্রসেসটি রিস্টার্ট করে।

সেটআপ বিশ্বাস করার আগে DNS leak পরীক্ষা করুন

DNS (domain name system) হলো এমন একটি লিকেজ যা একটি সঠিক টানেল থাকার পরেও থেকে যেতে পারে। Gluetun ডিফল্টভাবে তার নিজস্ব নেমস্পেসের ভেতরে একটি resolver চালায় এবং DoT (DNS over TLS) ব্যবহার করে Cloudflare-এর কাছে কুয়েরি পাঠায়: DNS_UPSTREAM_RESOLVER_TYPE=dot এবং DNS_UPSTREAM_RESOLVERS=cloudflare। এই দুটি সেটিংস পরিবর্তন করবেন না, এতে আপনার লুকআপগুলো এনক্রিপ্ট করা থাকবে এবং টানেলের ভেতর দিয়ে যাবে।

যে সেটিংটি এই সুরক্ষা ভেঙে দেয় তা হলো DNS_UPSTREAM_PLAIN_ADDRESSES। যখন কোনো নাম রিজলভ (resolve) হতে ব্যর্থ হয়, তখন ব্যবহারকারীরা তাদের রাউটার বা প্রোভাইডারের resolver ব্যবহার করার জন্য এটি পরিবর্তন করেন। Gluetun-এর ডকুমেন্টেশনে এর পরিণাম স্পষ্টভাবে বলা আছে: সমস্ত DNS ট্রাফিক VPN টানেলের ভেতর দিয়ে যাবে না এবং টানেলের বাইরে লিক হবে। আপনার ট্রাফিক প্রাইভেট থাকলেও, আপনি কোন কোন হোস্টনেম ভিজিট করছেন তা ফাঁস হয়ে যাবে। WireGuard-এর ক্ষেত্রে একই ভুলের বিষয়টি এখানে আলোচনা করা হয়েছে: DNS that stops resolving over a WireGuard tunnel।

এটি পরীক্ষা করতে, Gluetun-এ HTTPPROXY=on সেট করুন এবং 8888:8888/tcp পাবলিশ করুন। এরপর একটি ব্রাউজারকে সেই প্রক্সির দিকে নির্দেশ করুন এবং একটি DNS leak test লোড করুন। ফলাফলে আপনার VPN প্রোভাইডার বা Cloudflare-এর নাম আসা উচিত, কখনোই আপনার হোম রাউটারের নাম আসা উচিত নয়। Gluetun-এর নিজস্ব ডকুমেন্টেশনে সতর্ক করা হয়েছে যে, কিছু leak টেস্ট অদ্ভুত ফলাফল দেখাতে পারে, কারণ নেমস্পেসের ভেতরের resolverটি একটি লোকাল ক্যাশিং ইন্টারমিডিয়ারি হিসেবে কাজ করে, সরাসরি উত্তরদাতা সার্ভার হিসেবে নয়। যদি ভুল দেশ বা আপনার নিজস্ব ISP-এর resolver দেখায়, তবে সেটিকে একটি বাস্তব সংকেত হিসেবে গণ্য করুন।

VPN sidecar-এর পাশাপাশি Tailscale যোগ করা এবং কোনটি কার্যকর থাকবে

Tailscale হলো WireGuard-এর ওপর ভিত্তি করে তৈরি একটি overlay network, যা আপনার নিজস্ব মেশিনগুলোর সাথে সংযোগ স্থাপনের জন্য ব্যবহৃত হয়। অ্যাডমিন প্যানেলে প্রবেশের পথ খোলা রাখতে অনেকেই এটিকে একটি প্রোভাইডার VPN-এর পাশাপাশি ব্যবহার করেন। এই দুটির মধ্যে খুব কমই বিরোধ ঘটে, যার একটি যৌক্তিক কারণ রয়েছে। Tailscale-এর ডকুমেন্টেশন অনুযায়ী এর ডিফল্ট আচরণ হলো: এটি একটি overlay network হিসেবে কাজ করে, শুধুমাত্র Tailscale চলমান ডিভাইসগুলোর মধ্যে ট্রাফিক রাউট করে এবং এটি আপনার পাবলিক ইন্টারনেট ট্রাফিককে স্পর্শ করে না।

তাই উত্তরটি একটি নির্দিষ্ট সেটিংসের ওপর নির্ভর করে।

• নিজস্ব কন্টেইনারে Tailscale, ডিফল্ট কনফিগারেশন: এটি অ্যাপের আউটবাউন্ড ট্রাফিক দেখতে পায় না। Gluetun এই ট্রাফিকের পুরোটাই বহন করে। Tailscale অন্য যেকোনো বাইরের কন্টেইনারের মতোই gluetun:8080-এ অ্যাপটির সাথে যোগাযোগ করে।
• network_mode: "service:gluetun" ব্যবহার করে gluetun-এর namespace-এ Tailscale যুক্ত করা: এর জন্য নিজস্ব cap_add, net_admin এবং net_raw প্রয়োজন, কারণ namespace-এর সাথে capabilities আসে না। ডিফল্ট userspace networking মোডে, যখন TS_USERSPACE চালু থাকে, তখন tailscaled কোনো ইন্টারফেস তৈরি করে না এবং SOCKS5 বা HTTP proxy হিসেবে কাজ করে, তাই এটি রাউটিং পরিবর্তন করতে পারে না। Gluetun তখনও সবকিছু বহন করে।
• একই কনফিগারেশন, TS_USERSPACE=false সহ: tailscaled একটি tunnel device তৈরি করে এবং রুট ইনস্টল করে, তবে তা শুধুমাত্র tailnet range 100.64.0.0/10 এবং TS_ROUTES দিয়ে আপনার অ্যাডভার্টাইজ করা subnet রুটগুলোর জন্য। পাবলিক ট্রাফিক তখনও gluetun-এর মাধ্যমেই বের হয়।
• উপরের যেকোনো একটির সাথে exit node নির্বাচন করা, sudo tailscale set --exit-node=<exit-node-ip>: Tailscale ডিফল্ট রুটটি দখল করে নেয় এবং কার্যকর থাকে। এটিকে gluetun-এর সাথে একত্রিত করবেন না। ডিফল্ট রুট একটিই থাকে এবং এর মালিকও একজনই হয়।

যদি অ্যাডভার্টাইজ করা রুটগুলোই আপনার মূল উদ্দেশ্য হয় এবং আপনি শুধুমাত্র বক্সটি নয়, বরং বক্সের পেছনের পুরো প্রাইভেট নেটওয়ার্কটি অ্যাক্সেস করতে চান, তবে VPS-এ Tailscale subnet router চালানো বিষয়টি রুট অনুমোদন, IP forwarding এবং ক্লায়েন্ট সাইড ফ্ল্যাগ সম্পর্কে বিস্তারিত আলোচনা করে, যা TS_ROUTES নিজে থেকে সম্পন্ন করে না।

যদি Tailscale-এর উদ্দেশ্য রুট নয় বরং একটি অ্যাডমিন URL প্রদান করা হয়, তবে tailscale serve এবং tailscale funnel আপনার tailnet-এর জন্য gluetun:8080-এর সামনে HTTPS যুক্ত করে, যেখানে শুধুমাত্র funnel এটিকে পাবলিক ইন্টারনেটের জন্য উন্মুক্ত করে।

একটি পার্শ্বপ্রতিক্রিয়া দেখা যায় যখন Tailscale টানেলের ভেতরে চলে। এর peers তখন VPN প্রোভাইডারের ঠিকানা দেখতে পায়, তাই সংযোগটি প্রায়ই relay-এর ওপর নির্ভর করতে পারে। যখন এমনটি ঘটে, তখন tailscale status-এ peer-এর পাশে relay "..." দেখা যায়, direct-এর পরিবর্তে। সংযোগটি কাজ করে কিন্তু ধীরগতির হয়। যদি overlay-ই আপনার একমাত্র প্রয়োজন হয়, তবে সাধারণ WireGuard এবং Tailscale-এর মধ্যে পার্থক্য বিষয়টি দিয়ে শুরু করা ভালো।

কী কী সমস্যা হতে পারে এবং আপনি যে বার্তাগুলো দেখবেন

Docker অ্যাপ কন্টেইনার তৈরি করতে অস্বীকার করে। Error response from daemon: conflicting options: port publishing and the container type network mode এর অর্থ হলো একটি ports: ব্লক এখনও সংযুক্ত সার্ভিসে রয়ে গেছে। এটিকে gluetun-এ সরিয়ে নিন।

Compose পুরো ফাইলটি গ্রহণ করতে অস্বীকার করে। একটি সার্ভিস একই সাথে network_mode এবং networks সেট করতে পারে না। নেটওয়ার্কগুলোকে gluetun-এর অধীনে রাখুন।

অন্য কোনো কন্টেইনার অ্যাপটিকে রিজলভ (resolve) করতে পারে না। curl: (6) Could not resolve host: qbittorrent একটি সঠিক আচরণ, কারণ সংযুক্ত কন্টেইনারটি কোনো নেটওয়ার্কে যোগ দেয়নি এবং কোনো নাম রেজিস্টার করেনি। gluetun এবং পোর্ট ব্যবহার করুন।

দ্বিতীয় সংযুক্ত কন্টেইনারটি চালু হবে না। একই নেমস্পেসের দুটি প্রসেস একই পোর্টে বাইন্ড (bind) করতে পারে না, এবং যে প্রসেসটি ব্যর্থ হয় সেটি জানায় যে অ্যাড্রেসটি ইতিমধ্যে ব্যবহৃত হচ্ছে। অ্যাপের ইন্টারনাল পোর্ট পরিবর্তন করুন অথবা দ্বিতীয় একটি gluetun চালান।

gluetun-এ পরিবর্তন করার পর অ্যাপটির নেটওয়ার্ক সংযোগ বিচ্ছিন্ন হয়ে যায়। gluetun রিস্টার্ট বা পুনরায় তৈরি করলে এর সাথে সংযুক্ত সবকিছুর কানেক্টিভিটি বিচ্ছিন্ন হয়ে যায়। সেই কন্টেইনারগুলোকে রিস্টার্ট করুন।

ছোট পেজ লোড হয় কিন্তু বড় পেজগুলো হ্যাং হয়ে থাকে। এটি MTU (maximum transmission unit)-এর সমস্যা। টানেলটি অতিরিক্ত ডেটা যোগ করে (overhead), এবং পথের কোনো একটি অংশ ত্রুটি বার্তা না পাঠিয়েই বড় প্যাকেটগুলোকে ড্রপ করে দেয়। WIREGUARD_MTU কমিয়ে দেখুন, প্রথমে 1400 এবং তারপর 1320 ট্রাই করুন।

gluetun কখনোই হেলদি (healthy) হয় না। স্টার্টআপ চেক প্রথম সন্দেহভাজনদের নাম বলে দেয়: WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout। কি (key)-এর মেয়াদ শেষ হয়েছে কি না তা পরীক্ষা করুন, তারপর সার্ভার লিস্ট পুরনো কি না দেখুন, এবং সবশেষে আপনার হোস্ট ফায়ারওয়াল আউটবাউন্ড UDP ব্লক করছে কি না তা যাচাই করুন।

FAQ

Gluetun-এর পেছনে আমার কন্টেইনারের পাবলিশ করা পোর্টগুলো কেন কাজ করা বন্ধ করে দিল?

কারণ network_mode: "service:gluetun" কন্টেইনারটিকে Gluetun-এর নেটওয়ার্ক নেমস্পেসের ভেতরে রাখে, আর একটি নেমস্পেসের একটি মাত্র IP অ্যাড্রেস এবং একটি নির্দিষ্ট লিসেনিং পোর্ট সেট থাকে। অ্যাপটি লিসেন করা চালিয়ে যায়, কিন্তু পাবলিশ রুলটি সেই কন্টেইনারে থাকতে হয় যার মালিকানায় নেমস্পেসটি আছে। ports: লিস্টটিকে Gluetun সার্ভিসে সরিয়ে নিন। যদি আপনি এটিকে সংযুক্ত সার্ভিসে রেখে দেন, তবে Docker সেটি তৈরিই করবে না: Error response from daemon: conflicting options: port publishing and the container type network mode।

VPN টানেলের ভেতরের একটি কন্টেইনারে আমি বাইরের কন্টেইনার থেকে কীভাবে পৌঁছাব?

Gluetun-এর সার্ভিস নেম এবং অ্যাপটি যে পোর্টে লিসেন করছে তা ব্যবহার করুন, উদাহরণস্বরূপ gluetun:8080। সংযুক্ত কন্টেইনারটির নিজস্ব কোনো Docker নেটওয়ার্ক নেই, তাই এর নিজস্ব নাম কখনোই রিজলভ হয় না। কন্টেইনার থেকে কন্টেইনার ট্রাফিকের জন্য কোনো কিছু পাবলিশ করার প্রয়োজন নেই। উল্টো দিকে, নেমস্পেসের ভেতরের একটি কন্টেইনার বাইরের একটি কন্টেইনারে তার সার্ভিস নেম দিয়ে পৌঁছাতে পারে, যেমন postgres:5432 (Gluetun v3.41 এবং তার পরবর্তী ভার্সনের ক্ষেত্রে)। ভিন্ন সাবনেটের কোনো ক্লায়েন্ট, যেমন আপনার LAN-এ থাকা একটি ল্যাপটপ, Gluetun-এর ফায়ারওয়াল দ্বারা ড্রপ করা হবে যতক্ষণ না আপনি সেই সাবনেটটিকে FIREWALL_OUTBOUND_SUBNETS-এ যোগ করছেন।

VPN সংযোগ বিচ্ছিন্ন হলে Gluetun কি কিল সুইচ হিসেবে কাজ করে?

হ্যাঁ, এবং একই সাথে দুটি কারণে। সংযুক্ত কন্টেইনারটির শেয়ার্ড নেমস্পেসের রুট ছাড়া অন্য কোনো রুট নেই, তাই টানেল বন্ধ হয়ে গেলে তার মেশিনের বাইরে যাওয়ার কোনো পথ থাকে না। এছাড়া Gluetun-এর ফায়ারওয়াল শুধুমাত্র টানেলের ভেতর দিয়ে এবং VPN সার্ভার এন্ডপয়েন্টের দিকে আউটবাউন্ড ট্রাফিক অনুমোদন করে। Gluetun তখন VPN-কে ইন্টারনালি রিস্টার্ট করে এবং WARN [vpn] restarting VPN because it failed to pass the healthcheck লগ করে, বরং পুরোপুরি বন্ধ হয়ে যায় না, কারণ Gluetun নিজে রিস্টার্ট হলে প্রতিটি সংযুক্ত কন্টেইনার তাদের নেটওয়ার্ক হারিয়ে ফেলে।

একই স্ট্যাকে Tailscale এবং Gluetun থাকলে কোনটি আউটবাউন্ড ট্রাফিক বহন করবে?

একটি কনফিগারেশন ছাড়া বাকি সব ক্ষেত্রে Gluetun। Tailscale ডিফল্টভাবে শুধুমাত্র আপনার tailnet-এর ডিভাইসগুলোর মধ্যে ট্রাফিক রুট করে এবং পাবলিক ট্রাফিককে স্পর্শ করে না। কন্টেইনার ইমেজের ডিফল্ট ইউজারস্পেস মোডে এটি কোনো ইন্টারফেসই তৈরি করে না, তাই এটি রাউটিংকে প্রভাবিত করতে পারে না। TS_USERSPACE=false ব্যবহার করলে এটি শুধুমাত্র 100.64.0.0/10 এবং আপনার অ্যাডভার্টাইজ করা সাবনেটগুলোর জন্য রুট ইনস্টল করে। ব্যতিক্রম হলো এক্সিট নোড: sudo tailscale set --exit-node=<exit-node-ip> ব্যবহার করলে Tailscale ডিফল্ট রুট হয়ে যায় এবং তখন সেটিই কার্যকর থাকে। দুটিকে একসাথে ব্যবহার না করে ডিফল্ট রুটের মালিক হিসেবে যেকোনো একটি প্রোডাক্ট বেছে নিন।