VPN द्वारे Docker कंटेनरचा ट्रॅफिक कसा पाठवायचा

VPN द्वारे Docker कंटेनरचा नेटवर्क ट्रॅफिक पाठवल्यावर ports का अदृश्य होतात

Docker कंटेनरचा ट्रॅफिक VPN द्वारे पाठवण्यासाठी एका कंटेनरला tunnel द्या. त्यानंतर network_mode: "service:gluetun" वापरून इतर कंटेनर त्याच्या network namespace शी जोडा. या जोडणीमुळे अनेकदा गोंधळ होतो. जोडलेला कंटेनर स्वतःचे network गमावतो. त्यामुळे त्याचे published ports आणि Docker service name देखील उपलब्ध राहत नाहीत. Ports VPN कंटेनरवर publish करा. त्यानंतर इतर कंटेनर VPN कंटेनरच्या नावाने त्या अॅपपर्यंत पोहोचू शकतात.

जोडलेल्या कंटेनरमध्ये ports: block ठेवला, तर Docker तो कंटेनर तयार करण्यासच नकार देतो:

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

येथे वापरलेले साधन Gluetun आहे. हे WireGuard किंवा OpenVPN द्वारे commercial VPN (virtual private network) provider शी जोडले जाणारे कंटेनर आहे. त्यात स्वतःचा firewall देखील असतो. August 2026 पर्यंत v3.41.3 ही current release आहे. उदाहरणांमध्ये WireGuard सह Mullvad वापरले आहे. त्यामुळे provider कडील account आणि key आवश्यक आहेत. Tunnel तुमच्या मालकीच्या hardware वर terminate करायचा असल्यास, VPS वर स्वतःचा WireGuard server चालवणे tunnel चे दुसरे टोक तयार करते. तसेच Docker मधील wg-easy त्यासाठी web interface उपलब्ध करून देते.

प्रत्यक्षात network_mode: "service:gluetun" काय करते

प्रत्येक Docker container ला सामान्यतः स्वतःचा network namespace मिळतो: स्वतःचे interfaces, routing table, firewall rules आणि listening sockets. service: mode ही पायरी वगळते आणि container gluetun च्या namespace मध्ये सुरू करते. एका namespace मध्ये एकच IP address असतो आणि त्यामुळे सहा गोष्टी बदलतात.

• अॅपचा स्वतःचा address नसतो. त्याचा address gluetun चा address असतो.
• अॅप कोणत्याही Docker network शी जोडलेले नसते. त्यामुळे त्याचे service name नोंदवले जात नाही आणि ते resolve होत नाही. इतर containers ने gluetun वापरावे.
• namespace मधील containers एकमेकांपर्यंत localhost द्वारे पोहोचतात.
• एका namespace मधील दोन containers एकाच port वर listen करू शकत नाहीत. Gluetun documentation याबाबत स्पष्ट आहे: यावर कोणताही workaround नाही.
• Capabilities या namespace ऐवजी container शी संबंधित असतात. Tunnel interface तयार करत असल्यामुळे Gluetun कडे NET_ADMIN आणि /dev/net/tun असतात. जोडलेल्या container ला त्या inherit होत नाहीत.
• एखाद्या service मध्ये network_mode आणि networks दोन्ही सेट केले असल्यास Compose ती file नाकारते. gluetun ला तुमच्या networks शी जोडा; अॅप त्याच्यासोबत जोडले जाईल.

gluetun restart केल्यास त्याच्याशी जोडलेल्या सर्व गोष्टींचे connection तुटते. हे documented behaviour आहे. Connection अयशस्वी झाल्यावर gluetun container मधील VPN process restart करते आणि स्वतः exit होत नाही, याचे हेच कारण आहे. तुम्ही gluetun स्वतः restart किंवा recreate केल्यानंतर त्याच्याशी जोडलेले containers restart करा.

कार्यरत 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 tag ही v3 मालिकेतील सर्वात नवीन stable release आहे. :latest tag master branch मधील शेवटच्या commit कडे निर्देश करतो. ही development edge आहे. त्यामुळे मंगळवारी debugging करायची इच्छा नसलेल्या मशीनवर :v3 pin करा.

WEBUI_PORT=8080 ने प्रकाशित port शी जुळले पाहिजे. qBittorrent gluetun च्या namespace मध्ये bind होते आणि publish rule host वरील traffic तिथल्या port 8080 कडे पाठवते. एका बाजूचा number बदलून दुसरा न बदलल्यास त्या port वर कोणतेही उत्तर मिळणार नाही. 127.0.0.1:8080:8080 web interface ला host च्या loopback address वर ठेवते. साधे 8080:8080 वापरल्यास ते प्रत्येक interface वर port publish करते आणि स्वतःचा firewall rule लिहिते. त्यामुळे Docker ने प्रकाशित केलेले ports ufw च्या नियमांना थेट वगळतात.

