Discusión sobre la legalidad del proxy inverso en redes domésticas
Categories:
Antecedentes
Hace aproximadamente 90 días, encontré un problema con IPv6 de China Telecom en Hubei que no podía conectarse. Después de una observación y análisis a largo plazo, ahora resumo la siguiente experiencia.
Análisis del problema
Las dos posibles causas iniciales sospechadas:
Detección de uso de PCDN
- Aunque no uso PCDN activamente
- Solo hay una pequeña cantidad de descargas BT
- Se ha implementado limitación de velocidad de subida, pero el problema persiste
Servidor doméstico como origen del blog
- A través de la regla de origen de Cloudflare especificando el puerto
- Podría ser juzgado por el operador como “comportamiento comercial”
Después de tres meses de verificación, el problema es más probable que provenga de la exposición de puertos HTTP/HTTPS al público.
Manifestaciones específicas
Estado anormal de IPv6:
- Se puede obtener el prefijo /56
- Los dispositivos pueden obtener direcciones IPv6 globales
- Pero no pueden acceder a Internet
- Solo el router conectado en modo puente del módem puede usar IPv6 normalmente
Conexión anormal de Tailscale:
- El servidor de origen muestra conexión directa pero con latencia anormal (aproximadamente 400ms)
- Otros dispositivos conectados mediante relay, con latencia más baja (aproximadamente 80ms)
Análisis de la política del operador
Algunos operadores de telecomunicaciones de China Telecom en ciertas áreas toman medidas de degradación de servicio para conexiones HTTP/HTTPS entrantes frecuentes:
Degradación del servicio IPv6
- Asignación de direcciones normal
- Falta de tabla de enrutamiento
- Realmente no puede conectarse a Internet
Restricción de conexión P2P
- Tailscale muestra conexión directa
- Latencia real alta
- Ancho de banda limitado
Soluciones
Desactivar el servicio de proxy inverso:
- Desactivar proxy inverso de Cloudflare/Alibaba Cloud ESA
- Se puede restaurar después de varios reinicios del router
Prevención de escaneo de dominios: Evitar usar los siguientes subdominios comunes:
- home.example.com - ddns.example.com - dev.example.com - test.example.comMejores prácticas:
- Usar GUID para generar subdominios aleatorios
- Evitar usar nombres de subdominios con patrones o comunes
- Cambiar el dominio regularmente para reducir el riesgo de ser escaneado