Cómo distinguir diferentes fallos de red provocados por el hombre en el entorno doméstico de Internet

Como todos sabemos, al navegar por Internet en China, nos encontraremos con varios fallos de red provocados por el hombre, que nos imposibilitan acceder a muchos sitios web con normalidad. Sin embargo, debido a que muchas personas no están familiarizadas con Internet, a menudo no pueden distinguir entre diferentes fallas de la red, lo que lleva a situaciones en las que es claramente una falla de la red pero piensan que es una falla del servidor o es claramente una falla del servidor pero; Piensan que es un fallo de la red. Siento que es necesario explicar las características de las diferentes fallas de la red y cómo distinguirlas y solucionarlas.

En el entorno de Internet doméstico, las fallas de red que encontramos a menudo incluyen: secuestro de DNS, contaminación de DNS, bloqueo de IP, filtrado de IP del firewall del servidor, tiempo de inactividad del servidor, restablecimiento de la conexión TCP basado en palabras clave, sin restablecimiento de la conexión TCP con estado, Filtrado de certificados SSL, secuestro de SSL, secuestro de sesión HTTP y otras fallas de red. Lo explicaré a continuación:

1. Secuestro de DNS

El secuestro de DNS hará que visitemos algunos sitios web inexistentes o inestables, pero lo que visitamos es la búsqueda de Telecom 114 ( para obtener más detalles, consulte "Secuestro del navegador en Internet después de la desconexión" de Moonlight Blog) o al acceder a Google, se muestra la página de inicio de Baidu (para obtener más detalles, consulte "La búsqueda de blogs de Google transformada en Baidu" de Moonlight Blog).

Si necesitamos confirmar si estamos en un entorno de secuestro de DNS, podemos usar la herramienta de diagnóstico de red incorporada de Windows nslookup en la línea de comando cmd de Windows para encontrar un nombre de dominio inexistente o inestable para diagnóstico de red:

C:\gt;nslookup www.SomeRandomDomainName.com

Servidor: ns-pd.online.sh.cn

Dirección: 202.96. .209.133

Respuesta no autorizada:

Nombre: www.SomeRandomDomainName.com

Dirección: 218.83.175.155

Vemos que www.SomeRandomDomainName.com debería ser un nombre de dominio que no existe. El servidor DNS debería decirnos que este nombre de dominio no existe, pero vemos que el servidor DNS nos dice que la IP de este nombre de dominio es 218.83.175.155 (. las IP buscadas por 114 en diferentes regiones son diferentes. La IP que puede obtener no es 218.83.175.155, sino la dirección IP del servidor de 114 Search en su área), y esta IP es la IP de 114 Search, lo que hace que veamos 114. Buscar cuando visitamos este sitio web en la página web del navegador.

Si necesita resolver el problema del secuestro de DNS, puede cambiar su servidor de resolución de nombres de dominio a uno externo, como OpenDNS (consulte el blog de Moonlight "Uso de OpenDNS para resolver el secuestro de nombres de dominio DNS" para obtener más detalles). ) o Google DNS (consulte Moonlight para más detalles) Blog "Google lanza servicio DNS gratuito").

Después de resolver el problema, utilizamos nslookup nuevamente para encontrar este sitio web:

C:\gt;nslookup www.SomeRandomDomainName.com

Servidor: google- public-dns -a.google.com

Dirección: 8.8.8.8

*** google-public-dns-a.google.com no puede encontrar www.SomeRandomDomainName. com: Dominio inexistente

Vemos que el servidor DNS nos dijo correctamente que este nombre de dominio no existe y no seremos secuestrados para buscar 114.

Sin embargo, como dice el último párrafo de "Uso de OpenDNS para resolver el secuestro de nombres de dominio DNS", "pero para el secuestro de contaminación de DNS, el uso de OpenDNS no puede resolver el problema". A continuación, presentaré la contaminación del DNS.

2. Contaminación de DNS

