Show HN: WireGuard के लिए Wag मल्टी-फैक्टर ऑथेंटिकेशन और रजिस्ट्रेशन सिस्टम

 (github.com/NHAS)
1 पॉइंट द्वारा GN⁺ 2024-05-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Wag एक प्रोजेक्ट है जो WireGuard में मल्टी-फैक्टर ऑथेंटिकेशन, route restrictions और device registration जोड़ता है, जिससे MFA की जरूरत वाले routes और हमेशा accessible public routes को अलग-अलग किया जा सकता है
  • नए client registration API, high availability, real-time user updates और notifications, Security Key·SSO·PAM·TOTP जैसे कई MFA integrations उपलब्ध कराता है
  • server चलाने के लिए IP forwarding enable होना जरूरी है; manual run के लिए iptables और libpam install करने होंगे, और iptables व WireGuard device management के लिए root execution जरूरी है
  • management web UI और CLI से किया जा सकता है; CLI में start, registration, devices, users, webadmin subcommands हैं, जो registration tokens, device locking, MFA reset और web admin accounts संभालते हैं
  • सीमाओं में प्रति client केवल एक AllowedIP support शामिल है; यह मुख्य रूप से Linux-only है और Windows कुछ अतिरिक्त steps के बाद काम कर सकता है

Wag द्वारा जोड़ी जाने वाली WireGuard capabilities

  • Wag WireGuard में MFA, route restrictions और device registration जोड़ता है
  • routes को MFA authentication की जरूरत वाले paths और हमेशा accessible public routes के रूप में अलग-अलग define किया जा सकता है
  • नए clients को register करने के लिए आसान API देता है
  • high availability, real-time user updates और notifications support करता है
  • MFA integrations में ये methods शामिल हैं
    • Security Key
    • SSO
    • PAM
    • TOTP
  • documentation Documentation पर उपलब्ध है

installation और runtime requirements

  • server पर forwarding enabled होना चाहिए
    • IPv4 के लिए net.ipv4.ip_forward=1 setting इस्तेमाल होती है
    • IPv6 के लिए net.ipv6.conf.all.forwarding=1 जैसी संबंधित sysctl settings इस्तेमाल होती हैं
  • Docker Compose run example में wagvpn/wag:latest image इस्तेमाल होती है
    • management page port example: 4433/tcp
    • public registration page port example: 8081/tcp
    • WireGuard port example: 53230/udp
    • /dev/net/tun device को container से जोड़ा जाता है
  • manual installation के लिए iptables और libpam जरूरी हैं
  • iptables और WireGuard device manage करने के लिए Wag को root के रूप में run करना होगा
  • binary releases के लिए glibc 2.31+ जरूरी है
  • source build के लिए go1.23.1 और npm जरूरी हैं

management methods

  • management UI enable करने के बाद Wag configure करने पर पहला admin बनाया जाता है, और password STDOUT पर output होता है
  • इसके बाद web UI में login करके users manage किए जा सकते हैं
  • root users CLI से Wag server manage कर सकते हैं
  • CLI format wag subcommand [-options] है
  • supported subcommands ये हैं
    • start: Wag server start करता है और daemonize नहीं करता
    • registration: registration token create, delete और list operations संभालता है
    • devices: WireGuard devices की list, delete, lock, unlock और active MFA sessions view करना संभालता है
    • users: user MFA management, user deletion, account locking और MFA reset संभालता है
    • webadmin: web UI admin users add, delete, list, account lock और unlock संभालता है
    • version, firewall भी supported commands में शामिल हैं

registration tokens और MFA flow

  • नया device register करने के लिए पहले wag registration -add -username tester जैसे command से registration token बनाया जाता है
  • बने हुए token को public registration endpoint पर भेजने से WireGuard configuration response मिल सकता है
  • लौटाए गए configuration में Interface, PrivateKey, Address, Peer, Endpoint, PublicKey, AllowedIPs, PersistentKeepAlive जैसी entries शामिल होती हैं
  • user server के VPN address से connect करके 2FA code enter करता है
  • session expire होने तक की duration configuration file में specify की जाती है

web management console

  • management console में login करने के लिए Webserver.Management.Enabled को true set करना होगा
  • console में sudo ./wag webadmin -add -username <your_username> -password <your-password-here> से web admin account add किया जाता है
  • इसके बाद management listening address पर जाकर credentials enter किए जाते हैं
  • web interface खुद admin user add नहीं कर सकता
  • management portal को public internet पर expose न करने की सलाह दी जाती है; ListenAddress को 127.0.0.1 या localhost पर set करके SSH forwarding से expose करने की approach recommended है

