الوصول إلى خادم ssh عبر اتصال مزدحم للغاية

هذه المقالة هي نتيجة زيارتي لخدمة السيارات. أثناء انتظار السيارة ، قمت بتوصيل جهاز الكمبيوتر المحمول الخاص بي بشبكة wifi الضيف وقراءة الأخبار. لدهشتي ، وجدت أنه لا يمكنني زيارة بعض المواقع. مع معرفتي بمعلومات عن المكوك ( وكوني معجبًا كبيرًا بهذا المشروع) حاولت إنشاء جلسة مكوك مع الخادم الخاص بي ، لكنها لم تنجح. تم إغلاق المنفذ 22 بإحكام. في نفس الوقت ، استجاب nginx على المنفذ 443 بشكل طبيعي. في الزيارة التالية لخدمة السيارة ، قمت بتثبيت مُضاعِف sslh على الخادم .يقوم الخادم بتشغيل gentoo وقمت بإضافة السطر التالي إلى الملف /etc/conf.d/sslh:

DAEMON_OPTS="-p 0.0.0.0:443 --ssl 127.0.0.1:8443 --ssh 127.0.0.1:22 --user nobody"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

اعتمادًا على نوع الاتصال ، يتم إعادة توجيه الاتصالات بالمنفذ 443 إلى المنفذ المحلي:

• 8433 في حالة https (يعمل nginx على هذا المنفذ)
• 22 في حالة ssh

ولكن عندما حاولت إنشاء اتصال ssh بالخادم ، فشلت مرة أخرى. على ما يبدو ، تم إجراء التصفية ليس فقط عن طريق المنافذ ، ولكن تم أيضًا استخدام فحص الحزم العميق. هذا يجعل المهمة أكثر صعوبة. يجب أن تكون حركة مرور Ssh ملفوفة في https. لحسن الحظ ، هذا ليس بالأمر الصعب بفضل مشروع websocat . في صفحة المشروع ، يمكنك العثور على العديد من الثنائيات سابقة الإنشاء. إذا كنت تريد ، لسبب ما ، تجميع الثنائي بنفسك من المصدر ، فهذا أيضًا ليس صعبًا جدًا. أفعل ذلك مع باكر hashicorp بالتكوين التالي:

{
  "min_packer_version": "1.6.5",
  "builders": [
    {
      "type": "docker",
      "image": "ubuntu:20.04",
      "privileged": true,
      "discard": true,
      "volumes": {
        "{{pwd}}": "/output"
      }
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "skip_clean": true,
      "environment_vars": [
        "DEBIAN_FRONTEND=noninteractive"
      ],
      "inline": [
        "apt-get update && apt-get install -y git curl gcc libssl-dev pkg-config gcc-arm-linux-gnueabihf",
        "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs >/tmp/rustup.sh && chmod +x /tmp/rustup.sh && /tmp/rustup.sh -y",
        "git clone https://github.com/vi/websocat.git && cd websocat/",
        ". $HOME/.cargo/env && cargo build --release --features=ssl",
        "printf '[target.armv7-unknown-linux-gnueabihf]\nlinker = \"arm-linux-gnueabihf-gcc\"\n' >$HOME/.cargo/config",
        "rustup target add armv7-unknown-linux-gnueabihf",
        "cargo build --target=armv7-unknown-linux-gnueabihf --release",
        "strip target/release/websocat",
        "tar czf /output/websocat.tgz target/armv7-unknown-linux-gnueabihf/release/websocat target/release/websocat",
        "chown --reference=/output /output/websocat.tgz"
      ]
    }
  ]
}

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

جانب العميل موجود في ubuntu 20.04 ، يعمل الخادم على nvidia tegra jetson tk1 ، لذلك أقوم بإجراء تجميع متقاطع لمنصة armv7. يرجى ملاحظة أن بناء الخادم يتم بدون دعم ssl ، حيث يتم تنفيذ إنهاء SSL بالنسبة لي بواسطة nginx ، والذي يعالج الاتصالات الواردة. يبدو تكوين nginx كما يلي:

http {
    server {
        listen 0.0.0.0:8443 ssl;
        server_name your.host.com;
        ssl_certificate /etc/letsencrypt/live/your.host.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/your.host.com/privkey.pem;
        location /wstunnel/ {
            proxy_pass http://127.0.0.1:8022;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";
        }
    }
}

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

أقوم بتشغيل Websocat من تاج المستخدم الخاص بي:

* * * * * netstat -lnt|grep -q :8022 || $HOME/bin/websocat -E --binary ws-l:127.0.0.1:8022 tcp:127.0.0.1:22|logger -t websocat &
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

الآن يمكنك الاتصال بالخادم الخاص بك كما يلي:

ssh -o ProxyCommand='websocat --binary wss://your.host.com/wstunnel/' your.host.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

إلى أي مدى يقلل الالتفاف في https من النطاق الترددي؟ للتحقق من ذلك ، استخدمت الأمر التالي:

ssh -o ProxyCommand='websocat --binary wss://your.host.com/wstunnel/' your.host.com 'dd if=/dev/zero count=32768 bs=8192' >/dev/null
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

في تجاربي ، حصلت على انخفاض 2x في عرض النطاق الترددي. عند استخدام بروتوكول ws: // ، أي http ، فإن عرض النطاق الترددي للاتصال مطابق لـ ssh غير المغلف.



إليك كيف يمكنك إعداد جلسة مكوك:

sshuttle -e 'ssh -o ProxyCommand="websocat --binary wss://your.host.com/wstunnel/"' -r your.host.com 0/0 -x $(dig +short your.host.com)/32
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

في الزيارة التالية لخدمة السيارات ، تأكدت من أن كل شيء يعمل كما ينبغي. كمكافأة لطيفة ، انخفض عدد محاولات تسجيل الدخول إلى الخادم عبر ssh من العناوين اليسرى بشكل حاد.