ते सुरू करा. त्यानंतर खालील क्रमाने तपासा:

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

docker compose ps मध्ये gluetun हे healthy आणि qbittorrent हे running म्हणून दिसले पाहिजे. त्यानंतर namespace मधून exit address पडताळा. हीच तपासणी इतर सर्व गोष्टींचा निर्णय घेते:

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

त्या JSON मधील ip field मध्ये तुमच्या VPN provider चा address दिसला पाहिजे. त्याऐवजी तुमच्या server चा स्वतःचा address दिसत असल्यास app tunnel मध्ये नाही. अशा स्थितीत खालीलपैकी कोणतीही गोष्ट वर्णन केल्याप्रमाणे कार्य करणार नाही.

कळा compose file मध्ये ठेवू नका

gluetun.env मध्ये credentials असतात आणि ही फाइल git मध्ये commit केली जात नाही:

WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU=
WIREGUARD_ADDRESSES=10.64.222.21/32

दोन्ही मूल्ये provider च्या account area मध्ये generate केलेल्या WireGuard configuration file मधून येतात. या file ची mode 600 सेट करा. यामुळे नेमके काय साध्य होते, ते स्पष्टपणे समजा: key repository मध्ये राहत नाही; मात्र Docker socket पर्यंत पोहोचू शकणाऱ्या कोणालाही docker inspect gluetun अजूनही प्रत्येक environment variable दाखवते. अधिक मजबूत पर्यायांसाठी Docker Compose मधील environment files आणि secrets पहा.

कंटेनरच्या बाहेरून आत असलेल्या कंटेनरशी संवाद कसा साधावा

दोन्ही दिशांमध्ये संवाद कार्यरत असतो आणि प्रत्येक दिशेसाठी वेगळे नाव वापरले जाते. या दोन कंटेनरना एक समान Docker network आवश्यक असते. संलग्न कंटेनरकडे स्वतःचे network नसल्यामुळे हे gluetun चे network असते. Docker Compose networks कशा जोडल्या जातात यामध्ये default settings स्पष्ट केल्या आहेत.

बाहेरून आत जाताना gluetun चे नाव आणि अॅप ज्या port वर ऐकते तो port वापरा. Reverse proxy container `gluetun:8080 येथे qBittorrent web interface शी जोडला जातो. यासाठी ports:` entry आवश्यक नाही, कारण container-to-container traffic Docker network वरच राहते आणि host port ला स्पर्श करत नाही.

आतून बाहेर जाताना दुसऱ्या container चे service name वापरा, उदाहरणार्थ `postgres:5432`. v3.41 पासून gluetun ने त्याच्या namespace मधून इतर container ची नावे resolve केली आहेत. एखादे नाव resolve होत नसेल, तर ही आवृत्ती किंवा त्यानंतरची आवृत्ती निश्चित करा.

कोणाला gluetun शी connection उघडता येईल हे gluetun चा firewall ठरवतो. gluetun च्या स्वतःच्या Docker network मधून येणारा traffic अनुमत असतो. वेगळ्या subnet वरील client, तुमच्या LAN वरील laptop किंवा स्वतंत्र bridge network वरील container यांना तुम्ही तो subnet स्पष्टपणे नमूद करेपर्यंत traffic नाकारला जातो:

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

दस्तऐवजीकरणातील अर्थ अचूक आहे: Gluetun आणि त्याचा network stack share करणाऱ्या containers ना access करण्याची परवानगी असलेले comma-separated subnets.

Internet कडून येणारे inbound connections ही स्वतंत्र समस्या आहे. Torrent client चे peers VPN बाजूने येतात. त्यामुळे host वर port 6881 publish केल्याने त्यांना काही उपयोग होत नाही. Provider कडून forwarded port आवश्यक आहे. तो port `FIREWALL_VPN_INPUT_PORTS` मध्ये नमूद करा. या setting मुळे VPN server बाजूकडून येणारे ports अनुमत होतात. Docker Compose ने तयार केलेले media stacks बहुतेक वेळा हाच भाग अपूर्ण ठेवतात.

टनेल बंद झाल्यावर काय होते: kill switch

