Respuesta original:

En mi caso estaba usando una VPN en Windows, al desconectarme de la VPN se resolvió el problema.

Editar:

Sin embargo, esto se está convirtiendo en un problema más amplio, me sucedió nuevamente y lo resolví eliminando el adaptador de extensión de conmutador virtual de Hyper-V.

Las dos soluciones más utilizadas en este momento para este problema son:

1 Evite que /etc/resolfv.conf se "corrompa"

1. Cree un archivo: /etc/wsl.conf .
2. Pon las siguientes lineas en el archivo

 [network] generateResolvConf = false

3. En una ventana cmd , ejecute wsl --shutdown
4. Reiniciar WSL2
5. Cree un archivo: /etc/resolv.conf . Si existe, reemplace uno existente con este nuevo archivo.
6. Pon las siguientes lineas en el archivo

 nameserver 8.8.8.8

7. Repita los pasos 3 y 4. Verá que git funciona bien ahora.

Créditos a NonStatic que lo compartió en github

2 Eliminar los controladores de interfaz de red dañados (podrían ser permanentes)

1. Primero ve al administrador de dispositivos

2. Mostrar dispositivos ocultos

3. Eliminar todos los adaptadores de extensión de conmutador virtual de Hyper-V

Créditos a Jaysonsantos que lo compartió en GitHub

Estaba experimentando el mismo problema.

cat /etc/resolv.conf y vea si la salida tiene algo como esto:

 # This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf: # [network] # generateResolvConf = false nameserver 172.XXX

Deberá cambiar el servidor de nombres a 8.8.8.8 , así que ejecute sudo nano /etc/resolv.conf , edite y guarde el archivo.

Sin embargo, esta es más o menos una solución temporal, ya que deberá hacer esto cada vez que se inicie WSL. Es posible que desee ejecutar un script que verifique el servidor de nombres y lo actualice a 8.8.8.8 cada vez que reinicie wsl. Este cambio funciona para mi WSL2-Debian. Pero no necesito reiniciar WSL.

El archivo generado /etc/resolv.conf es:

servidor de nombres 172.24.0.1

..tuve que cambiarlo a

servidor de nombres 8.8.8.8

que resuelve el problema

Lo más probable es que la Distribución obtenga su propio adaptador virtual, primero hay algunos pasos que puede probar:

1. Necesito verificar si los paquetes realmente pasan por el firewall de Windows Luego verifique %systemroot%\system32\LogFiles\Firewall\pfirewall.log

2. Si los paquetes no pasan por el cortafuegos, lo más probable es que la distribución obtenga su propio adaptador virtual, verifique qué IP obtiene la distribución desde dentro de Debian con:

   ifconfig

o si no tienes ifconfig :

 perl -MSocket -le 'socket(S, PF_INET, SOCK_DGRAM, getprotobyname("udp")); connect(S, sockaddr_in(1, inet_aton("8.8.8.8"))); print inet_ntoa((sockaddr_in(getsockname(S)))[1]);'

o ipconfig en la máquina host de Windows WSL2 y mire qué IP toma la máquina bajo el adaptador WSL

3. Si necesita tener acceso a Internet a través de la IP de Windows, consulte este problema: https://github.com/microsoft/WSL/issues/4150

La solución es usar un script que haga:

un. Obtenga la dirección IP de la máquina WSL 2

B. Eliminar las reglas de reenvío de puertos anteriores

C. Agregar reglas de reenvío de puertos

D. Eliminar reglas de firewall agregadas anteriormente

mi. Agregar nuevas reglas de firewall

 $remoteport = bash.exe -c "ifconfig eth0 | grep 'inet '" $found = $remoteport -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}'; if( $found ){ $remoteport = $matches[0]; } else{ echo "The Script Exited, the ip address of WSL 2 cannot be found"; exit; } #[Ports] #All the ports you want to forward separated by coma $ports=@(80,443,10000,3000,5000); #[Static ip] #You can change the addr to your ip config to listen to a specific address $addr='0.0.0.0'; $ports_a = $ports -join ","; #Remove Firewall Exception Rules iex "Remove-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' "; #adding Exception Rules for inbound and outbound Rules iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Outbound -LocalPort $ports_a -Action Allow -Protocol TCP"; iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Inbound -LocalPort $ports_a -Action Allow -Protocol TCP"; for( $i = 0; $i -lt $ports.length; $i++ ){ $port = $ports[$i]; iex "netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr"; iex "netsh interface portproxy add v4tov4 listenport=$port listenaddress=$addr connectpor t=$port connectaddress=$remoteport"; }