Dado que el secuestro de DNS puede resolver el problema reemplazando el servidor de resolución de nombres de dominio por uno externo, el sistema necesita utilizar la contaminación de DNS para bloquear algunos nombres de dominio. De esta manera, incluso si utiliza un servidor de nombres de dominio extranjero, no podrá obtener la IP correcta del servidor, por lo que no podrá acceder a estos servidores. Por ejemplo, la página de inicio de Twitter, el ahora famoso antepasado de los microblogs, fue contaminada por DNS.

Si necesita confirmar que el nombre de dominio está contaminado por DNS y no causado por otras fallas, primero debe comprender que el secuestro de DNS lo completan los servidores de nombres de dominio nacionales, por lo que podemos resolver el problema reemplazando los servidores de nombres de dominio con servidores externos la contaminación del DNS la realiza el sistema, por lo que incluso si se cambia el servidor de nombres de dominio, el sistema aún puede enviar resultados de resolución de nombres de dominio falsos para reemplazar los resultados de resolución correctos. Por lo tanto, podemos diagnosticar si se trata de un secuestro de DNS o de una contaminación de DNS utilizando una IP extranjera inexistente como nuestro servidor de nombres de dominio. Seguimos usando nslookup para el diagnóstico de red y seleccionamos una IP extranjera inexistente como 144.223.234.234:

C:\gt; nslookup twitter.com 144.223.234.234

Se agotó el tiempo de espera de la solicitud de DNS. .

El tiempo de espera fue de 2 segundos.

*** No se puede encontrar el nombre del servidor para la dirección 144.223.234.234: Tiempo de espera agotado

Servidor: Desconocido

Dirección: 144.223.234.234

Nombre: twitter.com

Dirección: 93.46.8.89

Vemos que ya que 144.223.234.234 es no hay existencia, no debería haber retorno. Pero obtuvimos una IP incorrecta: 93.46.8.89. Probemos la IP que fue secuestrada por DNS hace un momento:

C:\gt;nslookup www.SomeRandomDomainName.com 144.223.234.234

Se agotó el tiempo de espera de la solicitud de DNS.

El tiempo de espera fue de 2 segundos.

*** No se puede encontrar el nombre del servidor para la dirección 144.223.234.234: Tiempo de espera agotado

Servidor: Desconocido

Dirección: 144.223.234.234

Se agotó el tiempo de espera de la solicitud de DNS.

El tiempo de espera fue de 2 segundos.

Se agotó el tiempo de espera de la solicitud de DNS.

El tiempo de espera fue de 2 segundos .

*** Se agotó el tiempo de espera de la solicitud desconocida

Vemos que www.SomeRandomDomainName.com no devuelve un resultado, por lo que no está contaminado por DNS.

Si queremos solucionar la contaminación del DNS, sólo podemos utilizar varios proxies de cifrado para resolución remota de DNS, VPN o explotar vulnerabilidades del sistema.

3. Bloqueo de IP

Aquí el bloqueo de IP se refiere a la adición nacional de IP de servidores extranjeros a la lista negra del sistema, lo que resulta en la imposibilidad de acceder directamente al servidor en la mayoría de las áreas y Incluso todo el país. Dado que el sistema está distribuido, es posible que se pueda acceder a algunas áreas y a otras no. Por ejemplo, la página de inicio de Dropbox, un conocido servicio de almacenamiento en la nube, ha sido bloqueada por IP.

En primer lugar, configuramos el servidor de nombres de dominio como uno externo para eliminar el problema del secuestro de DNS. Después de eso, diagnosticaremos si el nombre de dominio de Dropbox está contaminado por DNS:

C:\gt;nslookup www.dropbox.com 144.223.234.234

Se agotó el tiempo de espera de la solicitud de DNS.

El tiempo de espera fue de 2 segundos.

*** No se puede encontrar el nombre del servidor para la dirección 144.223.234.234: Tiempo de espera agotado

Servidor: Desconocido

