Port forwarding के बिना SQL Server से कैसे जुड़ें

Port 1433 forward करने से क्यों बचना चाहिए

Office में एक SQL Server है। उस network के बाहर कोई — remote analyst, कोई cloud reporting tool, या वह app जो आपकी team बनाना चाहती है — उसे पढ़ना चाहता है। हर कोई जो जल्दी वाला हल सुझाता है: router पर TCP port 1433 को database server पर forward करो और firewall में allow कर दो।

यह चलता है, और जल्दी चलता है। लेकिन यही वह तरीका है जिसके लिए लगभग हर security expert मना करेगा:

• आपकी login screen public हो जाती है। Internet पर कुछ भी SQL Server तक पहुँचकर login करने की कोशिश कर सकता है। Automated scanners दिन-रात खुला 1433 ढूँढते हैं और sa जैसे accounts पर password lists आज़माते हैं।
• Database ही आपकी सीमा बन जाता है। हर pending patch और हर कमज़ोर SQL login अब बाहर से पहुँच में है।
• IP allowlist मदद करती है, पर नाज़ुक है। 1433 को किसी vendor के IPs तक सीमित करने से exposure घटता है, लेकिन IPs बदलते हैं और किसी को list संभालनी पड़ती है।

आप असल में यह चाहते हैं कि बाहर की कोई चीज़ वह database बिना किसी inbound port के पढ़ सके। इसके चार तरीके हैं।

विकल्प 1: VPN

VPN बाहर वाले को आपके network के "अंदर" ले आता है। Client VPN किसी व्यक्ति का laptop जोड़ता है; site-to-site VPN दो networks को हमेशा के लिए जोड़ता है।

लोगों के लिए अच्छा। SQL Server Management Studio चलाने वाला remote accountant ठीक वही case है जिसके लिए VPN बने हैं।

SaaS tools के लिए नहीं। ज़्यादातर cloud services आपके VPN में join नहीं कर सकतीं। और VPN gateway खुद आमतौर पर एक inbound port पर सुनता है — आप exposed database की जगह एक exposed (हालाँकि कहीं ज़्यादा मज़बूत) VPN endpoint ले लेते हैं।

विकल्प 2: Bastion host के ज़रिए SSH tunnel

कई cloud tools "SSH tunnel से connect करें" का option देते हैं। आप एक छोटी Linux machine (bastion) चलाते हैं जिसमें tool SSH से आता है, और SQL Server तक का traffic उसी session से गुज़रता है।

बहुत जगह supported, और key-based SSH जाना-पहचाना, अच्छी तरह जाँचा हुआ protocol है।

दिक्कत: फिर भी एक inbound port — आमतौर पर 22 — internet या vendor के IPs के लिए खोलना पड़ता है, उस machine पर जिसे अब आपको patch और monitor करना है। बिना public address वाले office के लिए यह ठीक नहीं बैठता, क्योंकि bastion बाहर से reachable होना चाहिए।

विकल्प 3: Outbound tunnel (Cloudflare Tunnel, ngrok, Tailscale)

Outbound tunnels दिशा उलट देते हैं: आपके network के अंदर एक छोटी process बाहर की ओर connect करती है, और traffic उसी outbound connection से लौटता है।

• Cloudflare Tunnel आपके network में cloudflared चलाता है, सिर्फ़ Cloudflare की ओर outbound connections बनाता है, और access policies से आप तय करते हैं कौन पहुँचे।
• ngrok एक outbound connection खोलकर आपको public endpoint देता है जो local service तक forward करता है। Testing के लिए आसान, लेकिन access controls न लगाएँ तो वह endpoint internet से पहुँच में रहता है।
• Tailscale आपके enroll किए devices के बीच WireGuard का private network बनाता है। सिर्फ़ आपके network के members SQL Server तक पहुँचते हैं।

न inbound rule, न public IP की ज़रूरत। ऐसे office में भी चलते हैं जिसके पास दोनों में से कुछ नहीं।

