Jak skonfigurować przezroczysty tryb sslh w środowisku dokowania?


1

Chcę skonfigurować sslh na porcie 443, aby przekazywać dalej https i openvpn, które znajdują się w dwóch kontenerach dokowania. Ponieważ na dłuższą metę chcę udostępniać listy ACL oparte na protokole IP, chcę, aby sslh przekazywał prawdziwy adres IP klienta do serwera (tryb „przezroczysty” sslh).

Jak rozumiem dokumentacja i ta odpowiedź , sslh sfałszuje zewnętrzne żądania w sieci wewnętrznej i musi otrzymać zwrotną odpowiedź serwerów, aby przetłumaczyć port do komunikacji z klientem.

Moim problemem jest konfiguracja iptables. Istnieją dwie możliwości uruchomienia sslh: na hoście lub w kontenerze wewnątrz sieci dokującej.

Udało mi się uzyskać „domyślną” konfigurację, jak to opisano w dokumentacji, aby działała, tj .: sslh na hoście mógł przejrzeć w sposób przejrzysty na usługę na hoście.

Jednak nie mogę uzyskać przezroczystości sslh ani na hoście, ani w kontenerze, aby pracować z serwerami kontenerowymi. Dokładniej, moje reguły iptables, aby zaznaczyć ruch, który powinien zostać przekierowany do sslh, nigdy nie pasują do pakietu.

Na przykład. dla serwera https chciałbym:

iptables -t mangle -A OUTPUT -p tcp --sport 443 --source 172.25.0.2 --jump SSLH

Za pomocą ten wykres Próbowałem rozeznać, jak wirtualne urządzenia ethernetowe kontenera, most dokujący, doker NAT i iptables działają razem, ale nie mogę owinąć głowy wokół niego.

Aby lepiej to omówić, załóżmy, że:

  • host (eth0): 1.1.1.1
  • docker-bridge (br0): 172.25.0.0/16
    • serwer WWW (veth1): 172.25.0.2:443 (w razie potrzeby udostępniony na hoście jako 8443)
    • openvpn (veth2): 172.25.0.3:1194 (w razie potrzeby przekazane do hosta)
    • sslh w kontenerze (wzajemnie wykluczające się z hostem sslh): 172.25.0.4:443 (przekazane do hosta)
  • sslh na hoście (wzajemnie wykluczające się z kontem sslh): port 443
  • klient: 8.8.8.8

Oto mój wadliwy model powinien się zdarzyć, gdy przeglądarka łączy się z hostem: 443 i sslh jest na hoście w trybie przezroczystym

  • sslh łączy się z 172.25.0.2:8443 podając się za oryginalnego klienta 8.8.8.8
  • serwer odpowiada za handshake TCP na 8.8.8.8 przez veth1
  • pakiet trafia na br0
  • routing decyduje o wysłaniu go przez ent0
  • Łańcuch wyjściowy mangle iptables określa go jako ruch dla sslh (to nie działa dla mnie)
  • znak wskazuje zamiast tego skierowanie pakietu do lokalnego urządzenia lo
  • sslh podnosi, tłumaczy port i wysyła go z powrotem do klienta

Moim problemem na powyższej liście jest to, że nie znam kryteriów filtrowania ruchu wychodzącego na serwerach WWW: Czy powinienem używać wewnętrznego portu 443 dokera lub zmapowanego portu 8443? Doker IP 172.25.0.2 lub inny? To sprowadza się do: czy przez regułę wyjścia mangle zostanie uruchomiona przed NAT po dokerze?

Myślałem, że mogę umieścić sslh w sieci dokerów, aby uniknąć myślenia o NAT, ale wciąż nie mogę dopasować reguł iptables.

Nie rozumiem, jak postępować.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.