Problema de superposición del rango de red OpenVPN

Problema de superposición del rango de red OpenVPN

Un novato en redes aquí. Configuré un servidor OpenVPN en mi red doméstica para poder usar Wi-Fi público para conectarme primero a mi red doméstica y luego usar Internet con cierto grado de seguridad. Seguí este tutorial para configurarlo:https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-14-04. Por lo que puedo decir, es una configuración OpenVPN de tipo túnel muy simple. Cuando trabajo normalmente, puedo acceder a Internet a través de este servidor OpenVPN, así como conectarme a servidores en mi red doméstica.

Sin embargo, noté un problema. El rango de red IPv4 de mi hogar es 10.0.1.0/24, que es el valor predeterminado que viene con mi enrutador Mac AirPort Extreme. Cuando voy a la casa de un amigo o a otro lugar público cuyo enrutador también usa el 10.0.1.0/24rango IPv4, puedo conectarme a mi red doméstica, pero no puedo acceder a nada allí. La razón es obvia: la red local en la que estoy utiliza el mismo rango y puerta de enlace predeterminada que la configuración de mi hogar.

Podría cambiar el rango de mi red, pero luego me encontraría con un problema similar cada vez que el rango de la red IPv4 local de alguien fuera el mismo.

Mi pregunta es: ¿qué tipo de configuración necesitaría para evitar este problema? ¿Es esta la razón para utilizar una configuración TAP en lugar de TUN? Estoy más buscando un lugar para empezar. Aquí está la configuración de mi servidor:

/etc/openvpn/server.conf

port 1194
proto udp
dev tun

ca ca.crt
cert server.crt
dh dh2048.pem

server 10.8.0.0 255.255.255.0    # IP range for connecting users
ifconfig-pool-persist ipp.txt

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.0.1.13" # My local DNS server
push "dhcp-option DNS 10.0.1.1"  # My home router DNS
push "dhcp-option DNS 8.8.8.8"   # Google public DNS

keepalive 10 120
comp-lzo

user nobody
group nogroup

persist-key
persist-tun

status openvpn-status.log
verb 3

**** EDITAR 1 ****

Encontré estos recursos:

https://openvpn.net/index.php/open-source/documentation/howto.html#numbering

https://serverfault.com/questions/21399/cómo-evitar-conflictos-de-red-con-redes-vpn-internas

¿Realmente no hay otra manera de solucionar este problema que no sea elegir una subred IPv4 privada menos utilizada?

Respuesta1

Como dijo @Ecnerwal, no se puede evitar el problema, solo mitigarlo, aunque existen algunos trucos para reducir MUCHO la probabilidad de colisión.

Puede usar 172.31.xx (la gente rara vez parece darse cuenta de que 172.16-32.xx está reservado de la misma manera que 192.168.xx y 10.xxx y, por lo tanto, prácticamente nunca se usa) o, si desea romper ligeramente los estándares, 100.64 .0.x
100.64.0.x no debe usarse en redes domésticas como su "NAT de grado de operador". Dado que está encapsulando los puntos finales, probablemente pueda salirse con la suya rompiendo las reglas.

Al especificar su rango, probablemente desee especificar el rango más pequeño que pueda: es mucho menos probable que una subred /30 (es decir, 4 direcciones IP en el medio del rango) interfiera con máquinas específicas detrás de nat, y debería funcionar bien en Practica porque es una ruta muy específica.

Por supuesto, otra solución sería cambiar su túnel a IPV6.

información relacionada