Éste me tiene confundido:
Tengo un firewall pfSense (llamémoslo pfs) y detrás de él varios servidores. Realizo NAT de varios servicios desde mi IP pública a diferentes servidores en la LAN sin ningún problema.
En uno de los servidores (llamémoslo s1) estoy ejecutando una vagrant(con libvirt) VM (llamémoslav1 ) con unpúblicored configurada, que obtiene IP 192.168.1.159a través pfsdel servidor DHCP.
Ahora configuro una NAT simple pfspara acceder s1al SSH, digo <wan>:6622 -> s1:22y accedo a él mydomain.com:6622. Ningún problema.
También puedo acceder v1:22(o el equivalente192.168.1.159:22 ) con un usuario ssh válidodesde dentro de la LANsin problema.
Ahora agrego una NAT simple pfs, digamos <wan>:6722 -> v1:22. Ahora intentando accedermydomain.com:6722 no es¡¿trabajar?!
El objetivo es añadir incluso "otra capa": ejecutar contenedores con puertos públicos, por ejemplo, --publish 9980:80y v1acceder a ellos como, por ejemplo, v1:9980y desde mydomain.com:9980con el NAT correspondiente en pfsforma similar.<wan>:9980 -> v1:9980 .Desde la LANEsto también funciona como se esperaba (es decir, puedo acceder v1:9980desde la LAN), pero una vía NAT pfsno.
Tengo configuraciones similares trabajando dentro de la misma red en diferentes máquinas sin problemas. Incluso tengo otra libvirtmáquina virtual (no vagabunda, pero también) s1a la que puedo enviar ssh a través de NAT a través de mi IP pública perfectamente. Pero de alguna manera lo anterior no funciona con la vagrantmáquina y realmente no sé qué podría estar causando este problema. (FWIW lo he net.ipv4.forwardhabilitado v1).
EDITAR:
Me acerqué un paso más: si destruyo la primera NIC existente de la vagrantVM usando virt-managery configuro la segunda VM en rtl8139lugar de virtio(y luego reinicio), pierdo vagrant sshcapacidad pero NAT funciona. Entonces la pregunta es: ¿cómo configurar mediante vagrantaprovisionamiento de modo que tengamos una configuración similar? Supongo que eso significa que la red pública debe estar en la interfaz predeterminada.
Respuesta1
Solución:
La causa es que vagrantrequiere (y por lo tanto configura) su interfaz local (red privada) como principal, sin ningún método estándar para anularla. (Alguna información esaquí, pero la vagrantgente admite que ellos mismos están confundidos por el tema...)
Una variación (más sólida) del concepto para modificar las rutas predeterminadas trajo la solución. Estoy usando un ansibleaprovisionador, donde ejecuto lo siguiente (en el invitado, a través del libro de estrategias de aprovisionamiento):
- name: remove wrong default route on eth0 (again)
shell: |
eval $(route -n | awk '$0~/[.0]{4}/ && $3~/[.0]{4}/ && $8~/eth0/ { printf "ip route del default via %s dev %s; ",$3,$8 }')
(Curiosamente, debe ejecutarse dos veces (¿o después de un tiempo?), ¿posiblemente porque la red no se ha activado por completo cuando se inició el script de aprovisionamiento?)
Esto elimina la ruta predeterminada eth0( public_networksolo se configurará automáticamente en eth1) vagranty hace que las conexiones externas funcionen como se esperaba. Presumiblemente, esto se debe (especulando aquí) al hecho de que las respuestas a las solicitudes NAT entrantes se enrutan al firewall a través de la ruta predeterminada eth0(que por vagrantdefecto tiene prioridad), lo que confunde al FW NAT porque entró en la máquina virtual eth1. Por lo tanto, eliminar eth0las respuestas predeterminadas a las solicitudes externas en la misma interfaz en la que llegaron.