Puncte:1

Asigurați-vă că traficul Docker pentru nodul din Swarm trece exclusiv printr-o conexiune VPN

drapel in

Am două noduri într-un cluster Docker Swarm. Unul dintre aceste noduri are o conexiune client OpenVPN la un furnizor VPN pe interfață tun0. Scopurile mele sunt,

  • Orice servicii atribuite acestui nod utilizează exclusiv conexiunea VPN
  • Fără scurgeri (adică, DNS sau alt trafic)
  • Dacă VPN-ul se deconectează, tot traficul este eliminat
  • Permite descoperirea serviciului și conexiunile la alte containere din Swarm

Pentru DNS, am adăugat un dns intrarea la /etc/docker/daemon.json care utilizează serverele DNS ale furnizorului VPN care sunt accesibile numai prin VPN.

Iată regulile iptable cu care am venit:

iptables -I DOCKER-USER 1 -o tun0 -j ACCEPT
iptables -I DOCKER-USER 2 -i tun0 -m conntrack --ctstate RELATED,STABLISHED -j ACCEPT
iptables -I DOCKER-USER 3 -j DROP

Rezultați DOCKER-UTILIZATOR lanțul arată așa:

Lanț DOCKER-USER (1 referințe)
 pkts bytes target prot opt ​​in out source destination
    0 0 ACCEPT toate -- * tun0 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT toate -- tun0 * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,STABLISHED
    0 0 DROP toate -- * * 0.0.0.0/0 0.0.0.0/0

De la teste de bază, cum ar fi alergarea nslookup și răsuci cu conexiunea VPN activată și oprită, aceste reguli par să funcționeze, dar am foarte puțină experiență cu iptables. Este acesta modul corect de a face asta?

Puncte:1
drapel fr

IPtables este liniar și citește regulile de sus în jos până când ajunge la o țintă ACCEPT, REJECT sau DROP, apoi încetează să citească regulile. În cazul tău, vrei să ai iptables -I DOCKER-USER -j DROP ca și ultima regulă din lanțul dvs., altfel fiecare pachet va fi aruncat. De asemenea, nu este nevoie de regula RETURN la sfârșit, deoarece IPtables nu va mai citi regulile odată ce ajunge la regula DROP chiar deasupra acesteia. Acele reguli IPtables cu tun0 arată bine, dar asigură-te că ai și aceste reguli:

iptables -t filtru -I INTRARE 1 -i tun0 -j DOCKER-USER
iptables -t filter -I OUTPUT 2 -o tun0 -j DOCKER-USER

Pentru o bună practică, asigurați-vă că acceptați tot traficul loopback, care nu va ajunge niciodată pe internet și nici nu va părăsi mașina:

iptables -t filtru -I INTRARE 3 -i tun0 -j ACCEPT

Să analizăm cerințele dvs. unul câte unul:

  1. Orice servicii atribuite acestui nod utilizează exclusiv conexiunea VPN

Nu ați folosi IPtables pentru a face acest lucru. Rulați aceste comenzi pe servere:

IP route add default prin ${LOCAL_VPN_IP} 

Cred că OpenVPN utilizează de obicei 10.8.0.0/16, așa că gateway-ul implicit ar fi probabil 10.8.0.1 sau ceva de genul acesta. IProute2 (comanda ip) este încorporată în nucleu, la fel ca IPtables.

  1. Fără scurgeri (adică, DNS sau alt trafic)

Mai întâi ar trebui să redirecționați tot traficul prin VPN, punând acest lucru în configurația serverului dvs. OpenVPN:

push "redirect-gateway autolocal"

Acest lucru îi face pe clienți să-și transfere tot traficul prin VPN, chiar și DNS și altele. Dacă serverul OpenVPN se defectează, internetul nu va mai funcționa pe clienți.

  1. Dacă VPN-ul se deconectează, tot traficul este eliminat

Vezi pasul 2

  1. Permite descoperirea serviciului și conexiunile la alte containere din Swarm

Cred că OpenVPN face acest lucru în mod implicit. Pot să fac ping/arp de la un client la alți clienți care se află pe serverul OpenVPN.Cu siguranță ar trebui să puteți accesa serviciile care sunt pe alți clienți.

Sper că asta vă răspunde la întrebări!