अपयशाच्या स्थितीत या रचनेची गुंतागुंत योग्य ठरते. जोडलेल्या container कडे दुसरा route नसतो. मशीनबाहेर जाण्याचा त्याचा एकमेव मार्ग तो share करत असलेला namespace असतो. त्यामुळे tunnel बंद असताना fallback करण्यासाठी काहीही उपलब्ध नसते. Gluetun चे firewall दुसऱ्या बाजूने हाच नियम लागू करते: outbound traffic tunnel मधून किंवा VPN server endpoint कडे जाते आणि इतर सर्व traffic drop केले जाते. client पुन्हा connect होत असताना packets plain interface मधून बाहेर जाण्याची कोणतीही संधी राहत नाही.

Gluetun स्वतःचे connection monitor करते. प्रत्येक मिनिटाला ते HEALTH_ICMP_TARGET_IPS मधील addresses कडे ICMP echo (ping) पाठवते. यांची default value 1.1.1.1,8.8.8.8 आहे. प्रत्येक पाच मिनिटांनी ते HEALTH_TARGET_ADDRESSES कडे पूर्ण TCP आणि TLS (transport layer security) connection सुरू करते. याची default value cloudflare.com:443,github.com:443 आहे. हे checks अयशस्वी झाल्यावर ते container मधील VPN restart करते आणि त्याची नोंद log मध्ये करते:

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

ही क्रमवारी लक्षात घेऊन जोडलेल्या container चे logs वाचा. app मधील connection refused, operation not permitted आणि i/o timeout यांसारख्या lines dead tunnel चे परिणाम आहेत; कारणे नाहीत. Gluetun च्या documentation मध्ये हे स्पष्टपणे सांगितले आहे, कारण लोक परिणामाची नोंद करून तासन्‌तास त्याचा पाठपुरावा करतात.

HEALTH_RESTART_VPN=on हे default आहे आणि ते on ठेवावे. एखाद्या विशिष्ट failure चे debugging करताना तात्पुरतेच ते off करा, कारण ते off असल्यास dead tunnel तसाच dead राहतो.

क्रम: tunnel सुरू होण्यापूर्वी stack सुरू होऊ नये

या image मध्ये Docker healthcheck समाविष्ट आहे:

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

ही command gluetun ची दुसरी, अल्पकाळ चालणारी प्रत सुरू करते. ती http://127.0.0.1:9999/ वरील चालू gluetun च्या health server ला query करते. Tunnel कार्यरत असल्यास उत्तर 200 OK असते. Tunnel मध्ये बिघाड असल्यास error string सह 500 Internal server error उत्तर मिळते. एकदाच अपयश आल्यावर container ला unhealthy म्हणून चिन्हांकित केले जाते.

condition: service_healthy त्या स्थितीची प्रतीक्षा करते. साधा depends_on: [gluetun] फक्त container सुरू होईपर्यंत प्रतीक्षा करतो. Handshake पूर्ण होण्याच्या काही सेकंद आधीच container सुरू होते. त्यामुळे app network उपलब्ध नसताना सुरू होते आणि पहिल्या connection attempt वर अनेकदा थांबते. Docker Compose मधील healthchecks syntax आणि timing fields स्पष्ट करते.

एक मर्यादा अनेकदा लक्षात येत नाही. Compose container तयार करताना ही condition एकदाच तपासते. नंतर gluetun unhealthy झाल्यास ते app थांबवत किंवा पुन्हा सुरू करत नाही. त्या परिस्थितीसाठी gluetun चे अंतर्गत auto-healing कार्य करते. म्हणून ते container ऐवजी VPN process पुन्हा सुरू करते.

सेटअपवर विश्वास ठेवण्यापूर्वी DNS leak तपासा

DNS (domain name system) हा योग्य tunnel नंतरही टिकून राहणारा leak आहे. Gluetun namespace मध्ये स्वतःचा resolver चालवतो आणि default नुसार DoT (DNS over TLS) द्वारे Cloudflare कडे queries forward करतो: DNS_UPSTREAM_RESOLVER_TYPE=dot आणि DNS_UPSTREAM_RESOLVERS=cloudflare. दोन्ही तसेच ठेवल्यास तुमचे lookups encrypted राहतात आणि tunnel मधून जातात.

ही रचना बिघडवणारी setting म्हणजे DNS_UPSTREAM_PLAIN_ADDRESSES. एखादे नाव resolve होत नसताना आणि त्याऐवजी router किंवा provider च्या resolver कडून उत्तर मिळवायचे असताना लोक ही setting वापरतात. Gluetun documentation मध्ये याची किंमत स्पष्टपणे दिली आहे: सर्व DNS traffic VPN tunnel मधून जाणार नाही आणि tunnel च्या बाहेर leak होईल. तुमचा traffic private राहतो. मात्र hostnames ची यादी private राहत नाही. WireGuard मधील याच चुकीचे वर्णन WireGuard tunnel वर DNS resolve होणे थांबते येथे दिले आहे.