लेकिन यह network access है, database access नहीं। जो भी tunnel तक पहुँचे, वह अपने login की permissions से SQL Server से बात करता है। Policies, logins और monitoring आपकी ज़िम्मेदारी रहती है। और दूसरी तरफ़ के SaaS tool को tunnel इस्तेमाल करना आना चाहिए — कई को नहीं आता।

विकल्प 4: बाहर की ओर जुड़ने वाला vendor agent

कुछ products इसी काम के लिए अपना agent देते हैं। आप उसे ऐसी machine पर install करते हैं जो database देख सकती है; वह vendor के cloud से बाहर की ओर जुड़ता है, और product उसी connection से queries भेजता है।

• Microsoft का on-premises data gateway सबसे जाना-माना है। यह Windows पर चलता है, Azure की ओर outbound जुड़ता है, और Power BI, Power Apps, Power Automate और Logic Apps को serve करता है। अगर आपकी team Microsoft stack में है, तो यही default choice है। (हमने इसे on-premises data gateway alternative guide में विस्तार से compare किया है।)
• AgentUI Connector AgentUI apps और dashboards के लिए यही करता है, जानबूझकर सीमित दायरे के साथ।

यह साफ़-सुथरा क्यों है: कोई inbound port नहीं, public address की ज़रूरत नहीं, और agent सिर्फ़ उसी vendor के products के लिए काम करता है, इसलिए कोई general network रास्ता नहीं जिसकी चिंता करनी पड़े।

कीमत: हर agent सिर्फ़ अपने vendor के products के लिए है, और आप vendor के agent पर भरोसा कर रहे हैं — install करने से पहले पढ़ लें कि वह क्या कर सकता है और क्या नहीं।

आमने-सामने

अगर मकसद उस data पर apps और dashboards है

अगर आपको असल में office database पर internal tools, reports या dashboards चाहिए, तो tunnel से ज़्यादा connector मायने रखता है। इसी के लिए बना है AgentUI का on-premise SQL Server connector:

• सिर्फ़ outbound। Port 443 पर HTTPS से बाहर जुड़ता है। कोई inbound rule नहीं, firewall में बदलाव नहीं, public address नहीं।
• Read-only। सिर्फ़ SELECT और WITH queries चलती हैं, और हर query बाद में roll back होती है।
• Password अपनी जगह रहता है। सिर्फ़ उसी server पर stored (Windows पर encrypted)। AgentUI के पास connector key का बस एक fingerprint रहता है।
• Revoke हो सकता है। दो clicks में revoke करें; key 25 seconds के अंदर काम करना बंद कर देती है।
• सीमाएँ। सिर्फ़ Microsoft SQL Server। Queries ज़रूरत पर चलती हैं, हर एक 1,000 rows और 30 seconds तक। Database को copy या sync नहीं करता।

यह Windows, macOS या Linux पर service के रूप में install होता है। एक आम case है Windows server पर SAP Business One। अगर आप इस मामले में app builders compare कर रहे हैं, तो हमने यह भी लिखा है कि Retool on-premise SQL Server से कैसे जुड़ता है।

कौन सा चुनें?

• किसी व्यक्ति को घर से पूरा access चाहिए: VPN।
• कोई cloud tool सिर्फ़ SSH tunnels support करता है: vendor के IPs तक सीमित एक bastion, और उसे maintain करने वाला एक और server मानें।
• आपकी team access policies संभालने में सहज है और general रास्ता चाहती है: Cloudflare Tunnel या Tailscale जैसा outbound tunnel।
• आप चाहते हैं कि सिर्फ़ एक product data पढ़े: उस product का outbound agent — Power Platform के लिए Microsoft का gateway, AgentUI apps के लिए AgentUI Connector।

अगर आखिरी वाला आपका case है, तो AgentUI Connector से अपना SQL Server जोड़ें। Read-only, और दो clicks में revoke हो जाता है।