frank-w schrieb:
Masquerading habe ich auf dem ppp-interface aktiv (default homerouter-NAT wegen 1 öffentlicher IP und mehrerer privater).
Dann müsstest du natürlich noch die IP in der Regel auf die ppp-IP ändern, oder du definierst das eingehende Interface. Angenommen, du willst den Port auf dem Host komplett an den Container weiterleiten, und du hast das öffentliche Interface ppp0 und das private Interface eth0, dann könnte das ganze so aussehen:
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j DNAT --to-destination 10.0.3.10:80
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.0.3.10:80
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Das Masquerading auf eth0 brauchst du natürlich nur, wenn die Clients im dort anliegenden Netz keine Route für das LXC-Netz haben.
wusste gar nicht, dass man die nat-table auch ohne masquerading nutzen kann
Masquerading ist ja nur ein spezieller Fall von NAT.
und damit auf einer IP-Adresse nen Socket für eine Weiterleitung öffnen kann.
Das ist kein Socket sondern einfach eine Weiterleitung in der Firewall des Systems... Klingt vielleicht wie Haarspalterei, aber die Verwendung korrekter Termini ist wichtig zum Verständnis 😉
Danke, das funktioniert soweit ganz gut, man kommt nur um die IP scheinbar nicht drumherum, wenn ich das auf das interface mache, geht darüber kein http(s) mehr...weil alles an den eigenen Server weitergeleitet wird
Versteh ich nicht.
wollte halt ungern nen Proxy dazwischenschalten dafür...haben ja den Webdienst mit allem was dazu gehört (sql,php,...) extra in einen LXC-Container eingesperrt, damit die Pakete nicht im Hostsystem rumfliegen.
Das ist auch sinnvoll, so mache ich das auch. Dennoch habe ich im Hostsystem einen einfachen Apache, der SSL-Offloading macht und die Proxy-Vhosts die Verbindungen nach hinten rausreichen. Das hat den Vorteil, dass ich Dinge wie Letsencrypt auf dem Host regeln kann. Und dafür sind nur die paar Apache-Pakete nötig.