Dirección: 144.223.234.234

Se agotó el tiempo de espera de la solicitud de DNS.

El tiempo de espera fue de 2 segundos.

Se agotó el tiempo de espera de la solicitud de DNS.

el tiempo de espera fue de 2 segundos.

*** Se agotó el tiempo de espera de solicitud desconocida

Aparentemente no hay contaminación de DNS. Luego, podemos usar la herramienta de diagnóstico de red que viene con Windows en la línea de comando cmd de Windows en un entorno de red donde el protocolo ICMP no está filtrado (algunas redes de banda ancha comunitaria y algunas redes internas de empresas filtran el protocolo ICMP y no pueden usar Tracert). realiza un diagnóstico de red para ver si el sitio web tiene IP bloqueada o tiene otras fallas:

C:\gt; tracert -d www.dropbox.com

Seguimiento de ruta a www.dropbox com [174.36.30.70]

sobre un máximo de 30 saltos:

1 18 ms 19 ms 26 ms 58.35.240.1

2 15 ms 20 ms 29 ms 58.35.240.1

3 13 ms 10 ms 14 ms 124.74.20.45

4 14 ms 14 ms 15 ms 124.74.209.137

5 10 ms 15 ms 14 ms 61.152.86.58

6 * * * Solicitud agotada.

7 * * * Solicitud agotada.

8 * * * Solicitud agotada.

......

Vemos que la última IP es 61.152.86.58 (las IP son diferentes en diferentes regiones) y luego, aparentemente, la IP no está disponible. está bloqueado cerca del bloqueo 61.152.86.58.

Luego abrimos ip138 y comprobamos quién controla 61.152.86.58:

La IP que estás consultando: 61.152.86.58

* Los datos principales de esta web: Shanghai Telecom

* Datos de referencia uno: Shanghai Telecom

* Datos de referencia dos: Shanghai Telecom

Obviamente, el problema radica en Shanghai Telecom (otras regiones pueden ser telecomunicaciones locales en la región). No es un problema con el servidor de Dropbox.

4. Filtrado de IP del firewall del servidor y tiempo de inactividad del servidor

Escribo estos dos puntos juntos porque el rendimiento externo de las dos situaciones es el mismo. Pero es muy diferente al bloqueo de IP. La última IP accesible para el bloqueo de IP es de China, pero la última IP accesible para el filtrado de IP del firewall del servidor y la caída del servidor es del extranjero.

Por ejemplo, tomamos 75.101.142.137 como experimento. El sitio web de Alexa ya se ha implementado en él. Ahora no hay ningún servidor en esta IP (se puede considerar como un servidor inactivo):

C:\gt. ;tracert -d 75.101 .142.237

Seguimiento de ruta a 75.101.142.237 en un máximo de 30 saltos

1 25 ms 18 ms 18 ms 58.35.240.1

2 25 ms 42 ms 27 ms 58.35.240.1

3 10 ms 15 ms 14 ms 124.74.37.9

4 49 ms 59 ms 12 ms 124.74.209.129

5 14 ms 14 ms 14 ms 61.152.86.142

6 10 ms 14 ms 15 ms 202.97.35.154

7 14 ms 15 ms 14 ms 202.97.34.126

8 194 ms 195 ms 194 ms 202.97.51.138

9 171 ms 170 ms 173 ms 202.97.50.54

10 215 ms 179 ms 175 ms 63.146.27.133

11 279 ms 280 ms 278 ms 67.14.36.6

12 * * * Tiempo de espera agotado para la solicitud.

13 249 ms 249 ms 244 ms 72.21.199.40

14 254 ms 254 ms 254 ms 72.21.222.157

15 250 ms 250 ms 249 ms 216.182.232.53

16 270 ms 270 ms 273 ms 216.182.224.22

17 272 ms 269 ms 289 ms 75.101.160.35

18 * * * Se agotó el tiempo de espera de la solicitud.

