Port forwarding ssh iptables di Linux (rifiuto marziano)


12

Ho un gateway Linux che esegue NAT per la mia rete domestica. Ho un'altra rete a cui vorrei inoltrare i pacchetti in modo trasparente, ma solo a / da IP / porte specifici (cioè non una VPN). Ecco alcuni esempi di IP e porte con cui lavorare:

Source          Router          Remote Gateway     Remote Target
192.168.1.10 -> 192.168.1.1 ->  1.2.3.4        ->  192.168.50.50:5000

Vorrei che la macchina Source fosse in grado di comunicare con porte specifiche su Remote Target come se fosse direttamente instradabile dal router. Sul router, eth0 è la rete privata e eth1 è rivolto a Internet. Remote Gateway è un'altra macchina Linux in cui posso accedere e può indirizzare direttamente a Remote Target.

Il mio tentativo di una soluzione semplice è impostare il port forwarding ssh sul router, come ad esempio:

ssh -L 5000:192.168.50.50:5000 1.2.3.4

Funziona bene con il router, che ora può connettersi localmente alla porta 5000. Quindi "telnet localhost 5000" sarà collegato a 192.168.50.50:5000 come previsto.

Ora voglio reindirizzare il traffico da Source e incanalare attraverso il tunnel ssh ormai consolidato. Ho tentato una regola NAT per questo:

iptables -t nat -D PREROUTING -i eth0 -p tcp -s 192.168.1.10 --dport 5000 -d 1.2.3.4 -j DNAT --to-destination 127.0.0.1:5000

e poiché il router è già il mio gateway NAT, ha già la regola di postrouting necessaria:

-A POSTROUTING -s 192.168.1.0/24 -o eth1 -j MASQUERADE

La maggior parte delle domande e risposte su questo sito o altrove sembrano avere a che fare con il forwarding delle porte del server o con NAT hairpin, entrambi i quali sto lavorando bene altrove, nessuno dei quali si applica a questa situazione. Certamente potrei DMZ inoltrare le porte di destinazione remota tramite Gateway remoto, ma non voglio che le porte siano accessibili a Internet, le voglio accessibili solo attraverso il tunnel SSH sicuro.

La migliore risposta che posso trovare riguarda il rifiuto dei pacchetti marziani nel kernel di Linux:

iptables, come reindirizzare la porta dal loopback?

Ho abilitato la registrazione dei marziani e confermato che il kernel rifiuta questi pacchetti come marziani. Solo che non lo sono: so esattamente a cosa servono questi pacchetti, da dove vengono e dove stanno andando (il mio tunnel SSH).

La soluzione "rotonda" presentata lì è applicabile a quella domanda originale, ma non si applica al mio caso.

Tuttavia, durante la scrittura / ricerca di questa domanda, ho aggirato il mio problema utilizzando l'associazione IP sorgente SSH in questo modo:

ssh -L 192.168.1.1:5000:192.168.50.50:5000 1.2.3.4
iptables -t nat -D PREROUTING -i eth0 -p tcp -s 192.168.1.10 --dport 5000 -d 1.2.3.4 -j DNAT --to-destination 192.168.1.1:5000

Dal momento che non sto usando il loopback, questo aggira il rifiuto marziano.

Pubblico ancora la domanda qui per due motivi:

  1. Nella speranza che qualcuno che sta cercando di fare qualcosa di simile in futuro possa trovare questo nelle loro ricerche e questa soluzione alternativa potrebbe aiutarli.
  2. Preferisco ancora l'idea di mantenere la mia porta ssh inoltra la connessione solo al loopback e di essere in grado di instradarli attraverso iptables. Dal momento che so esattamente cosa sono questi pacchetti e dove stanno andando, non dovrei avere un modo per segnalarli come tali in modo che il filtro marziano Linux non li rifiuti? Tutte le mie ricerche su questo argomento portano a rp_filter, che non ha aiutato affatto nei miei test. E anche se ha funzionato, non è specifico per i pacchetti esatti che sto cercando di consentire.

Sono interessato a contribuire con la mia domanda e soluzione alternativa alla ricerca generale per salvare qualcun altro le ore di ricerca che ho fatto solo per trovare vicoli ciechi, così come spero che qualcuno risponda alla parte loopback / marziana della mia domanda che rimane ancora aperta per me.


Su ulteriori letture del post Meta su UL vs SF, noto anche la richiesta di Michael di non crosspost. L'ho solo incrociato perché è stato specificamente contrassegnato off-topic in SF, quindi se è più appropriato e possibile spostare solo la domanda originale e chiudere questa, sarebbe fantastico.
Segna il

mettere net.ipv4.conf.default.rp_filter = 0 e net.ipv4.conf.all.rp_filter = 0 nel tuo /etc/sysctl.conf e fare "sudo sysctl -p" risolve il tuo problema?
Rui F Ribeiro,

Ho provato ad applicare entrambi direttamente, cioè. 'sysctl net.ipv4.conf.default.rp_filter = 0', incluso anche uno per la mia specifica interfaccia privata. Ho confermato che sono impostati tramite 'sysctl -a', tuttavia, i pacchetti marziani a 127.0.0.1 sono ancora respinti. E anche se funzionasse, aprire tutte le mie interfacce ai marziani NON è quello che voglio. Né voglio nemmeno aprire una singola interfaccia (albiet private). So esattamente quali pacchetti marziani voglio consentire e desidero / spero in un'espressione NAT / mangle di iptables per permettermi di ottenere questo risultato.
Segna il

Potresti voler net.ipv4.conf.default.rp_filter = 2 e qualche altra regola di iptables
Rui F Ribeiro,

Risposte:


1

Il problema con l'esecuzione di un DNAT a 127.0.0.1:5000 è che quando il lato remoto risponde, questi pacchetti ritornano nel motore di routing come se fossero originati localmente (da 127.0.0.1) ma hanno un indirizzo di destinazione esterno. SNAT / MASQUERADE corrispondenti all'interfaccia esterna li avrebbero catturati e riscritti, ma le decisioni di instradamento che devono essere prese affinché i pacchetti arrivino a quell'interfaccia vengono prima di tutto, e di default questi pacchetti sono falsi. Il motore di routing non può garantire che ti ricorderai di riscriverlo in seguito.

La cosa che dovresti essere in grado di fare invece è rifiutare qualsiasi connessione esterna a 192.168.1.1:5000 su iptables INPUT diversa da quelle provenienti da 192.168.1.10 usando l' !argomento prima della -sspecifica dell'indirizzo di origine. Se si utilizza il ripristino TCP come meccanismo di rifiuto ( -j REJECT --reject-with tcp-reset, anziché la destinazione ICMP predefinita non raggiungibile), sarà in gran parte identico alla situazione in cui nulla era in ascolto su quell'indirizzo: combinazione di porte per quanto riguarda il mondo esterno.


0

Vorrei usare openVPN per creare un tunnel dal router a RemoteGateway.

Quindi, sul router, aggiungerei un percorso:

route add -host RemoteTarget gw Indirizzo RemoteGateway-VPN

usa la semplice regola iptables ovunque tu voglia limitare a quali porte permetti a Source di arrivare.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.