key configuration items

  • NumberProxies client के आगे trusted reverse proxies की संख्या specify करता है, जिससे Wag X-Forward-For को ध्यान में रखकर client IP parse करता है
  • Socket Wag control socket है; इसे बदलने से same machine पर कई Wag instances run किए जा सकते हैं
  • NAT masquerading को on/off करता है; enable होने पर सारा traffic ऐसा दिखता है जैसे वह VPN server से शुरू हुआ हो
  • NATExcludeRanges NAT=true होने पर NAT से exclude किए जाने वाले CIDR ranges specify करता है
  • ExposePorts VPN server के ports को clients के लिए expose करता है और iptables rules add करता है
  • CheckUpdates default रूप से off है; enable करने पर management UI नए Wag version notifications दिखाता है और api.github.com access करता है
  • Acls groups और policies define करता है, लेकिन यह सिर्फ पहली run पर लागू होता है; runtime के दौरान web UI से edit किया जाता है
  • Webserver public registration endpoint, tunnel MFA portal और management portal settings शामिल करता है
  • Wireguard device name, listening port, private key, VPN द्वारा handle किया जाने वाला subnet, MTU और DNS servers configure करता है
  • Clustering cluster name, etcd cluster state, log level, witness node, database location और cluster certificate related settings शामिल करता है

ACL policy behavior

  • Policies उन routes को define करता है जिन्हें VPN capture करेगा, और उन ports/protocols को जिन्हें Wag से होकर गुजरने दिया जाएगा
  • rule application subnet prefix length का उपयोग करता है, और सबसे specific match route access level तय करता है
  • उदाहरण के लिए, अगर /16 को MFA के रूप में define किया गया है और उसके अंदर किसी specific /32 को Allow के रूप में define किया गया है, तो अधिक specific /32 priority लेता है और MFA के बिना access संभव होता है
  • यह behavior v6.0.0 में बदला गया था; पहले MFA routes हमेशा priority लेते थे
  • एक route पर कई policies define होने पर policies compose होती हैं, और MFA rule priority लेता है
  • अभी release न हुई version से Deny rules के जरिए route access block किया जा सकता है
  • सबसे specific rule एक नया rule “bucket” बनाता है, इसलिए अगर /32 bucket में सिर्फ deny है, तो उसी /32 के अन्य ports तक access भी allow नहीं हो सकता

port और protocol rules

  • service access को port और protocol rules से define किया जा सकता है
  • supported rule types 3 हैं
    • Any: अगर कोई अलग rule नहीं है या any keyword इस्तेमाल किया गया है, तो सभी service और port combinations allow होते हैं
    • Single Service: 192.168.1.1 22/tcp 53/udp की तरह host के specific TCP·UDP ports allow करता है
    • Ranges: 192.168.1.1 22-1024/tcp 23-53/any की तरह port ranges specify करता है
  • port range में lower port पहले लिखना होगा
  • ICMP में ports नहीं होते, इसलिए 1.1.1.1 icmp की तरह बिना port के specify किया जा सकता है