चाचणीसाठी gluetun वर HTTPPROXY=on सेट करा आणि 8888:8888/tcp publish करा. त्यानंतर browser त्या proxy कडे निर्देशित करून DNS leak test उघडा. निकालात तुमचा provider किंवा Cloudflare दिसला पाहिजे; तुमचा home router कधीही दिसू नये. Gluetun च्या documentation नुसार काही leak tests अनपेक्षित निकाल दाखवू शकतात, कारण namespace मधील resolver हा अंतिम उत्तर देणारा server नसून local caching intermediary असतो. चुकीचा देश किंवा तुमच्या ISP चा resolver दिसणे हे खरे संकेत माना.

VPN sidecar च्या शेजारी Tailscale जोडणे आणि कोणते प्राधान्य मिळवते

Tailscale हे WireGuard वर आधारित overlay network आहे. त्याद्वारे स्वतःच्या मशीनपर्यंत पोहोचता येते. अनेक जण stack मध्ये प्रशासकीय प्रवेशाचा मार्ग कायम ठेवण्यासाठी ते provider VPN सोबत चालवतात. ही दोन्ही साधने क्वचितच परस्पर संघर्ष करतात. त्यामागील कारण समजून घेणे महत्त्वाचे आहे. Tailscale च्या documentation नुसार त्याची default वर्तणूक अशी आहे: ते overlay network म्हणून काम करते, फक्त Tailscale चालू असलेल्या devices मधील traffic route करते आणि सार्वजनिक internet traffic ला स्पर्श करत नाही.

म्हणून उत्तर एका setting वर अवलंबून असते.

• Tailscale स्वतःच्या container मध्ये, default configuration सह: ते app चा outbound traffic कधीही पाहत नाही. सर्व traffic Gluetun वाहून नेतो. Tailscale app पर्यंत gluetun:8080 वर पोहोचते, अगदी इतर कोणत्याही बाहेरील container प्रमाणे.
• Tailscale ला network_mode: "service:gluetun" सह gluetun च्या namespace ला जोडल्यास: त्याला net_admin आणि net_raw चे स्वतःचे cap_add आवश्यक असते, कारण namespace सोबत capabilities मिळत नाहीत. Default userspace networking mode मध्ये TS_USERSPACE सुरू असते. tailscaled कोणतेही interface तयार करत नाही आणि SOCKS5 किंवा HTTP proxy म्हणून काम करते. त्यामुळे ते routing बदलू शकत नाही. Gluetun अजूनही सर्व traffic वाहून नेतो.
• त्याच configuration मध्ये TS_USERSPACE=false वापरल्यास: tailscaled tunnel device तयार करते आणि routes स्थापित करते. मात्र हे फक्त tailnet range 100.64.0.0/10 आणि TS_ROUTES सह advertise केलेल्या subnet routes साठी असते. Public traffic अजूनही gluetun मार्फत बाहेर जाते.
• वरीलपैकी कोणत्याही configuration मध्ये exit node निवडल्यास, sudo tailscale set --exit-node=<exit-node-ip>: Tailscale default route ताब्यात घेते आणि त्याला प्राधान्य मिळते. हे gluetun सोबत एकत्र वापरू नका. एक default route आणि एकच मालक असावा.

Tailscale tunnel मध्ये चालत असताना त्याचा एक परिणाम दिसतो. त्याचे peers VPN provider चा address पाहतात. त्यामुळे ते अधिक वेळा relays कडे fallback करतील, अशी अपेक्षा ठेवा. असे झाल्यावर peer च्या शेजारी direct ऐवजी relay "..." असल्याचे tailscale status दाखवते. Connection कार्यरत राहते, पण ती धीमी असते. Overlay हाच तुम्हाला प्रत्यक्षात आवश्यक असलेला एकमेव घटक असल्यास, plain 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 आणि पोर्ट वापरा.

दुसरा जोडलेला कंटेनर सुरू होत नाही. एका namespace मधील दोन प्रक्रिया एकाच पोर्टला bind करू शकत नाहीत. दुसरी प्रक्रिया अयशस्वी होते आणि address already in use असा संदेश देते. अॅपचा अंतर्गत पोर्ट बदला किंवा दुसरा gluetun चालवा.