drapel in
Mulțumesc! Mi-am editat întrebarea pentru a fi mai clar. Iată câteva întrebări ulterioare... 1. Regulile `INPUT 1` și `OUTPUT 2` direcționează traficul prin sublanțul DOCKER-USER. Sunt cele necesare deoarece Docker gestionează automat regulile din lanțul FORWARD? 2. Pentru regulile mele originale, ar trebui să folosesc RETURN pentru a-i permite să treacă prin celelalte sublanțuri FORWARD sau ACCEPT? 3. Comanda `ip route` este redundantă? Nu tot traficul va fi forțat pe interfața `tun0`, indiferent de regulile iptables?
drapel fr
1. Da, puteți adăuga și `iptables -t filter -A FORWARD -j DOCKER-USER`. `INPUT` este pentru traficul destinat serverului, `OUTPUT` este pentru traficul care provine de la server, iar `FORWARD` este pentru traficul care nu provine și nici nu se termină la server. Cu alte cuvinte, „FORWARD” este ceea ce face routerul atunci când computerul se conectează la google.com. 2. `RETURNARE` nu este util decât dacă sunteți într-un sublanț și doriți să reveniți la lanț mai sus. 3. `ip route` nu este redundant. `iptables` permite sau nu permite pachete, dar nu spune serverului dvs. unde să trimită pachete. `ruta ip` face.
drapel in
1. Deci spui că pot folosi `iptables -t filter -A FORWARD -j DOCKER-USER` în loc să adaug regulile `INPUT` și `OUTPUT` pe care le-ai menționat? 2. `DOCKER-USER` este sub-lanțul gestionat de Docker de `FOWARD`, deci atunci `RETURN` ar trebui să fie folosit pentru a reveni la lanțul `FOWARD`? 3. Are sens, va trebui să mă uit mai mult la acest lucru, deoarece ruta mea implicită actuală trece prin IP-ul meu local.
drapel fr
1.`INPUT`, `OUTPUT` și `FOWARD` au toate funcții diferite, așa că trebuie să le includeți pe toate 3 dacă doriți ca întregul trafic să fie gestionat de VPN. 2. Dacă `INPUT`, `OUTPUT` și `FORWARD` sunt toate trimise către `DOCKER-USER`, lanțul `DOCKER-USER` gestionează tot traficul pentru toate cele 3 lanțuri, ceea ce înseamnă că nu trebuie să `RETURNEȚI ` orice pentru lanțul `FOWARD`, deoarece lanțul `FOWARD` va fi tratat de regulile din `DOCKER-USER`.
drapel in
Sub-înlănțuind `DOCKER-USER` în `INPUT` și `OUTPUT`, nu s-ar aplica aceste reguli întregului trafic, inclusiv pentru gazdă? Se pare că ar arunca totul în interfața mea fizică `eth0`, inclusiv conexiunea la VPN-ul în sine, deoarece nu s-ar potrivi regulilor ACCEPT.
drapel in
Iată documentele pentru Docker iptables ca referință. https://docs.docker.com/network/iptables/ Linia de interes este „Docker instalează două lanțuri iptables personalizate numite DOCKER-USER și DOCKER și se asigură că pachetele primite sunt întotdeauna verificate de aceste două lanțuri mai întâi”.
drapel fr
Scuze pentru răspunsul târziu, am fost ocupat. Deci, nu știam că Docker a creat acele lanțuri. Acestea fiind spuse, ai dreptate. `DOCKER-USER` pare să verifice doar „pachetele primite” din înțelegerea mea. Deci, dacă doriți ca pachetele de ieșire să treacă doar prin VPN, ați face ceva de genul `iptables -t filter -A OUTPUT -o tun0 -j ACCEPT` urmat de `iptables -t filtler -A OUTPUT! -o tun0 -j DROP` sau puteți avea, de asemenea, doar `iptables -t filter -A OUTPUT -j DROP` după regula ACCEPT.
drapel in
Mulțumesc pentru urmărire! Toate lanțurile au sens acum, le voi implementa. În ceea ce privește ruta IP, se pare că OpenVPN face asta automat în timpul pornirii cu aceste „rute adăugați 0.0.0.0/1 prin REMOVED” și „128.0.0.0/1 prin REMOVED”. Din păcate, nu am putut să confirm dacă serverul OpenVPN are setat „redirect-gateway autolocal”. Știți vreo modalitate de a confirma acest lucru?
drapel fr
Veți pune `push "redirect-gateway autolocal"` în fișierul dvs. de configurare a serverului OpenVPN. În acest fel, s-ar împinge acea setare către clienți pentru a redirecționa tot traficul lor. Dar se pare că OpenVPN trebuie să aibă o setare ca aceasta activată în mod implicit. Acele comenzi de rută ar trebui să redirecționeze tot traficul prin VPN.

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.