Solución:
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
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 ha vuelto a pasar y lo he resuelto 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 Evitar que /etc/resolfv.conf se “corrompa”
- Crea un archivo:
/etc/wsl.conf
. - Pon las siguientes líneas en el archivo
[network]
generateResolvConf = false
- en un
cmd
ventana, correrwsl --shutdown
- Reiniciar WSL2
- Crea un archivo:
/etc/resolv.conf
. Si existe, reemplace uno existente con este nuevo archivo. - Pon las siguientes líneas en el archivo
nameserver 8.8.8.8
- Repita los pasos 3 y 4. Verá
git
trabajando bien ahora.
Créditos a NonStatic que lo compartió en github
2 Elimine los controladores de interfaz de red dañados (podría ser permanente)
-
Primero ve al administrador de dispositivos
-
Mostrar dispositivos ocultos
-
Eliminar todo el adaptador de extensión de conmutador virtual de Hyper-V
Créditos a Jaysonsantos que lo compartieron en GitHub
Lo más probable es que la Distribución obtenga su propio adaptador virtual, primero hay algunos pasos que puede intentar:
-
Necesito verificar si los paquetes realmente pasan por el firewall de Windows
Entonces revisa%systemroot%system32LogFilesFirewallpfirewall.log
-
Si los paquetes no pasan por el firewall, lo más probable es que la distribución obtenga su propio Adaptador virtual, verifique qué IP recibe la distribución desde 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 lleva la máquina bajo el adaptador WSL
- Si necesita tener acceso a Internet a través de la IP de Windows, verifique este problema: https://github.com/microsoft/WSL/issues/4150
La solución consiste en utilizar un script que haga lo siguiente:
una. Obtener 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 las 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
[email protected](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.