XRay w Google Cloud Run: obejście blokad podsieci

Wdrażanie XRay w Google Cloud Run do omijania blokad podsieci

Blokady całych podsieci dostawców ułatwiają DPI, ale powodują problemy z ubocznymi stratami. Zamiast skomplikowanego wykrywania stosuje się masowe blokady zakresów /16 i /8, co prowadzi do zamrożenia połączeń po 16 KB lub całkowitego odcięcia TLS. Analiza pokazuje wpływ na setki AS, blokując miliony IP. Omijanie możliwe przez umieszczenie w nieblokowanych podsieciach dużych dostawców lub domain fronting.

Reality i proste alternatywy

XTLS-Reality jest zbędne bez active probing: VLESS z samodzielnie podpisanym certyfikatem i podmianą domeny daje podobny efekt. Działa nawet z CDN wspierającymi niestandardowe certyfikaty. Do blokad TLS użyj gRPC dla VLESS lub XHTTP z multipleksowaniem.

Wdrażanie w Google Compute Engine

Utwórz instancję e2-micro (0,25 vCPU, 1 GB RAM) w Compute Engine:

• Wybierz region z najniższą ceną.
• Ustaw standardowy dysk bez backupów.
• Zezwól na ruch HTTP/HTTPS.
• Użyj efemerycznego IPv4.

Zainstaluj XRay i skonfiguruj VLESS Enc z Reality Seed dla ochrony przed analizą rozmiarów pakietów. SNI google.com przechodzi, bo IP z AS Google.

Optymalizacja przez Cloud Run: kontenery na żądanie

Dla obniżenia kosztów użyj serverless w Cloud Run:

• Przejdź do Cloud Run > Services > Deploy web service.
• Obraz: docker.io/teddysun/xray.
• Region: Tier 1, najbliższy.
• Port kontenera: 8080.
• Zasoby: 128 MB RAM, 1 CPU (minimum dla >1 połączenia).
• Skalowanie: 0–1 instancja, rozliczenie na żądanie.
• Ingress: all, timeout 3600 s, concurrency 100+.

Montowanie konfiguracji

W Secret Manager utwórz sekret z config.json i zamontuj jako /etc/xray/config.json.

Przykład configu dla XHTTP (sniffing wyłączony):

{
  "log": {
    "loglevel": "info"
  },
  "inbounds": [
    {
      "port": 8080,
      "protocol": "vless",
      "tag": "pxy",
      "settings": {
        "clients": [
          {
            "id": "4c3fe585-ac09-41df-b284-70d3fbe27773",
            "email": "user1"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "xhttpSettings": {
          "path": "/secreturlxx"
        }
      },
      "sniffing": {
        "enabled": false
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

Na kliencie: XHTTP z XMUX (maxConnections=1, maxConcurrency=0). Uruchomienie kontenera trwa 1–2 s.

Domain fronting w infrastrukturze Google

Połączenie do google.com rozwiązuje IP Google, ale Host wskazuje na twój *.run.app — żądanie jest routowane wewnątrz AS. Certyfikat jest wydawany poprawnie dla każdego serwisu Google (HTTPS/QUIC). To nie podmiana jak w Reality: ruch idzie przez realną infrastrukturę Google.

Konfiguracja klienta używa server=google.com, SNI=google.com, Host=xxxxxxxxx.run.app.

Ograniczenia i skalowanie

• Wymaga zagranicznej karty i potwierdzenia rezydencji.
• Koszt wysoki: dla 1–2 użytkowników — opcja awaryjna.
• Trial: 200$ na 3 miesiące.

Dla obciążenia >1 połączenia wdrażaj proxy typu praveenkarunarathne/Google-Cloud-Run-Proxy z env V2RAY_SERVER_IP=twój_VPS.

| Parametr | Compute Engine | Cloud Run |

|----------|----------------|-----------|

| Uruchomienie | Stałe | Na żądanie (0–1 instancja) |

| Cena | Stała/godz | Na żądanie |

| Skala | Ręczna | Auto |

| Opóźnienie | Niskie | 1–2 s |

Co ważne

• Blokady /16–/8 podsieci dotykają >225 mln IP, omijanie przez AS Google.
• XHTTP w Cloud Run kompatybilne z balancerem, Reality Seed chroni pakiety.
• Domain fronting routuje przez infrastrukturę Google bez banów.
• Minimalne zasoby: 128 MB/1 CPU dla pary klientów.
• Config w Secret Manager, sniffing off dla wydajności.

— Editorial Team