Pentru a rezuma contextul, este un container lxd care se conectează întotdeauna ca client OpenVpn.
{wan} <-> {192.168.x.x <-> iptables <-> lxd bridge host 10.0.3.1} <-> {lxd container 10.0.3.3 | openvpn <-> iptables}
În container există
- eth0 (ip 10.0.3.3) care este interfața client pe un bridge lxd
- tun0 care se conectează ca client la un server OpenVpn
Gazda lxd (10.0.3.1) redirecționează traficul 10.0.3.3 către rețeaua externă, iptables acceptă întotdeauna conexiuni de ieșire.
Gazda și clientul lxd au ambele iptables.
Am făcut deja rutarea pe 10.0.3.3, dar pentru portul de intrare (de exemplu, portul http de intrare la 10.0.3.3 și răspunsurile pe eth0, nu tun0).
Deci am un tabel de rutare "novpn" cu un număr fwmark.
Problema mea acum este că încerc să fac invers. Solicitările trimise către portul 21 de pe orice server la distanță trebuie să treacă prin tabelul eth0 ("novpn").
Am urmărit mai multe postări despre stackoverflow și am integrat acest lucru în iptable-urile clientului 10.0.3.3. Simt că este doar:
regulă ip adăugați tabelul fwmark 66 novpn
ip route add default prin 10.0.3.1 dev eth0 novpn table
iptables -t mangle -A PREROUTING -p tcp --dport 21 -j MARK --set-mark 66
iptables -t mangle -A OUTPUT -p tcp --dport 21 -j MARK --set-mark 66
Pe iptables din 10.0.3.1, am o regulă care acceptă redirecționări de la conexiuni deja stabilite și cunoscute. Deci bridge-ul ar trebui să urmeze și nu cred că sunt necesare alte reguli?
Dar nu merge, cand ma uit la tcpdump pe host (10.0.3.1) vad ca pachetele sunt trimise cu IP-ul openvpn, nu 10.0.3.3. De asemenea, pare să existe o problemă cu suma de control a pachetelor trimise -> cksum 0x1983 (incorect -> 0xe8ec).
Curios, când fac tcpdump pe consola clientului lxd (10.0.3.3), tcpdump nu afișează nimic și acolo nu mai înțeleg nimic.
Mă întreb dacă lxd are prioritate (poate ceva de genul dispozitivelor proxy etc.) față de iptables (și tcpdump??), dar asta mi se pare foarte ciudat.
Dacă poate fi util, am o regulă „regula ip adăuga la tabelul xxx.xxx.xxx.xxx novpn”. Deci orice conexiune la acest ip trece prin eth0 și, într-adevăr, acesta este cazul, acolo cererea este corectă în tcpdump.
Ma poate ajuta cineva.
