Am un caz de utilizare ciudat, în care un pod care rulează în Azure Kubernetes trebuie să direcționeze traficul de la anumite porturi către anumite ținte printr-un tunel VPN dedicat. Dar acele ținte sunt IP-uri private și, prin urmare, pot avea aceeași IP pentru ținte diferite. Podul pe lângă rutare este și serverul OpenVPN la care se conectează țintele. Un exemplu:
Comunicațiile care sosesc la portul 10 sunt direcționate către IP 10.0.0.4:80 prin VPN IP 10.118.0.2
si in acelasi timp putem avea:
Comunicațiile care sosesc la portul 20 sunt direcționate către IP 10.0.0.4:80 prin VPN IP 10.118.0.3
În ciuda faptului că IP-ul țintă este același, acestea sunt mașini diferite. Deci, pentru a realiza acest lucru, am venit cu această posibilă soluție:
/sbin/iptables --table mangle --insert PREROUTING --destination "192.168.0.100" -i eth0 -p tcp --dport "10" --jump MARK --set-mark "10"
/sbin/iptables --table nat --insert PREROUTING --destination "192.168.0.100" -i eth0 -p tcp --dport "10" --jump DNAT --to-destination "10.0.0.4:80"
Regula /sbin/ip adaugă înainte „10” din toate căutările fwmark „10” „10”
ruta /sbin/ip adăugați „10.0.0.4” prin tabelul 10 „10.118.0.2”
Acest lucru ar permite ca ambele comunicații să funcționeze în același timp, traficul fiind direcționat către mașina corectă. Dar ceea ce văd este că pachetele sunt marcate, în tabelul Mangle. Dar apoi nu ajunge niciodată la mesele NAT. Am aflat că are legătură cu rt_filter. Mai multe despre asta mai jos. Așa cum este acum și funcționează, este așa:
/sbin/iptables --table nat --insert PREROUTING --destination "192.168.0.100" -i eth0 -p tcp --dport "10" --jump DNAT --to-destination "10.0.0.4:80"
ruta /sbin/ip adăugați „10.0.0.4” prin „10.118.0.2”
Cu toate acestea, dacă se stabilește o a doua rută, ca în primul exemplu, comanda ar arăta astfel:
/sbin/iptables --table nat --insert PREROUTING --destination "192.168.0.100" -i eth0 -p tcp --dport "20" --jump DNAT --to-destination "10.0.0.4:80"
ruta /sbin/ip adăugați „10.0.0.4” prin „10.118.0.3”
Aceasta ar crea o altă rută în tabelul principal de rute pentru aceeași țintă. Dar atunci, atunci când accesează 192.168.0.100, utilizatorul ar putea fi direcționat fie către mașina conectată la 10.118.0.3, fie la 10.118.0.2.
Pe lângă aceste reguli, pentru toate acestea, aceasta a fost întotdeauna activată pentru a permite traficului să revină la interfața tap0, unde se duce comunicarea la 10.118.0.X:
iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE
Din păcate, nu pot cunoaște IP-ul sursei utilizatorului, altfel ar fi simplu de rezolvat. IP-ul sursă pentru orice comunicare care ajunge la acest port va fi întotdeauna același, deoarece comunicarea trebuie să treacă printr-un alt serviciu care maschează IP-ul sursă reală.
Am văzut în alte subiecte că pentru a marca pachetele primite într-un container/pod trebuie să dezactivez rt_filter. Cu toate acestea, nu pot face asta, spune că este un sistem de fișiere numai pentru citire și nu știu dacă este chiar posibil să îl schimb în Azure Kubernetes Clusters.
Există altă soluție decât marcarea pachetelor? Sau mai lipsește ceva referitor la marcarea pachetului?
