Consentire SSH su un server con un client OpenVPN attivo

Ho un VPS con CentOS 7 a cui mi collego con SSH. Vorrei eseguire un client OpenVPN sul VPS in modo che il traffico Internet venga instradato attraverso la VPN, ma mi permetta comunque di connettermi al server tramite SSH. Quando avvio OpenVPN, la mia sessione SSH viene disconnessa e non riesco più a connettermi al mio VPS. Come posso configurare il VPS per consentire l'apertura delle connessioni SSH in entrata (porta 22) sull'IP effettivo del VPS (104.167.102.77), ma instradare comunque il traffico in uscita (come da un browser Web sul VPS) attraverso la VPN?

Il servizio OpenVPN che utilizzo è PrivateInternetAccess e un esempio di file config.ovpn è:

cliente
dev tun
proto udp
remote nl.privateinternetaccess.com 1194
resolv-retry infinite
nobind
persistono-chiave
persistono-tun
ca.
TLS-cliente
server remote-cert-tls
-Pass auth-user
comp-lzo
verbo 1
reneg-sec 0
crl-confirm crl.pem

Indirizzo IP di VPS:

1: lo: mtu 65536 qdisc noqueue state UNKNOWN
    link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    inet 127.0.0.1/8 scope host lo
       valido_lft per sempre preferito_lft per sempre
    inet6 :: host ambito 1/128
       valido_lft per sempre preferito_lft per sempre
2: ens33: mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link / etere 00: 50: 56: be: 16: f7 brd ff: ff: ff: ff: ff: ff
    inet 104.167.102.77/24 brd 104.167.102.255 portata globale ens33
       valido_lft per sempre preferito_lft per sempre
    inet6 fe80 :: 250: 56ff: febe: collegamento ambito 16f7 / 64
       valido_lft per sempre preferito_lft per sempre
4: tun0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    Link / nessuno
    inet 10.172.1.6 peer 10.172.1.5/32 portata globale tun0
       valido_lft per sempre preferito_lft per sempre

Percorso ip di VPS:

0.0.0.0/1 tramite 10.172.1.5 dev tun0
impostazione predefinita tramite 104.167.102.1 dev ens33 proto static metric 1024
10.172.1.1 tramite 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 tramite 104.167.102.1 dev ens33
128.0.0.0/1 tramite 10.172.1.5 dev tun0

Sto riscontrando un problema simile a questo e ho tentato la correzione descritta in questo post del forum .

L'idea è che attualmente quando ci si connette al proprio indirizzo IP pubblico, i pacchetti di ritorno vengono instradati tramite la VPN. È necessario forzare il routing di questi pacchetti sull'interfaccia pubblica.

Speriamo che questi comandi di rotta facciano il trucco:

regola ip aggiunta dalla tabella xxxx 128

ip route aggiungi la tabella 128 a yyyy / y dev ethX

ip route aggiunge la tabella 128 di default tramite zzzz

Dove xxxx è il tuo IP pubblico, yyyy / y dovrebbe essere la sottorete del tuo indirizzo IP pubblico, ethX dovrebbe essere la tua interfaccia Ethernet pubblica e zzzz dovrebbe essere il gateway predefinito.

Nota che questo non ha funzionato per me (usando Debian e PrivateInternetAccess) ma potrebbe aiutarti.

Potrebbe essere un po 'tardi, ma ...

Il problema è che il gateway predefinito viene modificato da OpenVPN e che interrompe la connessione SSH corrente a meno che non si impostino le route appropriate prima di avviare OpenVPN.

Quello che segue funziona per me. Utilizza iptables e ip (iproute2). Di seguito, si presume che l'interfaccia gateway predefinita prima dell'avvio di OpenVPN sia "eth0". L'idea è di garantire che quando viene stabilita una connessione a eth0, anche se eth0 non è più l'interfaccia gateway predefinita, i pacchetti di risposta per la connessione ritornano di nuovo su eth0.

È possibile utilizzare lo stesso numero per il segno di connessione, il segno del firewall e la tabella di routing. Ho usato numeri distinti per rendere più evidenti le differenze tra loro.

# 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

===

AGGIORNARE:

Quanto sopra funziona bene per me su Debian Jessie. Ma su un vecchio sistema Wheezy ho appena scoperto che devo aggiungere "via" alla voce della tabella di routing:

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

Lì "12.345.67.89" deve essere il gateway non VPN originale.

Sulla base della risposta di @MrK, ho scritto un semplice codice qui per rendere più veloce l'esecuzione del lavoro in modo da non dover controllare interfacce / 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+)')

Ho provato questo script su 4 del mio VPS e funziona perfettamente.

hmm suona come sovrapposizione della sottorete IP .... senza sapere di più sul tuo schema IP, oltre all'ip pubblico per la tua VPN VPN come nl.privateinternetaccess.com, non posso dirlo con certezza.

quindi, ad esempio, se la sottorete remota sull'altro lato di nl.privateinternetaccess.com è 10.32.43.0/24 e la tua istanza si trova in un vpc aws la cui sottorete è 10.32.44.0/24. ma il tuo client ssh di origine vive il 10.32.43.0/24 (il tuo lato di aws vpc), non funzionerà, poiché il traffico ssh di ritorno verrà trasferito erroneamente su vpn nei Paesi Bassi.

fornire informazioni complete su ip / subnet per ulteriori informazioni.

...

ok, quindi ... sembra che il tuo percorso predefinito sia nel tunnel, dopo esserti connesso a nl:

0.0.0.0/1 tramite 10.172.1.5 dev tun0

così puoi cambiarlo dopo esserti connesso. molte volte i server VPN offrono percorsi fasulli. specialmente nei corpi sciatti. in questo caso, stanno inviando un percorso predefinito verso di te, quindi tutto il traffico proveniente dalla casella vps sta per essere nl. cambia il percorso predefinito in 104.167.102.xo qualunque sia il tuo subnet gateway sia al tuo provider vps.

Quando si attiva la VPN, il gateway predefinito viene sostituito. Ciò significa che tutto il traffico generato o instradato attraverso la tua casella verrà inoltrato al gateway VPN.

Una soluzione semplice è quella di filtrare tutto il traffico che non si desidera instradare attraverso la VPN e fare qualcos'altro con esso. Una possibilità è quella di raccogliere il traffico generato dalla tua casella con il tuo indirizzo di origine locale e instradarlo attraverso il gateway locale. Ciò consente a servizi come SSH di funzionare correttamente.

Lo faremo qui. Innanzitutto, crea una nuova tabella di routing e aggiungi una route predefinita che instrada tutto attraverso il gateway locale:

# <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>

Successivamente, crea una nuova regola di filtro pacchetti che contrassegna tutto il traffico in uscita dalla tua casella da un determinato indirizzo di origine con un identificatore.

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

Infine, crea un criterio di routing che raccolga tutto il traffico contrassegnato sopra indicato e lo instrada utilizzando la tabella generata sopra.

ip rule add fwmark <mark> table <table>

Ancora una volta, i valori di <mark>e <table>sono identificatori arbitrari di tua scelta.

Per me con il server OpenVPN in esecuzione su me stesso in pfSense è stato deselezionare l'impostazione "Forza tutto il traffico IPv4 generato dal client attraverso il tunnel".