Puncte:0

Cum redirec tot traficul care sosește într-un anumit port către alt port?

drapel gb

Cum redirec tot traficul care sosește într-un anumit port către alt port?

Definiți aspectul și problema

Schema

Iată schema a ceea ce încerc să fac...

+--------+ +---------------------+ +---------------- +
| WAN | <---> | 6789 | | |
| Client | | Gateway | | Gazdă |
| | | 4567 | <---> | 2345 Service |
+--------+ +---------------------+ +---------------- +

Vreau să redirecționez în mod transparent tot traficul care sosește pe portul 6789 către portul 4567. Clientul de pe WAN și serviciul de pe gazdă nu ar trebui să știe nimic despre gateway.

Poarta de acces este Debian 10 cu firewalld.

Problema

Nu pot obține traficul care sosește la portul 6789 pe gateway pentru a redirecționa către portul 4567.


Configurația actuală

Pasul 01 - Expuneți portul pe firewall și confirmați că portul este deschis.

Deschideți portul de pe gateway

  1. Rulați firewall-cmd comanda: firewall-cmd --add-port=6789

  2. Verificați starea firewall-ului...

root@gateway:~# firewall-cmd --list-all
public (activ)
  target: implicit
  icmp-block-inversion: nu
  interfețe: etho0
  surse: 
  servicii: dhcpv6-client http https ssh
  porturi: 6789/tcp
  protocoale: 
  mascarada: da
  porturi înainte: 
  porturi sursă: 
  icmp-blocks: 
  reguli bogate:
  1. Confirmați că portul este deschis.
  • Pe gateway, porniți un ascultător: nc -vvlp 6789 &
  • Confirmați că ascultătorul este trezit...
root@gateway:~# netstat -tulnp | grep 6789
tcp 0 0 0.0.0.0:6789 0.0.0.0:* ASCULTĂ 2274/nc
  • De la client, încercați să ajungeți la gateway:
client@client123:~$ nc -vvN gateway.example.org 6789
Conexiunea la portul gateway.example.org 6789 [tcp/*] a reușit!

Concluzie: Portul 6789 este deschis pe firewall.

Curățați ucigând nc proces atât pe client, cât și pe gateway.

Pasul 02 - Confirmați conexiunea dintre gateway și serviciul de pe gazdă

root@gateway:~# telnet localhost 4567
Încercați 127.0.0.1...
Conectat la localhost.
Caracterul de evacuare este „^]”.
220 backendhost.backendhost MyService (Debian/GNU)

Concluzie: tunelul dintre gateway și serviciul de pe gazdă este sus.

Pasul 03 - Adăugați port forward pe gateway și verificați starea firewall-ului

root@gateway:~# firewall-cmd --add-forward-port=port=6789:proto=tcp:toport=4567`
root@gateway:~# firewall-cmd --list-all
public (activ)
  target: implicit
  icmp-block-inversion: nu
  interfețe: etho0
  surse: 
  servicii: dhcpv6-client ssh
  porturi: 6789/tcp
  protocoale: 
  mascarada: nu
  forward-ports: port=6789:proto=tcp:toport=4567:toaddr=
  porturi sursă: 
  icmp-blocks: 
  reguli bogate: 

Concluzie: port forward este în firewall.


În acest moment, dacă încerc să telnet gazda de la client, primesc...

client@client123:~$ telnet gateway.example.org 6789
Se încearcă <IP_of_gateway>...
telnet: Imposibil de conectat la gazda de la distanță: Conexiune refuzată

În acest moment, vreau să văd ce am văzut la Pasul 02 de mai sus.

Întrebările

Aici nu sunt sigur de...

Când alerg netstat -tulnp pe gateway, NU arată nimic care ascultă pe portul 6789. Nu mă aștept, deoarece nu am niciun serviciu care rulează care să asculte pe portul 6789.

Am nevoie de un fel de serviciu pentru a asculta pe portul 6789? Si ce daca? Sau îmi lipsește ceva din setările firewall-ului? Am nevoie de un fel de proxy transparent, așa cum este menționat Aici?

Nu voi aglomera această postare cu link-uri către toate lucrurile pe care le-am citit în ultimele două săptămâni, dar dacă există o postare care are răspunsul, nu ezitați să-l subliniați.

Editați | ×

Ca răspuns la @A.B

Gazda rulează în spatele unui firewall. Când gazda este pornită, aceasta creează automat un tunel către gateway folosind un port SSH forward.

Iată comanda pe care o rulează gazda la pornire: ssh -N -R 4567:localhost:2345 [email protected]

Acest tunel este sus, așa cum s-a confirmat în Pasul 02. Și, deși nu am menționat mai devreme, clientul funcționează atunci când este pe aceeași rețea LAN cu gazda.

Ceea ce mă lupt este ca traficul care sosește la gateway să fie transmis cu succes către gazdă. Poarta de acces trebuie să fie „transparentă”. Certificatul de securitate este deținut de gazdă și clientul ar trebui să creadă că vorbește direct cu gazda.

Încă încerc să învăț terminologiile, așa că dacă există o modalitate mai corectă de a pune această întrebare, cu siguranță sunt deschis să știu ce este.

Michael Hampton avatar
drapel cz
Ai nevoie de ceva pentru a asculta pe portul 4567.
user371793 avatar
drapel gb
@MichaelHampton - Mulțumesc pentru răspuns. Pe gazdă, există un port forward SSH care este configurat să se conecteze automat la gateway. Port forward-ul este conectat și, din câte am înțeles și arăt în Pasul 02, ascultă pe portul 4567. Sau am înțeles greșit ceva despre ce vrei să spui când spui că „am nevoie de ceva de ascultat pe portul 4567”? Multumesc din nou.
A.B avatar
drapel cl
A.B
Vocabularul care ar trebui folosit (și așteptat de cei care vă citesc întrebarea) este „redirecționează către gazdă pe portul 2345”, nu „redirecționează către portul 4567”. Unele porturi din schema ta apar ca destinație, altele ca sursă (sau nu am înțeles cum să citesc schema). Ar trebui să vă clarificați întrebarea.
Michael Hampton avatar
drapel cz
Să revenim la elementele de bază aici. Ce rost are să schimbi portul folosind firewalld? Puteți avea doar redirecționarea portului ssh pentru a asculta direct pe portul dorit.
Puncte:0
drapel gb

Multumesc pentru diversele comentarii.

Erau două lucruri care îmi lipseau...

  1. GatewayPorts în /etc/ssh/sshd_config trebuiau schimbate din valoarea implicită Nu la specificat de client
  2. The ssh comanda trebuia schimbată de la ascultare pe loopback la ascultare pe toate adresele. Comanda actualizată arată astfel: ssh -N -R 0.0.0.0:4567:localhost:2345 [email protected] (Observați 0.0.0.0: care a fost adăugat în fața portului 4567.)

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.