19 * * * Se agotó el tiempo de espera de la solicitud.

20 * * * Se agotó el tiempo de espera de la solicitud.

Vemos que la última IP accesible es 75.101.160.35, y luego verificamos a qué IP pertenece:

La IP que estás consultando: 75.101.160.35

* Datos principales de este sitio: Estados Unidos

* Datos de referencia uno: Estados Unidos

* Datos de referencia dos: Amazon, Seattle, King Condado, Washington, Estados Unidos

Obviamente, se trata de una falla del servidor.

Si queremos solucionar el bloqueo de IP, sólo podremos acceder a estos sitios web a través de proxies cifrados, VPN o explotar vulnerabilidades del sistema.

5. Restablecimiento de la conexión TCP basada en palabras clave

Los sistemas nacionales registrarán todo el contenido cuando las personas accedan a sitios web extranjeros a través del protocolo http. Una vez que algo sea "sensible" cuando se utiliza la palabra clave. La conexión TCP se desconectará a la fuerza, las direcciones IP de ambas partes se registrarán y conservarán durante un período de tiempo (aproximadamente 1 minuto) y nuestro navegador también mostrará "Restablecer conexión". Posteriormente, durante este período de tiempo (aproximadamente 1 minuto), debido a que nuestra IP y la IP del servidor son registradas por el sistema de inspección de cámaras, no podremos volver a acceder a este sitio web.

Debemos dejar de acceder a este sitio web. Después de este período de tiempo, podemos volver a acceder a este sitio web accediendo nuevamente a páginas web sin estas palabras clave.

Debido a estas características, nos resulta más fácil determinar si se ha producido un restablecimiento de la conexión TCP basado en palabras clave. Si el navegador muestra "Restablecer conexión" y no puede acceder a este sitio web nuevamente durante un período de tiempo, y luego de este período de tiempo, cuando se puede acceder a páginas web sin estas palabras clave en este sitio web, hemos sido atacados en función de palabras clave. Error de restablecimiento de la conexión TCP de Word.

Precisamente porque el protocolo http se transmite en texto claro, se puede restablecer la conexión TCP en función de palabras clave. Entonces, si el sitio web admite el acceso cifrado https, podemos acceder al sitio web a través de https para resolver este problema. Pero si el sitio web no admite el acceso https, sólo podremos acceder a él a través de un proxy cifrado, VPN o aprovechando las vulnerabilidades del sistema. Además, el sistema nacional no tiene otros medios para lidiar con https. Además del bloqueo de IP, también existen restablecimientos de conexiones TCP sin estado, filtrado de certificados SSL, secuestro de SSL y otros medios, que se presentan a continuación.

6. Restablecimiento de la conexión TCP sin estado

Dado que https es un protocolo para la transmisión de datos cifrados, el sistema no puede saber qué contenido se transmite a través del protocolo https, pero el público no puede saberlo. utilice https para acceder a "información dañina", de modo que siempre que el sistema detecte (el sistema solo sabe que se accede al protocolo https del sitio web y no conoce el contenido transmitido) que se accede al protocolo https del sitio web especificado ( como el método de acceso https de Google Docs), desconectará por la fuerza la conexión TCP. De esta forma, el protocolo https de estos sitios web no se puede utilizar directamente en China. Muchas personas se ven obligadas a utilizar el protocolo http, de modo que todo el contenido transmitido queda registrado por el sistema.

El resultado de un restablecimiento de la conexión TCP sin estado es que el navegador muestra "Restablecimiento de conexión", pero se restablecerá cualquier página web a la que se acceda en este servidor. Si desea resolver este problema, sólo puede confiar en servidores proxy cifrados, VPN o explotar vulnerabilidades del sistema.

7. Filtrado de certificado SSL

