La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: ochbob le 05 février 2021 à 13:24:50
-
Bonjour à tous,
je bloque sur un problème réseau suite à l'installation de Docker et de Filestash (https://github.com/mickael-kerjean/filestash) comme conteneur.
Configuration:
Serveur Debian avec:
- eth0 = 192.168.1.100
- br0 bridge avec eth1 = 192.168.1.101
- vnet0 = interface de la VM KVM
Docker a rajouter 3 interfaces (les 2 propres à Docker (docker0 + br-4edbd5a6a8d3) + celle que le conteneur lance veth8154c09)
- docker0 = 172.17.0.1
- br-4edbd5a6a8d3 = 172.18.0.1
- veth8154c09
- Adresse du conteneur docker = 172.18.0.2
PC sur le réseau local = 192.168.1.50
J'utilise KVM qui utilise br0 comme source avec une VM qui utilise donc vnet0, suite à l'installation de Docker, impossible de joindre cette VM, j'ai corrigé le pb avec l'ajout d'une règle iptables:
iptables -A FORWARD -i br0 -o br0 -j ACCEPT
Jusque la, RAS, tout fonctionne bien comme voulu et comme avant que j'installe Docker.
Mnt, le vif du sujet, le conteneur Docker écoute sur:
0.0.0.0:8334->8334/tcp
Un netstat me donne:
tcp6 0 0 [::]:8334 [::]:* LISTEN
Depuis mon PC sur le réseau local, j'arrive bien à le joindre sur http://192.168.1.100:8334/, Filestash fonctionne très bien.
Par contre depuis l'host en lui même, impossible de joindre ce conteneur...
Un curl -vv http://192.168.1.100:8334/ me retourne:
* Expire in 0 ms for 6 (transfer 0x56202813cf90)
* Trying 192.168.1.100...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x56202813cf90)
^C
Un curl -vv http://0.0.0.0:8334/ me retournne:
* Expire in 0 ms for 6 (transfer 0x55b9a8716f90)
* Trying 0.0.0.0...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b9a8716f90)
* Connected to 0.0.0.0 (127.0.0.1) port 8334 (#0)
> GET / HTTP/1.1
> Host: 0.0.0.0:8334
> User-Agent: curl/7.64.0
> Accept: */*
>
^C
Coté iptables voila ce que j'ai en rapport avec Docker (ce n'est pas moi qui ai rajouté les règles,):
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2
-N DOCKER-USER
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o br-4edbd5a6a8d3 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-4edbd5a6a8d3 -j DOCKER
-A FORWARD -i br-4edbd5a6a8d3 ! -o br-4edbd5a6a8d3 -j ACCEPT
-A FORWARD -i br-4edbd5a6a8d3 -o br-4edbd5a6a8d3 -j ACCEPT
-A DOCKER -d 172.18.0.2/32 ! -i br-4edbd5a6a8d3 -o br-4edbd5a6a8d3 -p tcp -m tcp --dport 8334 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i br-4edbd5a6a8d3 ! -o br-4edbd5a6a8d3 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o br-4edbd5a6a8d3 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
Avez vous une idée de ce qui cloche ?
Merci à ceux qui prendront le temps de m'aider ;D
-
comment le container est-il crée?
que donne
docker network ls
et
docker inspect nomducontainer
cette derniere commande donne notamment tous les détails réseau du container.
dedans y'a le réseau utilisé par le conteneur,
ensuite:
docker network inspect nomdureseau
ps: on peut aussi utiliser
docker inspect nomducontainer -f "{{json .NetworkSettings}}"pour voir que la partie réseau du container
-
ps2:
avant de regarder si ca cloche coté docker ou host, il faudrait voir si ce n'est pas l'application dans le container qui filtre/bloque ou :
lancement d'un serveur http simple pour tester:
docker run -d --rm --name echo-test -p 5678:5678 hashicorp/http-echo -text="hello world"
test:
curl localhost:5678et
curl ip_lan_local:5678
arrêt & destruction du container de test:
docker stop echo-test
ps3:
la rule 'FORWARD' ajouté ne concerne pas le trafic de/vers l'hôte donc ca peut être cela aussi (forward = ce qui traverse l'hôte).
si tu veux container->host il faut regarder 'INPUT ' sur l'hote. (sudo iptables -S INPUT).
si la policy sur INPUT n'est pas a ACCEPT, il faut ouvrir le trafic entre docker0 et l'hote:
sudo iptables -A INPUT -i docker0 -j ACCEPT
ton "curl" est un process local:
(https://www.booleanworld.com/wp-content/webp-express/webp-images/doc-root/wp-content/uploads/2017/06/Untitled-Diagram.png.webp)
-
Merci beaucoup Kgersen pour ce retour. Je vais regarder tout ça et je reviens poster le résultat.
-
Concernant la partie Docker, une fois que le conteneur est lancé
Je lance le conteneur avec
docker-compose up -d
cat docker-compose.yml
version: '2'
services:
app:
container_name: filestash
image: machines/filestash
restart: always
environment:
- APPLICATION_URL=
- GDRIVE_CLIENT_ID=<gdrive_client>
- GDRIVE_CLIENT_SECRET=<gdrive_secret>
- DROPBOX_CLIENT_ID=<dropbox_key>
- ONLYOFFICE_URL=http://onlyoffice
ports:
- "8334:8334"
Cote réseau
docker network ls
NETWORK ID NAME DRIVER SCOPE
eefd00b8bce9 bridge bridge local
2071b13f2ca7 filestash_default bridge local
7f1840b4dece host host local
6ea24888546b none null local
docker inspect filestash
[
{
"Id": "d15341db80fed43ed02d70685f93b5bcc847dd9e39871256c0a8520468a01855",
"Created": "2021-02-06T17:16:28.659261351Z",
"Path": "/app/filestash",
"Args": [],
"State": {
"Status": "running",
"Running": true,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 16394,
"ExitCode": 0,
"Error": "",
"StartedAt": "2021-02-06T17:16:29.418758227Z",
"FinishedAt": "0001-01-01T00:00:00Z"
},
"Image": "sha256:60e86c9fc57a77e1307439464fd194a89371f81014455e131a485ea9e976ce79",
"ResolvConfPath": "/var/lib/docker/containers/d15341db80fed43ed02d70685f93b5bcc847dd9e39871256c0a8520468a01855/resolv.conf",
"HostnamePath": "/var/lib/docker/containers/d15341db80fed43ed02d70685f93b5bcc847dd9e39871256c0a8520468a01855/hostname",
"HostsPath": "/var/lib/docker/containers/d15341db80fed43ed02d70685f93b5bcc847dd9e39871256c0a8520468a01855/hosts",
"LogPath": "/var/lib/docker/containers/d15341db80fed43ed02d70685f93b5bcc847dd9e39871256c0a8520468a01855/d15341db80fed43ed02d70685f93b5bcc847dd9e39871256c0a8520468a01855-json.log",
"Name": "/filestash",
"RestartCount": 0,
"Driver": "overlay2",
"Platform": "linux",
"MountLabel": "",
"ProcessLabel": "",
"AppArmorProfile": "docker-default",
"ExecIDs": null,
"HostConfig": {
"Binds": [],
"ContainerIDFile": "",
"LogConfig": {
"Type": "json-file",
"Config": {}
},
"NetworkMode": "filestash_default",
"PortBindings": {
"8334/tcp": [
{
"HostIp": "",
"HostPort": "8334"
}
]
},
"RestartPolicy": {
"Name": "always",
"MaximumRetryCount": 0
},
"AutoRemove": false,
"VolumeDriver": "",
"VolumesFrom": [],
"CapAdd": null,
"CapDrop": null,
"Dns": null,
"DnsOptions": null,
"DnsSearch": null,
"ExtraHosts": null,
"GroupAdd": null,
"IpcMode": "shareable",
"Cgroup": "",
"Links": null,
"OomScoreAdj": 0,
"PidMode": "",
"Privileged": false,
"PublishAllPorts": false,
"ReadonlyRootfs": false,
"SecurityOpt": null,
"UTSMode": "",
"UsernsMode": "",
"ShmSize": 67108864,
"Runtime": "runc",
"ConsoleSize": [
0,
0
],
"Isolation": "",
"CpuShares": 0,
"Memory": 0,
"NanoCpus": 0,
"CgroupParent": "",
"BlkioWeight": 0,
"BlkioWeightDevice": null,
"BlkioDeviceReadBps": null,
"BlkioDeviceWriteBps": null,
"BlkioDeviceReadIOps": null,
"BlkioDeviceWriteIOps": null,
"CpuPeriod": 0,
"CpuQuota": 0,
"CpuRealtimePeriod": 0,
"CpuRealtimeRuntime": 0,
"CpusetCpus": "",
"CpusetMems": "",
"Devices": null,
"DeviceCgroupRules": null,
"DiskQuota": 0,
"KernelMemory": 0,
"MemoryReservation": 0,
"MemorySwap": 0,
"MemorySwappiness": null,
"OomKillDisable": false,
"PidsLimit": 0,
"Ulimits": null,
"CpuCount": 0,
"CpuPercent": 0,
"IOMaximumIOps": 0,
"IOMaximumBandwidth": 0,
"MaskedPaths": [
"/proc/asound",
"/proc/acpi",
"/proc/kcore",
"/proc/keys",
"/proc/latency_stats",
"/proc/timer_list",
"/proc/timer_stats",
"/proc/sched_debug",
"/proc/scsi",
"/sys/firmware"
],
"ReadonlyPaths": [
"/proc/bus",
"/proc/fs",
"/proc/irq",
"/proc/sys",
"/proc/sysrq-trigger"
]
},
"GraphDriver": {
"Data": {
"LowerDir": "/var/lib/docker/overlay2/ac6df8c7ad386f97285b75af1864ff413f6446cef69193cba83ba4065b73bc3b-init/diff:/var/lib/docker/overlay2/b112c003e1b9f556756692d39d3768aa88c63cd9871cc45fa172fdab3d61013a/diff:/var/lib/docker/overlay2/5e8e796e2138d6b48bbd3f2d07f20c8e822fbec18f6147a1e76144228be4d682/diff:/var/lib/docker/overlay2/ff32f4dce195a06a392ba6ecb89711f6d05f6044ae374dc6737d6d807e428d22/diff",
"MergedDir": "/var/lib/docker/overlay2/ac6df8c7ad386f97285b75af1864ff413f6446cef69193cba83ba4065b73bc3b/merged",
"UpperDir": "/var/lib/docker/overlay2/ac6df8c7ad386f97285b75af1864ff413f6446cef69193cba83ba4065b73bc3b/diff",
"WorkDir": "/var/lib/docker/overlay2/ac6df8c7ad386f97285b75af1864ff413f6446cef69193cba83ba4065b73bc3b/work"
},
"Name": "overlay2"
},
"Mounts": [
{
"Type": "volume",
"Name": "6111177f69aa2044f9f978bdc35bfbb3e5ab3f01a5b320b943c5b38e1be6cf20",
"Source": "/var/lib/docker/volumes/6111177f69aa2044f9f978bdc35bfbb3e5ab3f01a5b320b943c5b38e1be6cf20/_data",
"Destination": "/app/data/state",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
}
],
"Config": {
"Hostname": "d15341db80fe",
"Domainname": "",
"User": "filestash",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"ExposedPorts": {
"8334/tcp": {}
},
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"APPLICATION_URL=",
"GDRIVE_CLIENT_ID=<gdrive_client>",
"GDRIVE_CLIENT_SECRET=<gdrive_secret>",
"DROPBOX_CLIENT_ID=<dropbox_key>",
"ONLYOFFICE_URL=http://onlyoffice",
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"PUBLIC_KEY=-----BEGIN PGP PUBLIC KEY BLOCK-----
END PGP PUBLIC KEY BLOCK-----\\n",
"DEBIAN_FRONTEND=noninteractive"
],
"Cmd": [
"/app/filestash"
],
"Image": "machines/filestash",
"Volumes": {
"/app/data/state/": {}
},
"WorkingDir": "/app",
"Entrypoint": null,
"OnBuild": null,
"Labels": {
"com.docker.compose.config-hash": "8cff4d179fd504521e8ee9550e7b7d337c7af6ec6719b69640311a1f2225c8c1",
"com.docker.compose.container-number": "1",
"com.docker.compose.oneoff": "False",
"com.docker.compose.project": "filestash",
"com.docker.compose.service": "app",
"com.docker.compose.version": "1.21.0",
"org.label-schema.build-date": "2020-11-24T11:58:45Z",
"org.label-schema.schema-version": "1.0",
"org.label-schema.vcs-ref": "e02267d3d57c7e60a1c6e4543a6b594a03b20cdb",
"org.label-schema.vcs-url": "https://github.com/mickael-kerjean/filestash.git"
}
},
"NetworkSettings": {
"Bridge": "",
"SandboxID": "ac89d8718ffb4a5f1c95e45ee00d61d73a5ffdb7f601c3482fdb5f9a97655195",
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"Ports": {
"8334/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "8334"
}
]
},
"SandboxKey": "/var/run/docker/netns/ac89d8718ffb",
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"EndpointID": "",
"Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "",
"IPPrefixLen": 0,
"IPv6Gateway": "",
"MacAddress": "",
"Networks": {
"filestash_default": {
"IPAMConfig": null,
"Links": null,
"Aliases": [
"d15341db80fe",
"app"
],
"NetworkID": "2071b13f2ca7b5fe7fb411ed48be3ebe3b8ddb9159541cd57493bda61131b563",
"EndpointID": "5d7e86ac754bcca73bb9f2e16e582cabfe5c694ddc4343735f0b37a999b36e55",
"Gateway": "172.18.0.1",
"IPAddress": "172.18.0.2",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "02:42:ac:12:00:02",
"DriverOpts": null
}
}
}
}
]
docker network inspect filestash_default
[
{
"Name": "filestash_default",
"Id": "2071b13f2ca7b5fe7fb411ed48be3ebe3b8ddb9159541cd57493bda61131b563",
"Created": "2021-02-06T18:16:27.90252391+01:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.18.0.0/16",
"Gateway": "172.18.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"d15341db80fed43ed02d70685f93b5bcc847dd9e39871256c0a8520468a01855": {
"Name": "filestash",
"EndpointID": "5d7e86ac754bcca73bb9f2e16e582cabfe5c694ddc4343735f0b37a999b36e55",
"MacAddress": "02:42:ac:12:00:02",
"IPv4Address": "172.18.0.2/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {}
}
]
Et concernant le test avec le conteneur http-echo j'ai le même phénomème
Donc j' imagine bien avoir un soucis avec Iptables :(
-
oui surement.
que donne "sudo iptables -S INPUT" ?
-
iptables -S INPUT
-P INPUT ACCEPT
-A INPUT -p tcp -m multiport --dports 25,465,587,143,993,110,995 -j f2b-postfix-sasl
-A INPUT -p tcp -m multiport --dports 22,115 -j f2b-ssh
-A INPUT -p udp -m udp --dport 1701 -m policy --dir in --pol none -j DROP
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m multiport --dports 500,4500 -j ACCEPT
-A INPUT -p udp -m udp --dport 1701 -m policy --dir in --pol ipsec -j ACCEPT
-A INPUT -p udp -m udp --dport 1701 -j DROP
-A INPUT -i tun0 -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A INPUT -i tun0 -j REJECT --reject-with icmp-port-unreachable
J'ai un tunnel VPN qui tourne sur tun0 et quelques règles lie également a un serveur vpn qui tourne + un fail2ban
-
hum curieux la policy est ACCEPT donc ca ne devrait bloquer pas a ce niveau.
le curl entre l'host et le container a besoin de passer dans le 2 sens. reste a trouver ou ca coince
toutes les règles ca donne quoi ?
sudo iptables -S
-
Ce sont mes règles montées par défaut au démarrage de la machine
Fail2ban et Docker (voir au dessus) rajoutent également ses règles en plus.
Te faire un un -S entier serait bien trop gros (toutes les IP bannis par fail2ban y sont, et la liste est très longues ;D
*filter
:OUTPUT ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
-A INPUT -p udp -m udp -m policy --dport 1701 -j DROP --dir in --pol none
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m multiport -j ACCEPT --dports 500,4500
-A INPUT -p udp -m udp -m policy --dport 1701 -j ACCEPT --dir in --pol ipsec
-A INPUT -p udp -m udp --dport 1701 -j DROP
-A INPUT -m conntrack -i tun0 --ctstate ESTABLISHED -j ACCEPT
-A INPUT -i tun0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -m conntrack -i eth0 -o ppp+ --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ppp+ -o eth0 -j ACCEPT
-A FORWARD -s 192.168.42.0/24 -d 192.168.42.0/24 -i ppp+ -o ppp+ -j ACCEPT
-A FORWARD -m conntrack -d 192.168.43.0/24 -i eth0 --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.43.0/24 -o eth0 -j ACCEPT
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -j DROP
-A OUTPUT -m owner -o lo --uid-owner 1014 -j ACCEPT
-A OUTPUT -m owner -o tun0 --uid-owner 1014 -j ACCEPT
*nat
:PREROUTING ACCEPT [26107:5498315]
:INPUT ACCEPT [26104:5498123]
:OUTPUT ACCEPT [580209:35078053]
:POSTROUTING ACCEPT [579551:35024916]
-A POSTROUTING -s 192.168.42.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.43.0/24 -o eth0 -m policy --dir out --pol none -j MASQUERADE
-A POSTROUTING -o tun0 -j MASQUERADE
*mangle
:PREROUTING ACCEPT [8229231:3408318247]
:INPUT ACCEPT [8229187:3408297350]
:FORWARD ACCEPT [44:20897]
:OUTPUT ACCEPT [8757918:12312010103]
:POSTROUTING ACCEPT [8795066:12314426716]
-A OUTPUT -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A OUTPUT ! -d 192.168.1.100/32 -m owner --uid-owner 1014 -j MARK --set-xmark 0x1/0xffffffff
-A OUTPUT -d 192.168.1.100/32 -p udp -m udp --dport 53 -m owner --uid-owner 1014 -j MARK --set-xmark 0x1/0xffffffff
-A OUTPUT -d 192.168.1.100/32 -p tcp -m tcp --dport 53 -m owner --uid-owner 1014 -j MARK --set-xmark 0x1/0xffffffff
-A OUTPUT ! -s 192.168.1.100/32 -j MARK --set-xmark 0x1/0xffffffff
-A OUTPUT -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff
-
hum je seche la.
en utilisant l'ip local du container ca bloque aussi ?
docker inspect -f '{{ .NetworkSettings.IPAddress }}' nomducontainer
puis "curl cetteipaddress:portapplication"
sinon il faudrait tester avec nc (netcat) pour voir dans quel sens ca bloque.
-
Oui ça bloque aussi avec l'IP Local du conteneur.
C'est clairement un soucis avec iptables et le conteneur docker (en mode bridge )...
J'ai contourné le problème, je lance docker avec l'argument iptables": false, comme ça il ne me fait plus n'importe quoi avec iptables et lancement de mon conteneur en mode "host" (network_mode: host) et non "bridge" => plus de soucis.
If you use the host network mode for a container, that container’s network stack is not isolated from the Docker host (the container shares the host’s networking namespace), and the container does not get its own IP-address allocated. For instance, if you run a container which binds to port 80 and you use host networking, the container’s application is available on port 80 on the host’s IP address.
J'essaierais de creuser la question avec le mode bridge + iptables.
-
Au pire essai avec podman, c'est une solution alternative a Docker , et compatible avec.
-
Je pense que je vais migrer en effet, surtout que je compte pas utiliser docker énormément.
Son aspect rootless + daemonless pour 2/3 conteneurs par ci par là, ça sera parfait je pense.
Mais va falloir attendre la sortie de Bullseye ;D (pas dispo sur les backports Buster)
-
Ca reste quand même très curieux que ca ne fonctionne pas avec Docker. C'est quand meme tres utilisé et ce probleme n'est pas remonté.
Peut-etre fail2ban. y'a quoi dans jail.local ?
-
Disons que suite au passage de Docker sans iptables et le conteneur en mode host j'ai plus de soucis :D
(J'ai pas testé juste avec le conteneur en mode host et en laissant docker géré iptables, de toute façon je n'aime pas ne pas savoir ce que fait une appli... surtout quand elle touche à iptables... donc c'est pas plus mal comme ça ;D)
Mais ça semble voulu comme indiqué sur la page d'avant:
If you use the host network mode for a container, that container’s network stack is not isolated from the Docker host
Donc sur un mode réseau autre que host pour le conteneur, le conteneur est bien isolé de l'hôte => raison pour laquelle je n'arrivais pas à joindre le conteneur depuis localhost (de l'hôte) et j'arrivais à joindre le conteneur depuis l'extérieur de l'hôte.
En tout cas je le comprends comme ça...
Concernant mon jail.local rien de particulier, quelques jails activé sur ssh/dovecot/proftpd/postfix/etc...
Je n'ai jamais eu de soucis, c'est juste une première avec docker en mode bridge..
-
If you use the host network mode for a container, that container’s network stack is not isolated from the Docker host
Donc sur un mode réseau autre que host pour le conteneur, le conteneur est bien isolé de l'hôte => raison pour laquelle je n'arrivais pas à joindre le conteneur depuis localhost (de l'hôte) et j'arrivais à joindre le conteneur depuis l'extérieur de l'hôte.
En tout cas je le comprends comme ça...
c'est le mode host network qui est moins secure en fait. On l'utilise que très rarement. Ce n'est pas le mode par défaut et il est rarement recommandé...ca va un peu a l'encontre du pourquoi Docker existe...
> raison pour laquelle je n'arrivais pas à joindre le conteneur depuis localhost
Non pas du tout. L'isolation des stacks réseaux n'empêche pas le trafic de passer: il faut juste explicitement préciser quel port entre vers le conteneur et s'il faut le changer (c'est le role de l'option -p X:Y ou la section 'ports' du compose file).
Le trafic est routé et NATé via l'interface Docker0, l'hote se comporte comme un routeur vis a vis a du conteneur. rien de plus.
En mode 'net=host', l'option -p est ignoré, tous ports que le containeur ouvre sont ouverts totalement sur l'hote et peut être en conflit avec un port utilisé par un service de l'hôte lui-même. Ca n'est vraiment pas recommandé.
(https://drive.google.com/uc?id=1pU-RzhxunE_eO6D_gOu9AyAbJnkyQKFB)
-
Pour mon usage et pour garder une certaine cohérence avec tous le reste qui tourne déjà sur mon serveur, c'est la solution la plus simple finalement.
Franchement tout le stack réseaux de docker (avec les isolation entre conteneur de bases, etc...) je m'en contre fiche, mon but avec docker c'est juste faire tourner l'unique service par conteneur indivudellement, rien de plus (et pas un soucis qu'un conteneur voit un autre)
Si je pouvais me passer de docker je l'aurais fait pour le coup ;D
Dans mon cas mes conteneurs écoute bien sur un unique port que je n'utilise pas déjà (vérifier avec docker inspect), donc pas de conflit possible mais effectivement le risque d'un conflit est possible.
Par contre si effectivement l'isolation des stacks réseaux n'empêche pas le trafic de passer: pourquoi une fois une fois l'option host rajoutée, tout fonctionne bien ?
Il y avait bien une isolation qqpart, à quel niveau, ça, je ne sais pas malheureusement. :-\
-
Mais pour quelle raison utiliser Docker alors ? j'ai du mal à comprendre pourquoi utiliser ça, si ça ne fonctionne pas comme on veut.
Moi par exemple, je n'y connaît rien, n'y voit aucun intérêt donc je reste sur de la virtualisation qui fait tout ce dont j'ai besoin.
-
Par contre si effectivement l'isolation des stacks réseaux n'empêche pas le trafic de passer: pourquoi une fois une fois l'option host rajoutée, tout fonctionne bien ?
Il y avait bien une isolation qqpart, à quel niveau, ça, je ne sais pas malheureusement. :-\
Disons que sur un hôte nouvellement installé et propre, Docker marche normalement. Comme sur 99,9% des installations.
C'est ta hôte qui a un truc particulier qui fait que ca ne marche qu'en mode host. On ne sait pas pourquoi du coup. Sans doute un souci du coté d'iptables ou autre chose qui perturbe. L'important c'est que c'est ton cas qui est spécial et pas représentatif de la généralité.
Mais pour quelle raison utiliser Docker alors ? j'ai du mal à comprendre pourquoi utiliser ça, si ça ne fonctionne pas comme on veut.
Moi par exemple, je n'y connaît rien, n'y voit aucun intérêt donc je reste sur de la virtualisation qui fait tout ce dont j'ai besoin.
c'est plus léger qu'une VM , plus rapide a démarrer, plus simple a configurer.
Tout le principe de Docker c'est de partager le même noyau (kernel) et on partitionne (isole) tout le reste au dessus.
On n'a pas d'autre OS a gérer que celui de l'hôte. Et on utilise le même environnement que le développeur de l'application du coup on a moins de souci de compatibilité/versions (on peut par exemple faire tourner une application sur Debian dans un conteneur hébergé sur Ubuntu sans devoir installer, configurer et maintenir une VM Debian complète).
(https://i2.wp.com/www.docker.com/blog/wp-content/uploads/Blog.-Are-containers-..VM-Image-1.png)
-
Je connais très bien la théorie sur Docker ;) Dans la pratique, les avantages sont plus discutables.
-
Je connais très bien la théorie sur Docker ;) Dans la pratique, les avantages sont plus discutables.
Mais pour quelle raison utiliser Docker alors ? j'ai du mal à comprendre pourquoi utiliser ça, si ça ne fonctionne pas comme on veut.
Moi par exemple, je n'y connaît rien, n'y voit aucun intérêt donc je reste sur de la virtualisation qui fait tout ce dont j'ai besoin.
?! ;D
-
Je ne connais pas la partie pratique ni le fonctionnement interne ;) par rapport aux problèmes rencontrés dans le topic.
la théorie ça va
Quand je vois les problèmes rencontrés et la quasi impossibilité à débugguer, ça fait peur...
-
Quand je vois les problèmes rencontrés et la quasi impossibilité à débugguer, ça fait peur...
ce qui ne marche pas n'est pas a cause de Docker mais de son OS/réseau.
Comme indiqué son cas est exceptionnel , du jamais vu pour moi en tout cas.
Tu peux avoir les mêmes souci avec une VM de toute façon si au niveau de l'hôte iptables et/ou la config réseau ne sont pas clean...
Au niveau debug c'est pareil qu'avec une VM voir même souvent plus simple avec Docker car il n'y a pas 2 stack réseau distinctes (avec une VM et une config tordue tu peux avoir a toucher a iptables dans l'hote et a iptables dans la vm et ca peut vite être la zone).
Bref c'est vraiment pas le cas ou il faut juger Docker sur cet exemple. D'ailleurs de nos jours y'a surement plus de conteneurs que de VM qui tournent dans le monde.
Perso dans son cas je ferais: désinstaller Docker, reset iptables complet, install Docker, lancer son conteneur, tester si tout ok. puis commencer a rajouter les blocages & règles dans iptables et vraiment si nécessaire.
pour la sécurité de base de ssh:
-ne pas mettre ssh sur le port 22 mais un autre port pas commun.
-interdire les accès ssh avec mot de passe (donc autoriser que les accès par clés crypto)
-du coup plus besoin d'utiliser fail2ban
-
Mais pour quelle raison utiliser Docker alors ? j'ai du mal à comprendre pourquoi utiliser ça, si ça ne fonctionne pas comme on veut.
Moi par exemple, je n'y connaît rien, n'y voit aucun intérêt donc je reste sur de la virtualisation qui fait tout ce dont j'ai besoin.
Dans mon cas j'utilise docker car je n'ai pas le choix si je veux utiliser certains services (comme Filestash qui n'est proposé qu'en Docker)...
Les devs se mettent de plus en plus à Docker, et ne proposent que du docker ::) (plus facile pour eux a maintenir j'imagine...)
Mes VMs KVM/QEMU fonctionnent très bien sur ma machine host, je n'ai aucun soucis de la sorte :-X
J'applique déjà tes points concernant la sécurité SSH mais pour fail2ban, tu serais surpris des @IP qui essayent encore de forcer malgré l'auth par clé.
(Et mon fail2ban me sert pour d'autre services et les alertes mails, je préfère le garder ;D)
Par contre je testerais en virant docker et en essayant Podman (qui m’a bien donné envie sur le papier vs docker)
Je reviendrais poster mes résultats à la sortie de Bullseye du coup :)
-
Quand je vois les problèmes rencontrés et la quasi impossibilité à débugguer, ça fait peur...
C'est aussi ce que je pensais au début, mais voyant de plus en plus de logiciel distribué via docker, j'ai fini par essayé. On met très facilement en route de nouveaux programmes, les maj sont également simple, on s'embête plus avec les dépendances, tout se passe pour le mieux. Puis un jour c'est la panique car une maj casse ou un truc se passe pas comme prévu. Et puis en fait suffit de garder son calmer, chercher un peu sur google et on trouve une solution.
Après 2-3 problème du genre + lire quelques éléments sur le fonctionnement interne, on fini par comprendre comment ça marche, gagné en confiance. Et puis après on fini par ne plus pouvoir s'en passer et l'utiliser partout où cela est pertinent.
Ça faut le coup d'essayer ;)
En soit les container ne sont que des couches d'abstractions, qui réalisent un mapping entre une ressource virtuel du container et celle de l'hôte.
Là où une VM est une couche d'abstraction matériel sur lequel tourne un système entier, un container c'est une multitude de couche d'abstraction a un niveau plus élevé : système de fichier, processus, réseau, etc. sur lesquelles des programmes vont être lancé
https://platform.sh/blog/2020/the-container-is-a-lie/