Una solución alternativa es ir al Administrador de Hyper-V y cambiar el conmutador virtual que está vinculado a la NIC física.

funcionó para mí, estoy usando CiscoAnyConnect para VPN

 Get-NetAdapter | Where-Object {$_.InterfaceDescription -Match "Cisco AnyConnect"} | Set-NetIPInterface -InterfaceMetric 4000

Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Conjunto-NetIPInterface -InterfaceMetric 1

Créditos: Cisco AnyConnect

Para mí, tenía una nueva instancia de Ubuntu 20.04 WSL, después de instalar apache y permitir el perfil de apache usando este comando

 sudo ufw allow in "Apache"

Luego,

 sudo service ufw start && sudo ufw enable

Noté que este problema se ha desencadenado y después de deshabilitar el firewall nuevamente usando

 sudo ufw disable && sudo service ufw stop

todo funcionó bien.

Tal vez fue una coincidencia , pero activar Hyper-V ejecutando Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All en Powershell como administrador y reiniciar pareció resolver el problema cuando nada más lo hizo. Había probado la mayoría de las soluciones, excepto la que involucraba a Hyper-V Manager; Estaba activando Hyper-V para probar ese pero finalmente no tuve que hacer nada más.

Si fue una coincidencia, es posible que los servidores de archive.ubuntu.com no estuvieran disponibles temporalmente. El hecho de que nunca perdí la capacidad de hacer ping a otras direcciones lo respalda. Un comentario sobre esta pregunta de AskUbuntu dice:

A veces encuentra que los servidores no están disponibles o están caídos. . . Por lo general, el problema se resuelve solo después de un tiempo.

En otras palabras, a veces este problema es del lado del servidor. No creo que nadie aquí haya mencionado esa posibilidad todavía.

Comprueba qué antivirus estás usando. Tenía McAfee y la seguridad de endpoint habilitada. Si se desconecta, la conectividad del cortafuegos de seguridad de End Point funcionará de inmediato (no es necesario reiniciar).

https://kc.mcafee.com/corporate/index?page=content&id=KB91411

Tuve el mismo error cuando apliqué la compresión de unidad NTFS de Windows en el disco C: . Se muestra una investigación adicional, que la compresión de solo dos carpetas conduce a ese error:

1. Carpeta WSL ( %LocalAppData%\Packages\CanonicalGroupLimited* )
2. %TEMP% (es decir, C:\Users\<Username>\AppData\Local\Temp )

Entonces, si tiene una Temporary failure resolving... error con sudo apt-get update en WSL, le recomiendo no aplicar la compresión de disco NTFS a la unidad del sistema, o al menos mantener esos dos directorios sin comprimir.

Además, no olvide reiniciar su WSL en CMD o terminal PowerShell después de la descompresión con wsl --shutdown

Resolví el problema cambiando /etc/resolv.conf a:

 nameserver 8.8.8.8

y luego

 $ sudo chattr -f +i /etc/resolv.conf

en realidad 'bloquea' el archivo con el atributo +i==immutable y, por lo tanto, el sistema operativo no puede regenerarlo. De esta forma, el /etc/resolv.conf modificado por el usuario será persistente.

Descubrí que crear /etc/wsl.conf no funcionó, pero lo dejé de todos modos:

 [network] generateResolvConf = false

Ejecute estos comandos en cmd:

 $ wsl --shutdown $ netsh winsock reset $ netsh int ip reset all $ netsh winhttp reset proxy $ ipconfig /flushdns $ netsh winsock reset $ shutdown /r