gluetun मध्ये बदल केल्यानंतर अॅपला नेटवर्क उपलब्ध नाही. gluetun restart किंवा recreate केल्यास त्याच्याशी जोडलेल्या सर्व गोष्टींची connectivity तुटते. ते कंटेनर पुन्हा सुरू करा.

लहान पृष्ठे लोड होतात, पण मोठी पृष्ठे अडकतात. ही MTU (maximum transmission unit) ची समस्या आहे. tunnel मुळे अतिरिक्त overhead येतो आणि मार्गातील एखादी यंत्रणा error परत न पाठवता जास्त आकाराची packets टाकून देते. WIREGUARD_MTU कमी करा, 1400 वापरून पाहा आणि नंतर 1320 वापरून पाहा.

Gluetun कधीही healthy होत नाही. startup check मध्ये प्राथमिक संशयित कारणे दिली जातात: WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout. key ची मुदत संपली आहे का ते तपासा. त्यानंतर server list जुनी आहे का ते तपासा. शेवटी, host firewall मुळे outbound UDP अवरोधित होत आहे का ते तपासा.

FAQ

Gluetun च्या मागे माझ्या container चे published ports काम करणे का थांबले?

कारण network_mode: "service:gluetun" मुळे container Gluetun च्या network namespace मध्ये ठेवला जातो. एका namespace मध्ये एक IP address आणि listening ports चा एकच संच असतो. अॅप listening करत राहते, पण publish rule ही namespace ज्या container च्या मालकीची आहे त्यावर असणे आवश्यक आहे. ports: यादी Gluetun service मध्ये हलवा. ती attached service वर ठेवली असल्यास Docker ती तयारही करणार नाही: Error response from daemon: conflicting options: port publishing and the container type network mode.

VPN tunnel च्या आत असलेल्या container पर्यंत VPN tunnel च्या बाहेरील container मधून कसे पोहोचायचे?

Gluetun चे service name आणि अॅप ज्या port वर listening करते तो port वापरा. उदाहरणार्थ, gluetun:8080. Attached container स्वतःच्या कोणत्याही Docker network वर नसतो. त्यामुळे त्याचे स्वतःचे name resolve होत नाही. Container-to-container traffic साठी publishing आवश्यक नाही. उलट दिशेने, namespace च्या आत असलेला container बाहेरील container पर्यंत त्याच्या service name द्वारे पोहोचू शकतो. उदाहरणार्थ, Gluetun v3.41 आणि त्यानंतरच्या आवृत्त्यांमध्ये postgres:5432. वेगळ्या subnet वरील client, जसे तुमच्या LAN वरील laptop, तुम्ही ते subnet FIREWALL_OUTBOUND_SUBNETS मध्ये जोडत नाही तोपर्यंत Gluetun च्या firewall कडून नाकारला जातो.

VPN बंद पडल्यावर Gluetun kill switch म्हणून काम करते का?

होय. याची दोन कारणे आहेत. Attached container कडे shared namespace मधील route सोडून दुसरा कोणताही route नसतो. त्यामुळे tunnel बंद पडल्यावर त्याच्याकडे machine च्या बाहेर जाण्याचा मार्ग राहत नाही. Gluetun चा firewall outbound traffic फक्त tunnel आणि VPN server endpoint कडे जाण्यास परवानगी देतो. Gluetun नंतर VPN अंतर्गतरीत्या पुन्हा सुरू करते आणि WARN [vpn] restarting VPN because it failed to pass the healthcheck log करते. Gluetun स्वतः restart झाल्यास प्रत्येक attached container चे network नष्ट होते, म्हणून Gluetun बाहेर पडत नाही.

एकाच stack मध्ये Tailscale आणि Gluetun: outbound traffic कोणामार्फत जाते?

एका configuration वगळता प्रत्येक वेळी Gluetun मार्फत. Tailscale default स्वरूपात फक्त तुमच्या tailnet मधील devices दरम्यान traffic route करते आणि public traffic ला तसेच राहू देते. Container image च्या default userspace mode मध्ये ते कोणताही interface तयार करत नाही. त्यामुळे routing वर त्याचा परिणाम होऊ शकत नाही. TS_USERSPACE=false वापरल्यास ते फक्त 100.64.0.0/10 आणि तुम्ही advertise केलेल्या subnets साठी routes स्थापित करते. अपवाद म्हणजे exit node. sudo tailscale set --exit-node=<exit-node-ip> मुळे Tailscale default route बनते आणि त्यानंतर Tailscale ला प्राधान्य मिळते. Default route चे नियंत्रण एका product कडेच ठेवा; दोन्ही product एकावर एक लागू करू नका.