Permitir SSH en un servidor con un cliente OpenVPN activo

15

Tengo un VPS con CentOS 7 al que me conecto con SSH. Me gustaría ejecutar un cliente OpenVPN en el VPS para que el tráfico de Internet se enrute a través de la VPN, pero aún así me permita conectarme al servidor a través de SSH. Cuando inicio OpenVPN, mi sesión SSH se desconecta y ya no puedo conectarme a mi VPS. ¿Cómo puedo configurar el VPS para permitir que las conexiones entrantes SSH (puerto 22) se abran en la IP real del VPS (104.167.102.77), pero aún enrutar el tráfico saliente (como desde un navegador web en el VPS) a través de la VPN?

El servicio OpenVPN que uso es PrivateInternetAccess, y un archivo de ejemplo config.ovpn es:

cliente
Dev Tun
proto udp
remoto nl.privateinternetaccess.com 1194
resolv-retry infinite
nobind
clave persistente
persist-tun
ca ca.crt
tls-client
servidor remote-cert-tls
auth-user-pass
comp-lzo
verbo 1
reneg-sec 0
crl-verificar crl.pem

IP addr de VPS:

1: lo: mtu 65536 qdisc noqueue state DESCONOCIDO
    enlace / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    inet 127.0.0.1/8 ámbito host lo
       válido_lft para siempre preferido_lft para siempre
    inet6 :: host de alcance 1/128
       válido_lft para siempre preferido_lft para siempre
2: ens33: mtu 1500 qdisc pfifo_fast state UP qlen 1000
    enlace / éter 00: 50: 56: be: 16: f7 brd ff: ff: ff: ff: ff: ff
    Inet 104.167.102.77/24 brd 104.167.102.255 alcance global ens33
       válido_lft para siempre preferido_lft para siempre
    inet6 fe80 :: 250: 56ff: febe: 16f7 / 64 enlace de alcance
       válido_lft para siempre preferido_lft para siempre
4: tun0: mtu 1500 qdisc pfifo_fast estado DESCONOCIDO qlen 100
    enlace / ninguno
    inet 10.172.1.6 igual 10.172.1.5/32 alcance global tun0
       válido_lft para siempre preferido_lft para siempre

Ruta IP del VPS:

0.0.0.0/1 a través de 10.172.1.5 dev tun0
predeterminado a través de 104.167.102.1 dev ens33 proto static metric 1024
10.172.1.1 a través de 10.172.1.5 dev tun0
10.172.1.5 dev tun0 proto kernel scope link src 10.172.1.6
104.167.102.0/24 dev ens33 proto kernel scope link src 104.167.102.77
109.201.154.177 a través de 104.167.102.1 dev ens33
128.0.0.0/1 a través de 10.172.1.5 dev tun0
odie5533
fuente

Respuestas:

15

Tengo un problema similar a este y he intentado la solución descrita en esta publicación del foro .

La idea es que actualmente cuando se conecta a su dirección IP pública, los paquetes de retorno se enrutan a través de la VPN. Debe forzar que estos paquetes se enruten a través de su interfaz pública.

Con suerte, estos comandos de ruta harán el truco:

regla ip agregar de xxxx tabla 128

ruta ip agregue la tabla 128 a yyyy / y dev ethX

ruta IP agregar tabla 128 por defecto a través de zzzz

Donde xxxx es su IP pública, aaaa / y debería ser la subred de su dirección IP pública, ethX debería ser su interfaz Ethernet pública y zzzz debería ser la puerta de enlace predeterminada.

Tenga en cuenta que esto no me ha funcionado (usando Debian y PrivateInternetAccess) pero puede ayudarlo.