Similar al restablecimiento de una conexión TCP sin estado, dado que https es un protocolo para la transmisión de datos cifrados, el sistema no puede saber qué contenido se transmite a través del protocolo https, pero Las personas no pueden usar https para acceder a "información dañina". Además de la contaminación de nombres de dominio y el restablecimiento de la conexión TCP sin estado para evitar que el contenido sea censurado, también existen métodos de censura de filtrado de certificados SSL. Dado que el certificado SSL se transmite en texto claro durante la transmisión https, puede controlar si el certificado SSL se emite para el nombre de dominio especificado. Si este es realmente el caso, entonces la conexión TCP se desconecta a la fuerza y ​​el navegador también mostrará "Restablecer conexión". El filtrado de certificados SSL solo se produce cuando se accede al sitio web mediante https.

El filtrado de certificados SSL es relativamente raro. Si necesita resolver este problema, sólo puede confiar en servidores proxy cifrados, VPN o explotar las vulnerabilidades del sistema.

8. Secuestro de SSL

Aunque desconectar la conexión https puede evitar que las personas accedan a "información dañina", no saben a qué información dañina se accede. En base a esto, en vista de la debilidad de https (confiar en todas las CA de autoridad certificadora), CNNIC solicitó convertirse en una autoridad certificadora superior (CA raíz), para poder emitir certificados falsos para llevar a cabo ataques de intermediario. y descifrar el contenido transmitido por https. Para obtener más información, consulte "Nuevas ideas para descifrar el HTTPS de Google Gmail" del blog Moonlight.

Si se secuestra SSL, es difícil de detectar. Cuando accedemos a sitios web extranjeros a través de https, debemos verificar siempre si el certificado es emitido por una autoridad certificadora nacional. Si lo emite una autoridad certificadora nacional, es probable que haya sido secuestrado por SSL y se debe detener el acceso de inmediato.

Si queremos resolver el secuestro de SSL, podemos prohibir los certificados de la autoridad certificadora nacional como CNNIC en el navegador (como "CNNIC, no confío en ti").

Pero esto no resuelve completamente el problema, si un día una autoridad certificadora nacional desconocida está involucrada en el secuestro de SSL, será difícil de detectar. Con el tiempo, también necesitaremos confiar en un proxy cifrado o una VPN.

9. Secuestro de sesión HTTP

El secuestro de sesión HTTP tiene como objetivo modificar el resultado de retorno http normal y puede agregarle publicidad o incluso virus troyanos. En términos generales, si se secuestra una sesión http y se agregan anuncios a Internet, es probable que se consideren anuncios propios del sitio web. Dado que el protocolo http se transmite en texto claro, también se puede lograr el secuestro de sesiones http. "Anuncios emergentes de Internet a nivel de telecomunicaciones" de Moonlight Blog, "Obtuve evidencia de anuncios emergentes de telecomunicaciones maliciosos" y "¿Quién controla nuestro navegador?" 》También hay una introducción detallada al secuestro de sesiones http. Los ISP suelen implementar el secuestro de sesión HTTP para enviar anuncios, pero no se descarta que el sistema utilice este método en el futuro.

Para resolver el problema del secuestro de sesiones HTTP, Moonlight Blog también proporciona una solución: "Método para eliminar anuncios emergentes de ADSL". El uso de un complemento del navegador para bloquear anuncios puede resolver parte del problema, pero es posible que no lo resuelva por completo. Si desea resolver el secuestro de sesión HTTP por medios técnicos, una forma es utilizar un proxy cifrado y VPN para acceder a todos los sitios web, incluidos los nacionales, pero esto no puede resolver completamente el problema si el secuestro de sesión HTTP está configurado en un enrutador cerca del. servidor, este método no puede resolver el problema; otro método es secuestrar diferentes sesiones HTTP. Actualizamos el firmware del enrutador y luego lo volvemos a secuestrar (el firmware del enrutador dd-wrt y tomate admite la personalización, y es posible secuestrar la sesión HTTP). a los datos originales), o utilizar diferentes servidores proxy de capa de aplicación local para filtrar anuncios para diferentes secuestros de sesiones HTTP.