Puncte:0

Oglindiți traficul de intrare pe un anumit port la un alt IP, folosind tunelul meu IPSec strongswan

drapel za

Vreau să public intern un server SMTP (IP 10.0.0.10) care se află în spatele unui tunel VPN pe serverul meu intern (192.168.0.12) folosind lebăda puternică. Ale mele lebăda puternică rulează într-un container docker.

Pentru asta vreau serverul meu intern 192.168.0.12 pentru a asculta portul său 25 și pentru a redirecționa traficul către serverul tunelizat de pe același port 10.0.0.10:25.

Până acum am încercat să folosesc iptables, dar fără succes.

net.ipv4.ip_forward este activat atât pe gazdă, cât și pe containerul docker!

Ale mele iptables-salvare pe 192.168.0.12 după ce strongswan este conectat la tunel: (și da, pot face ping la 10.0.0.10 de la 192.168.0.12)

# Generat de iptables-save v1.8.4 pe vineri, 23 iulie 09:55:05 2021
*filtru
:INPUT ACCEPT [0:0]
: FORWARD ACCEPT [0:0]
: ACCEPT IEȘIRE [0:0]
-A INPUT -s 10.0.0.0/16 -d 192.168.0.10/32 -i eth0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A IEȘIRE -s 192.168.0.10/32 -d 10.0.0.0/16 -o eth0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
COMMIT
# Finalizat vineri, 23 iulie 09:55:05 2021
# Generat de iptables-save v1.8.4 pe vineri, 23 iulie 09:55:05 2021
*nat
:ACCEPTAREA PRE-ROUTARE [0:0]
:INPUT ACCEPT [0:0]
: ACCEPT IEȘIRE [2:1600]
: POSTROUTING ACCEPT [2:1600]
:DOCKER_OUTPUT - [0:0]
:DOCKER_POSTROUTING - [0:0]
-A IEȘIRE -d 127.0.0.11/32 -j DOCKER_OUTPUT
-A POSTROUTING -d 127.0.0.11/32 -j DOCKER_POSTROUTING
-A DOCKER_OUTPUT -d 127.0.0.11/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.11:45165
-A DOCKER_OUTPUT -d 127.0.0.11/32 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.11:53306
-A DOCKER_POSTROUTING -s 127.0.0.11/32 -p tcp -m tcp --sport 45165 -j SNAT --to-source :53
-A DOCKER_POSTROUTING -s 127.0.0.11/32 -p udp -m udp --sport 53306 -j SNAT --to-source :53
COMMIT

comanda ip r ieșire:

implicit prin 192.168.16.1 dev eth0
192.168.16.0/20 dev eth0 proto kernel scope link src 192.168.16.10 # aceasta este o rețea internă Docker pentru serviciile mele
192.168.0.10/30 dev eth1 proto kernel scope link src 192.168.0.12

Am încercat diverse comenzi ca acestea:

iptables -t nat -A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 10.0.0.10:25
iptables -t nat -A POSTROUTING -p tcp -d 10.0.0.10 --dport 25 -j SNAT --to-source 192.168.0.12

dar fără succes.

Nu pot oferi nicio informație despre ip r a gazdei nici a iptables-salvare.

ce fac greșit?

Tom Yan avatar
drapel in
Vă rugăm să furnizați rezultatul următoarelor comenzi pe *atât pe gazda containerului, cât și pe container*: `ip r` (și poate și `ip a`), `iptables-save` și `sysctl net.ipv4.ip_forward`.
drapel za
@TomYan a adăugat toate informațiile pe care le-am putut aduna, sunt restricționat pe mașina gazdă. Am reușit să întreb gazda dacă redirecționarea IP a fost activată și este activată.
Tom Yan avatar
drapel in
Nu înțeleg. Nu aveți control asupra „serverul meu intern (192.168.0.10)”? Sau este de fapt un alt container? (Rulând în paralel cu cel Strongswan, care este `192.168.0.12`?)
Tom Yan avatar
drapel in
De asemenea, ieșirea `ip r` pare dezactivată.`192.168.0.12` nu este nici măcar o adresă de gazdă validă cu `/30` (deoarece ar fi ID-ul subrețelei).
drapel za
@TomYan vă mulțumesc pentru ajutor, am actualizat IP-urile, astfel încât acestea să fie corecte acum. Nu am control asupra gazdei care rulează containerul docker. Controlez doar containerul docker în sine `192.168.0.12`. Sunt sigur că problema nu este cu gazda, ci cu configurația `iptables` din interiorul containerului docker.
Tom Yan avatar
drapel in
Problema este, pentru cine/care gazdă(e) serverul/containerul va servi/redirecționează? Și cum a fost configurată această adresă pe acest „eth1”? DHCP? Static? (De la tine?) După cum am spus, rezultatul lui `ip r` nu are sens. Este măcar o pastă „adevărată”? (Sau este ceva „scrieți/tastați-l în jos”?) Și această „rețea internă docker” (`eth0`) ar trebui să fie irelevantă pentru obiectivul/clienții dvs. de aici?
Tom Yan avatar
drapel in
De asemenea, dacă acest server/forwarder de aici este același container cu cel strongswan, unde este chiar ruta către tunel? Ai configurat rutarea politicilor sau ce?
drapel cn
Cum testezi asta? Prin conectarea la portul 25 al gazdei? Sau dintr-un alt container? Oricum, aceste pachete intră efectiv în container și respectă regulile NAT?
drapel za
@ecdsa Testez asta cu `telnet 10.0.0.10 25` pe `containerul strongswan` și scopul este să `telnet strongswan 25` presupunând că numele containerului este `strongswan`
Puncte:0
drapel za

Mi-am rezolvat problema folosind traefik.

Am instalat traefik pe gazdă (192.168.0.12) care are tunelul strongswan și a folosit a Router TCP pentru a transmite tot traficul către tunel.

traefik instalare:

wget -O /traefik.tar.gz https://github.com/traefik/traefik/releases/download/v2.4.12/traefik_v2.4.12_linux_amd64.tar.gz \
    && tar -zxvf /traefik.tar.gz \
    && ln -s /traefik /usr/bin/traefik

traefik.yaml:

puncte de intrare:
  smtp:
    adresa: ":1025"

jurnal de acces: {}

furnizori:
  fişier:
    director: /traefik-conf/dynamic/
    ceas: adevărat

API:
  tabloul de bord: adevărat
  nesigur: adevărat

Ale mele /traefik-conf/dynamic/dynamic.yaml:

tcp:
  routere:
    smtp-router:
      regula: "HostSNI(`*`)"
      puncte de intrare:
        - smtp
      serviciu: smtp-service

  Servicii:
    serviciu smtp:
      echilibrarea greutății:
        servere:
          - adresa: 10.0.0.10:25

Alerga traefik (Nu știu cum să-l rulez corect ca un daemon de fundal):

traefik --configfile /traefik-conf/traefik.yml &

Acum mă pot conecta la tunelul server smtp de oriunde în interiorul rețelei mele folosind 192.168.0.12:1025.

Am creat un exemplu folosind docker over aici pe github

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.