MrK
fuente
1
En lugar de simplemente vincularse a una solución, indique o al menos resuma la solución aquí. De esa manera, su publicación aún puede ser útil en el futuro si la publicación a la que se vinculó desaparece.
Andrew Schulman
Ejecuté estos comandos en vano ... ¿Cómo enumeraría esta tabla (no puedo ver las nuevas reglas que agregué con routeo ip route show) y la elimino?
Hussain Khalil
Perdí mi ssh en mi IP pública cuando me puse de pie openvpn en mi servidor doméstico. Ejecutar el primer comando mencionado anteriormente me permitió obtener acceso ssh nuevamente al servidor cuando no estaba en la LAN local. Usando PIA + OpenVPN + ubuntu 16.04.
aburrido
¿Realmente solo enruta el puerto SSH a mi IP pública? ¿Puedes explicar más sobre lo que esto hace exactamente? No veo ningún lugar donde configure un puerto o protocolo específico
Freedo
No se enruta en función de los puertos (128 es el número de la tabla, no un puerto). Básicamente dice que si los paquetes llegan a través de su dirección IP pública, la respuesta debe enviarse en la misma interfaz (sin usar la VPN).
MrK
17

Esto puede ser un poco tarde, pero ...

El problema es que OpenVPN cambia la puerta de enlace predeterminada, y eso interrumpe su conexión SSH actual a menos que configure las rutas apropiadas antes de iniciar OpenVPN.

Lo que sigue funciona para mí. Utiliza iptables e ip (iproute2). A continuación, se supone que la interfaz de puerta de enlace predeterminada antes de iniciar OpenVPN es "eth0". La idea es asegurar que cuando se realiza una conexión a eth0, incluso si eth0 ya no es la interfaz de puerta de enlace predeterminada, los paquetes de respuesta para la conexión vuelven a eth0 nuevamente.

Puede usar el mismo número para la marca de conexión, la marca de firewall y la tabla de enrutamiento. Usé números distintos para hacer que las diferencias entre ellos fueran más aparentes.

# set "connection" mark of connection from eth0 when first packet of connection arrives
sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234

# set "firewall" mark for response packets in connection with our connection mark
sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 table 3412

# route packets with our firewall mark using our routing table
sudo ip rule add fwmark 4321 table 3412

===

ACTUALIZAR:

Lo anterior funciona bien para mí en Debian Jessie. Pero en un sistema Wheezy más antiguo, acabo de descubrir que necesito agregar "via" a la entrada de la tabla de enrutamiento:

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 via 12.345.67.89 table 3412

Allí "12.345.67.89" debe ser la puerta de enlace no VPN original.

John Doe
fuente
1
¡GRACIAS! He estado buscando una solución para este problema durante días, y su respuesta me lo resolvió. Esta debería ser la respuesta aceptada.
Mike Turley
Esta solución también funcionó para mí. Muchas gracias por compartir esto.
alecov
¿Puede haber dos rutas en la tabla de enrutamiento con el mismo destino ( ip route add default)? Obtengo "RTNETLINK respuestas: el archivo existe". Estoy ejecutando Ubuntu Xenial. "vía" no ayuda. Acabo de probarlo en Arch Linux, primero ip route add defaultparece tener éxito, pero la ip routesalida no cambia. Cualquier ejecución posterior da como resultado el mensaje "el archivo existe".
x-yuri
Ya veo, la ruta se agrega a la tabla de enrutamiento 3412. Y para llegar a ella tienes que: ip route show table all | grep 3412. Y sin "vía" las conexiones no establecidas (si no me equivoco) dejan de funcionar (Ubuntu Xenial). Al menos puedo corregir la tabla de enrutamiento. Sin embargo, no puedo acceder al servidor después de ejecutarlo openvpn.
x-yuri
No funcionó para mí por alguna razón, a diferencia de esto , o esto , o esto . Que son básicamente lo mismo.
x-yuri
12

Basado en la respuesta @MrK, he escrito un código simple aquí para que sea más rápido hacer el trabajo para que no tenga que verificar las interfaces / IP:

ip rule add from $(ip route get 1 | grep -Po '(?<=src )(\S+)') table 128
ip route add table 128 to $(ip route get 1 | grep -Po '(?<=src )(\S+)')/32 dev $(ip -4 route ls | grep default | grep -Po '(?<=dev )(\S+)')
ip route add table 128 default via $(ip -4 route ls | grep default | grep -Po '(?<=via )(\S+)')