limitations और development

  • Wag प्रति client केवल एक AllowedIP support करता है
  • यह limitation client से server तक जाने वाली structure के लिए उपयुक्त है
  • यह मुख्य रूप से Linux-only है, और Windows कुछ extra work के बाद काम कर सकता है
  • development mode में tunnel से आने वाली requests की IP को client IP के रूप में set करने के लिए environment variable इस्तेमाल किया जा सकता है
  • test example internal/router में sudo go test -v . run करता है
  • external contributions के लिए guidance है कि feature addition या bug fix के समय, जहां संभव हो tests लिखें और Pull Request खोलें

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-13
Hacker News टिप्पणियाँ

  • देखने में अच्छा लगता है, लेकिन कुछ बातें खटकती हैं
    curl [http://public.server.address:8080/register_device?key=e83253...](<http://public.server.address/register_device/…;) उदाहरण और “सेवा पूरी तरह templated response लौटाती है” वाले विवरण को देखकर लगता है कि रजिस्ट्रेशन प्रक्रिया में client private key बनाकर public key server को भेजने के बजाय server private key बनाकर client को भेज रहा है
    इसके अलावा उदाहरण HTTP का है, इसलिए कम-से-कम वह हिस्सा बदलना बेहतर होगा ताकि लोग यह न समझें कि HTTP भी ठीक विकल्प है
    यह भी जानना चाहूँगा कि session expire होने पर client को इसका पता लगाने का कोई तरीका है या नहीं। या फिर SSH session जैसी चीज़ें बस रुक जाती हैं?
    मैं कभी-कभी ऐसा WireGuard client ढूँढता रहा हूँ जो Wi-Fi की captive portal detection की तरह काम करे। आदर्श रूप से config file में persistentkeepalive जैसी एक पंक्ति जोड़कर URL fetch करे और समय-समय पर उसे जाँचता रहे। OK आए तो सब ठीक, response न आए तो network समस्या, और Location header आए तो browser उस स्थान पर खोलकर session re-authentication वगैरह कराई जाए
    अभी तक ऐसा client नहीं मिला

    • रजिस्ट्रेशन URL वैकल्पिक रूप से pubkey parameter भी ले सकता है, इसलिए server द्वारा private key generate करने के तरीके पर निर्भर रहना ज़रूरी नहीं है। documentation कम है, इसलिए भ्रम होना स्वाभाविक है
      आखिरी सवाल का जवाब दूँ तो, मैं जो eBPF XDP इस्तेमाल करता हूँ उसमें सिर्फ PASS, DROP, REDIRECT ही संभव है। इसलिए सबसे आसान नतीजे PASS/DROP से ही handle करता हूँ, और connection बस रुक जाता है
      हालांकि captive portal detection page को wag MFA सूची में जोड़ दें तो detection आप खुद configure कर सकते हैं, और उसके बाद browser बाकी काम संभाल लेगा
      wag में intercept या proxy जैसी functionality लागू करने का इरादा नहीं है। उससे authentication expiry या logout को संभालना थोड़ा आसान हो सकता है, लेकिन वह दिशा नहीं है
    • ऐसी functionality सच में बहुत बढ़िया होगी, और अच्छा होगा अगर इस project के लेखक इसे consider करें
    • मैंने भी एक मिलता-जुलता server बनाया था। उसमें device-specific client certificates चाहिए थे, और उसी से login page पर mTLS के जरिए पहुँचकर OIDC से user को authenticate किया जाता था और tunnel activate होता था, लेकिन मुश्किल हिस्सा client था
      मैंने Mac के लिए एक Go client लिखा था, और Brew के command line wg का इस्तेमाल करके key generation भी संभाला, लेकिन वह भद्दा था और sudo चाहिए होता था
      network permissions का उपयोग करने वाला कोई proper native app बेहतर होता, लेकिन वह मेरी क्षमता से बाहर है

  • यह जानना चाहूँगा कि session management की समस्या पर पहले से काम हुआ है या आगे करने की योजना है
    मूल रूप से WireGuard key एक स्थायी session key जैसी होती है
    अगर WireGuard transport layer लागू करने वाला software एक सही VPN server solution है, तो उसे session management भी implement करना चाहिए। यानी server के साथ दूसरे channel के जरिए session key को समय-समय पर rotate करना, session खत्म करना, IP address बदलना, नए routes set करना, और ज़रूरत हो तो फिर से authentication कराना चाहिए

    • ऐसे उपयोग के लिए मैं Firezone इस्तेमाल करूँगा। इसमें ऐसा option है जो users को platform पर नियमित रूप से login करने के लिए मजबूर करता है, और OIDC के साथ external identity provider जोड़ने पर session management के लिए यह बहुत मजबूत और सरल समाधान बन जाता है
    • wag के संदर्भ में “स्थायी session key” से आपका ठीक-ठीक क्या मतलब है, यह मुझे स्पष्ट नहीं है
      WireGuard key wag server से communicate करने देती है, लेकिन वास्तविक session एक eBPF map में रखा जाता है जो यह बताता है कि user authenticated है या नहीं
      इसलिए अगर कोई private key material चुरा भी ले, तब भी वह MFA-सीमित routes तक पहुँच नहीं पाएगा
    • अगर GlobalProtect जैसे VPN client को WireGuard पर बनाना हो, तो शायद मैं client-specific persistent authentication key रखूँगा और उससे VPN controller तक शुरुआती tunnel बनाऊँगा, फिर उसके भीतर authentication कराकर अलग session key दिलाऊँगा। पहला tunnel authentication पूरा होते ही और वास्तविक session key मिलते ही बंद कर दिया जाएगा
    • अगर समय-समय पर session key rotation, session termination, IP address बदलना, नए routes configure करना, और re-authentication के लिए दूसरा channel चाहिए, तो क्या वह असल में IPsec का IKE protocol नहीं है? फिर सीधे IPsec क्यों न इस्तेमाल करें?

  • यह जानना चाहता हूँ कि TOTP code brute force को रोका जा रहा है या नहीं, जैसे rate limit या retry count limit
    मैंने code को जल्दी से देखा, लेकिन ऐसा handling नहीं मिला
    जो scenario मैं सोच रहा हूँ वह यह है कि कोई browser में TOTP input UI खोले, developer tools चालू करे, और सभी संभव TOTP codes को बार-बार आज़माए

    • TOTP code brute force के खिलाफ सुरक्षा है। हर authentication में user के लिए सीमित प्रयास हैं, और उन्हें पार करने पर account lock हो जाता है, जिसे admin को unlock करना पड़ता है
      खास तौर पर इरादा यह भी है कि user सोचे कि device आखिर authentication को ज़बरदस्ती क्यों ट्रिगर कर रहा है। क्योंकि ऐसी स्थिति endpoint compromise का संकेत हो सकती है
    • शायद यह यहाँ है: https://github.com/NHAS/wag/blob/cdbdbec3393fa86bf6c823117c8...
    • मुझे इस implementation की details नहीं पता, लेकिन आम तौर पर अगर कोई TOTP चरण तक पहुँचने लायक login info, यानी username और password, पहले से रखता है, तो वह user पहले ही compromise हो चुका है

  • यह Headscale या Tailscale से काफ़ी मिलता-जुलता लगता है। WireGuard network को manage करने के विकल्प दिखना अच्छा है
    मैं जानना चाहूँगा कि features कहाँ तक overlap करते हैं, क्या extra जोड़ा गया है, क्या अलग है, और आगे क्या implement नहीं किया जाएगा—क्या इसके लिए कोई comparison material है?

    • WireGuard इस्तेमाल करने के लिहाज़ से यह निश्चित रूप से मिलता-जुलता है
      मैंने documentation में सीधी तुलना नहीं डाली, और फिलहाल यह वह दिशा नहीं है जहाँ मैं जाना चाहता हूँ। यह project मेरी ज़रूरतों के हिसाब से है और काफ़ी मज़ेदार भी है
      Wag, Tailscale-शैली के mesh की तुलना में—जहाँ सब कुछ एक-दूसरे तक पहुँचता है और rules overlay को define करते हैं—ज़्यादा hub-and-spoke architecture के लिए उपयुक्त है, जहाँ आप मज़बूत boundaries चाहते हैं
      wag और Tailscale दोनों SSO integration और user protection के लिए लगभग 2FA जोड़ते हैं
      दोनों में registration methods और management के लिए web UI है, लेकिन मैं web development पसंद न करने वाला solo developer हूँ, इसलिए Tailscale काफ़ी ज़्यादा polished होगा
      जिस चीज़ को मैं निश्चित रूप से implement नहीं करूँगा, वह है session logout के बाद user को redirect करने के लिए interception या TLS proxy वाला हिस्सा। मुख्य कारण यह है कि अभी eBPF के साथ वह मेरे लिए थोड़ा भारी है, और उसे काम कराने के लिए शायद जो DNAT/SNAT component लिखने पड़ेंगे, उन्हें मैं इस्तेमाल नहीं करना चाहता

  • IPv4-only होना थोड़ा अजीब है; जो site WireGuard चुनती है, उससे ज़्यादा आधुनिक setup और self-service ULA का उपयोग करने की उम्मीद की जा सकती है

    • मैं जल्द ही IPv6 support जोड़ने की योजना बना रहा हूँ, और यह भी सोच रहा हूँ कि users के वास्तविक local network से टकराव के जोखिम को कम करने के लिए लोगों के IPv4 addresses को private IPv6 space में map किया जाए
      ULA का ज़िक्र करते समय क्या आपके मन में कोई खास बात थी?
    • मैं जानना चाहूँगा कि यहाँ ULA के फ़ायदे आप किस रूप में देखते हैं