He probado este script en 4 de mi VPS y está funcionando perfectamente.

SandPox
fuente
Muchas gracias!
Jordi Goyanes
0

hmm suena como una superposición de subred de ip ... sin saber más acerca de su esquema de ip, aparte de la ip pública para su terminación de vpn como nl.privateinternetaccess.com, no puedo asegurarlo.

así, por ejemplo, si la subred remota en el otro lado de nl.privateinternetaccess.com es 10.32.43.0/24, y su instancia está en un vpc aws cuya subred es 10.32.44.0/24. pero su cliente ssh de origen vive en 10.32.43.0/24 (su lado de aws vpc), no funcionará, ya que el tráfico ssh de retorno se enviará erróneamente sobre vpn a los países bajos.

proporcione información completa de ip / subred para obtener más ayuda con esto.

...

ok, entonces ... parece que tu ruta predeterminada está en el túnel, después de conectarte a nl:

0.0.0.0/1 a través de 10.172.1.5 dev tun0

para que pueda cambiar eso después de conectarse. Muchas veces los servidores VPN le dan rutas falsas. especialmente en cuerpo descuidado. en este caso, le están enviando una ruta predeterminada para que todo el tráfico del cuadro vps vaya a nl. cambie la ruta predeterminada a 104.167.102.xo cualquier puerta de enlace de subred que esté en su proveedor de vps.

nandoP
fuente
¿Qué salidas de comandos serían suficientes?
odie5533
1
salida de "ip addr" y "ip route" en cliente ssh, servidor ssh / cliente vpn y servidor nl vpn. asegúrese de que vpn esté activo cuando obtenga la salida.
nandoP
Quiero que el tráfico por defecto pase por la VPN; sin embargo, quiero que se permita el tráfico entrante en 104.167.102.77:22 para poder enviar SSH al VPS.
odie5533
lo verifica con tcpdump, pero parece que después de conectarse, y la ruta predeterminada se convierte en túnel, el nuevo tráfico ssh entrante desde otro lugar en Internet está permitido, pero no regresa, ya que la ruta predeterminada envía la respuesta ssh a través del túnel, en lugar de volver a ti. puede solucionar esto "ip route add [your-ip-addr] / 32 a través de [su puerta de enlace vps]". para encontrar su puerta de enlace vps, simplemente desconéctese del túnel y busque la ruta predeterminada
nandoP
0

Cuando activa la VPN, se reemplaza su puerta de enlace predeterminada. Esto significa que todo el tráfico generado o enrutado a través de su caja se enviará a la puerta de enlace VPN.

Una solución simple es filtrar todo el tráfico que no desea enrutar a través de la VPN y hacer algo más con él. Una posibilidad es recoger el tráfico generado desde su casilla con su dirección de origen local y enrutarlo a través de su puerta de enlace local. Esto permite que servicios como SSH funcionen correctamente.

Haremos eso aquí. Primero, cree una nueva tabla de enrutamiento y agregue una ruta predeterminada que enrute todo a través de su puerta de enlace local:

# <table> is any number between 2 and 252.
# Check /etc/iproute2/rt_tables for more info.
ip route add default via <gateway> table <table>
ip route add <lan-addr> dev <device> table <table>

A continuación, cree una nueva regla de filtro de paquetes que marque todo el tráfico que sale de su casilla desde una dirección de origen determinada con algún identificador.

# <mark> is any number.
iptables -tmangle -AOUTPUT -s<local-addr> -jMARK --set-mark <mark>

Finalmente, cree una política de enrutamiento que seleccione todo el tráfico marcado mencionado anteriormente y lo enrute utilizando la tabla generada arriba.

ip rule add fwmark <mark> table <table>

Una vez más, los valores de <mark>y <table>son identificadores arbitrarios de su elección.

alecov
fuente
0

Para mí, ejecutar el servidor OpenVPN en pfSense fue desmarcar la configuración "Forzar todo el tráfico IPv4 generado por el cliente a través del túnel".

user3820047
fuente