Estou construindo um contêiner para Kubernetes que executa um controlador de domínio SAMBA Active Directory.

Estou fazendo o trabalho por meio do Ansible e o contêiner está sendo implantado em um cluster Kubernetes (K3S).

O Docker está usando os seguintes arquivos como parte de sua construção:

etc/krb5.conf
etc/bind/rndc.key
etc/bind/named.conf.local
etc/bind/db.0
etc/bind/db.255
etc/bind/db.empty
etc/bind/named.conf.options
etc/bind/db.local
etc/bind/named.conf
etc/bind/db.127
etc/bind/named.conf.default-zones
etc/supervisor/conf.d/supervisord.conf
etc/freeradius/3.0/mods-available/eap
etc/freeradius/3.0/mods-available/realm
etc/freeradius/3.0/mods-available/ntlm_auth
etc/freeradius/3.0/mods-available/mschap
etc/freeradius/3.0/clients.conf
etc/freeradius/3.0/proxy.conf
etc/freeradius/3.0/sites-available/default
etc/freeradius/3.0/sites-available/inner-tunnel
boot/init.sh
boot/kdb5_util_create.expect
Dockerfile

A ideia é que para todos os arquivos o caminho seja o mesmo dentro do container, mas /como prefixo.

No entanto, me deparei com algo estranho ao inspecionar o contêiner em execução que foi compilado como resultado.

O conteúdo de /etc/samba, /etc/binde /etc/freeradiusdefinitivamente não deveria ser o mesmo!

O conteúdo do meu Dockerfileé o seguinte:

FROM ubuntu:noble

ENV DEBIAN_FRONTEND noninteractive

# Avoid ERROR: invoke-rc.d: policy-rc.d denied execution of start.
RUN echo "#!/bin/sh\nexit 0" > /usr/sbin/policy-rc.d

VOLUME ["/var/lib/samba", "/etc/samba", "/etc/bind", "/etc/freeradius", "/SambaVolume"]

# Setup ssh and install supervisord
RUN apt-get update
RUN apt-get upgrade -y
RUN apt-get install -y openssh-server supervisor ntp mc
RUN mkdir -p /var/run/sshd
RUN mkdir -p /var/log/supervisor
RUN sed -ri 's/PermitRootLogin without-password/PermitRootLogin Yes/g' /etc/ssh/sshd_config

# Add SAMBA VolumeShare location
RUN mkdir -p /SambaVolume

# Install bind9 dns server
RUN apt-get install -y bind9 dnsutils
# Copy tweaked DNS setttings (instead of ADD, due to we want to overwrite any existing files)
COPY etc/bind/* /etc/bind/

# Install samba and dependencies to make it an Active Directory Domain Controller
RUN apt-get install -y samba smbclient winbind libpam-winbind libnss-winbind krb5-kdc libpam-krb5

# Install Freeradius so validate VPN users against samba
RUN apt-get install -y freeradius

# Copy Freeradius customised files
COPY etc/freeradius/ /etc/freeradius/

# Copy customized kerberos configuration file
COPY etc/krb5.conf /etc/

# Install utilities needed for setup
RUN apt-get install -y expect pwgen
ADD boot/kdb5_util_create.expect /root/kdb5_util_create.expect

# Install rsyslog to get better logging of ie. bind9
RUN apt-get install -y rsyslog

# Create run directory for bind9
RUN mkdir -p /var/run/named
RUN chown -R bind:bind /var/run/named

# Add supervisord and init
ADD etc/supervisor/conf.d/supervisord.conf /etc/supervisor/conf.d/supervisord.conf
ADD boot/init.sh /root/init.sh
RUN chmod 755 /root/init.sh
EXPOSE 53/tcp 53/udp 80/tcp 80/udp 88/tcp 88/udp 135/tcp 135/udp 137/tcp 137/udp 
EXPOSE 138/tcp 138/udp 389/tcp 389/udp 443/tcp 443/udp 445/tcp 445/udp 464/tcp 464/udp 
EXPOSE 636/tcp 636/udp 3268/tcp 3268/udp 3269/tcp 3269/udp 9389/tcp 9389/udp
EXPOSE 123/udp 22/tcp 22/udp
ENTRYPOINT ["/root/init.sh"]
CMD ["app:start"]

E o contêiner compilado está sendo armazenado em um registro local usando os seguintes comandos:

  docker build -t samba:latest samba/
  docker tag samba:latest registry.example.com:5000/samba:latest
  docker push registry.example.com:5000/samba:latest  

Ele está sendo implantado através do Ansible com a seguinte tarefa:

- name: Create SAMBA Deployment
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: apps/v1
      kind: StatefulSet
      metadata:
        name: samba
        namespace: samba-system
        labels:
          app: samba
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: samba
        template:
          metadata:
            labels:
              app: samba
          spec:
            volumes:
              - name: samba-config
                persistentVolumeClaim:
                  claimName: samba-config-vol

            containers:
              - name: samba
                image: registry.example.com:5000/samba:latest
                ports:
                  - containerPort: 123
                    protocol: UDP

#           ### SKIPPING ###

                 - containerPort: 9389
                    protocol: UDP
                  - containerPort: 9389
                    protocol: TCP

                volumeMounts:
                  - name: samba-config
                    mountPath: /etc/samba
                  - name: samba-config
                    mountPath: /etc/bind
                  - name: samba-config
                    mountPath: /etc/freeradius
                  - name: samba-config
                    mountPath: /var/lib/samba

                envFrom:
                  - configMapRef:
                      name: samba-environment-map

                securityContext:
                  priviledged: true
                  allowPrivilegeEscalation: true
                  readOnlyRootFilesystem: false

                  capabilities:
                    add:
                      - ALL

Estou me perguntando por que o conteúdo das pastas /etc/bindé /etc/sambao /etc/freeradiusmesmo.

Pensei ter lido em algum lugar que você poderia usar o mesmo persistentVolumeClaimpara todas as pastas.

Estou instalando Home Assistantem meu cluster K3S Kubernetes por meio do Ansible e quero usar um certificado Let's Encrypt para minha entrada que foi gerada pela Cert-Managerexecução em meu cluster.

Estou usando o seguinte manual ao instalar o Home Assistant:

---
- name: Create HomeAssistant namespace
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: Namespace
      metadata:
        name: home-system

- name: Generate certificate for HomeAssistant
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: cert-manager.io/v1
      kind: Certificate
      metadata:
        name: homeassistant-tls
        namespace: home-system
      spec:
        secretName: homeassistant-tls-secret
        commonName: "homeassistant.example.com" 
        dnsNames:
        - "homeassistant.example.com"
        issuerRef:
          name: letsencrypt-staging
          kind: ClusterIssuer

- name: Get TLS certificate secret
  kubernetes.core.k8s_info:
    api_version: v1
    name: homeassistant-tls-secret
    kind: Secret
    namespace: home-system
  register: tls_secret
  
- name: Create ConfigMap for HomeAssistant
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: home-config
        namespace: home-system

      data:
        fullchain.pem: "{{ tls_secret.resources[0].data['tls.crt'] | b64decode }}"

        privkey.pem: "{{ tls_secret.resources[0].data['tls.key'] | b64decode }}"

        groups.yaml: |-

        scripts.yaml: |-

        scenes.yaml: |-

        known_devices.yaml: |- 
    
        automations.yaml: |-

        configuration.yaml: |-

          # Loads Default configuration - DO NOT REMOVE
          default_config:

          # Load frontend themes from the themes folder
          frontend:
            themes: !include_dir_merge_named themes
          
          # Text-to-speech
          tts:
            - platform: google_translate
          
          group: !include groups.yaml
          automation: !include automations.yaml
          script: !include scripts.yaml
          scene: !include scenes.yaml

          http:
            use_x_forwarded_for: true

            trusted_proxies:
            - 127.0.0.1
            - 10.42.0.0/16
            - 10.43.0.0/16
            - 192.168.0.0/24

            ssl_certificate: /ssl/fullchain.pem
            ssl_key: /ssl/privkey.pem

- name: Define storage space for HomeAssistant
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: homeassist-pvc
        namespace: home-system
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: small-longhorn # Store data on only 2 nodes instead of 3
        resources:
          requests:
            storage: 5Gi

- name: Add HomeAssistant StatefulSet
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: apps/v1
      kind: StatefulSet
      metadata:
        name: homeassistant
        namespace: home-system
        labels:
          app: homeassistant
      spec:
        serviceName: home-svc
        replicas: 1
        selector:
          matchLabels:
            app: homeassistant
        template:
          metadata:
            labels:
              app: homeassistant
          spec:
            volumes:
            - name: home-config-vol
              persistentVolumeClaim:
                claimName: homeassist-pvc

            - name: home-config-file
              configMap:
                name: home-config

            containers:
            - name: homeassistant
              image: lscr.io/linuxserver/homeassistant:latest
              ports:
                - containerPort: 8123
              volumeMounts:
              - name: home-config-vol
                mountPath: /config

              - name: home-config-file
                mountPath: /config/configuration.yaml
                subPath: configuration.yaml
                
              - name: home-config-file
                mountPath: /config/automations.yaml
                subPath: automations.yaml

              - name: home-config-file
                mountPath: /config/scripts.yaml
                subPath: scripts.yaml

              - name: home-config-file
                mountPath: /config/scenes.yaml
                subPath: scenes.yaml

              - name: home-config-file
                mountPath: /config/groups.yaml
                subPath: groups.yaml

              - name: home-config-file
                mountPath: /ssl/fullchain.pem
                subPath: fullchain.pem

              - name: home-config-file
                mountPath: /ssl/privkey.pem
                subPath: privkey.pem

              env:
                - name: PUID
                  value: "1000"
                - name: PGID
                  value: "1000"
                - name: TZ
                  value: "Etc/UTC"

            securityContext:
              capabilities:
                add:
                - NET_ADMIN
                - NET_RAW
                - SYS_ADMIN

              priviledged: true

- name: Define HomeAssistant service ports
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: Service
      metadata:
        name: home-svc
        namespace: home-system
        annotations: 
          metallb.universe.tf/address-pool: default-pool
      spec:
        type: LoadBalancer
        externalTrafficPolicy: Local
        selector:
          app: homeassistant
        ports:
          - name: "8123"
            port: 8123
            targetPort: 8123

- name: Add HomeAssistant ingress
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: networking.k8s.io/v1
      kind: Ingress
      metadata:
        name: homeassistant
        namespace: home-system

        annotations:
          kubernetes.io/ingress.class: nginx
          cert-manager.io/cluster-issuer: letsencrypt-staging
          nginx.ingress.kubernetes.io/backend-protocol: HTTPS
          nginx.ingress.kubernetes.io/ssl-redirect: "true"
          nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

      spec:
        ingressClassName: nginx
        tls:
        - hosts:
          - homeassistant.example.com
          secretName: homeassistant-tls

        rules:
        - host: 'homeassistant.example.com'
          http:
            paths:
            -  path: /
               pathType: Prefix
               backend:
                service:
                  name: home-svc
                  port:
                    number: 8123

Substituí o real FQDNpor um nome pertencente a example.com. :-)

Alguns pontos-chave:

O Home Assistant suporta criptografia TLS.

Meu primeiro trabalho é, portanto, criar um certificado Let's Encrypt, que estou nomeando homeassistant-tls. Possui o segredo associado homeassistant-tls-secret.

O próximo passo é extrair o certificado e a chave do segredo homeassistant-tls-secrete usá-los para criar os arquivos fullchain.peme privkey.pemno ConfigMap home-config.

Os arquivos contêm o certificado e a chave decodificados em base64.

Os arquivos de certificado e chave são então armazenados na /sslpasta dentro do contêiner, o que leva de volta ao último arquivo importante definido no ConfigMap: configuration.yaml.

Para habilitar a criptografia TLS, precisamos adicionar as seguintes linhas à httpseção de configuration.yaml:

  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

Tentei chamar os arquivos tls.crte tls.key, mas aparentemente o Home Assistant não gostou. :-)

Tudo o que sei com certeza é que os arquivos devem ser codificados em PEM.

Depois de executar o manual, recebo a seguinte saída:

root@central:~# kubectl get svc -n home-system
NAME       TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
home-svc   LoadBalancer   10.43.23.186   192.168.0.203   8123:30630/TCP   81m

root@central:~# kubectl get ingress -n home-system
NAME            CLASS   HOSTS                       ADDRESS         PORTS     AGE
homeassistant   nginx   homeassistant.example.com   192.168.0.200   80, 443   85m

O site está funcionando quando digito o endereço: https://192.168.0.203:8123/ou https://homeassistant.example.comno navegador.

No entanto, quando inspeciono os certificados associados, recebo o seguinte:

• https://192.168.0.203:803(LoadBalancer) aponta para o certificado Let's Encrypt, que pelo que sei é porque defini os certificados na /sslpasta.
• https://homeassistant.example.com(Ingress) aponta para um certificado de cluster Kubernetes genérico.

Então, como faço para Ingressusar o certificado correto? :-)

Alterar secretNamepara homeassist-tls-secret não funciona com certeza. :-)

Estou executando o K3S Kubernetes em um servidor de cluster que consiste em uma mistura de nós Raspberry 4 e Raspberry 5.

Quero instalar o aplicativo de rede Unifi no servidor de cluster e progredi bastante na configuração junto com MetalLBo LonghornAnsible Cert-Manager.

Estou usando a imagem Docker do linuxserver.io para meu servidor de cluster e é necessário instalar um pod separado contendo MongoDB.

Pesquisando on-line sobre como instalar o MongoDB me deu o seguinte arquivo Ansible:

- name: Generate MongoDB secrets
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: Secret
      metadata:
        name: mongodb-secret
        namespace: default
      type: Opaque
      data:
        password: VmVyeVNlY3JldFBhc3NvcmQ= # "VerySecretPassword" encoded in Base64

- name: Create Unifi DB init script
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: mongodb-init-script
        namespace: default
      data:
        init-script.js: |-
          db.getSiblingDB("unifi-db").createUser({user: "unifi", pwd: "unifi", roles: [{role: "dbOwner", db: "unifi-db"}]});
          db.getSiblingDB("unifi-db_stat").createUser({user: "unifi", pwd: "unifi", roles: [{role: "dbOwner", db: "unifi-db_stat"}]});

- name: Create MongoDB service
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: Service
      metadata:
        name: mongodb-svc
        namespace: default
        labels: 
          app: mongodb
      spec:
        type: ClusterIP
        ports:
        - protocol: TCP
          port: 27017
          targetPort: 27017
        selector:
          app: mongodb

- name: Create MongoDB statefull set
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: apps/v1
      kind: StatefulSet
      metadata:
        name: mongodb
        namespace: default
        labels:
          app: mongodb
      spec:
        serviceName: mongodb-svc
        replicas: 1
        selector:
          matchLabels:
            app: mongodb
        template:
          metadata:
            labels:
              app: mongodb
          spec:
            containers:
            - name: mongodb
              image: mongo:4.4.18 # Do NOT set it to 'latest'. I'll explain below.
              ports:
              - containerPort: 27017
              env:
              - name: MONGO_INITDB_ROOT_USERNAME
                value: admin

              - name: MONGO_INITDB_ROOT_PASSWORD
                valueFrom:
                  secretKeyRef:
                    name: mongodb-secret
                    key: password

              volumeMounts:
                - name: mongodb-data
                  mountPath: /data/db

        volumeClaimTemplates:
        - metadata:
            name: mongodb-data
          spec:
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 1Gi

- name: Initialize MongoDB
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: batch/v1
      kind: Job
      metadata:
        name: mongodb-init-job
        namespace: default
      spec:
        template:
          metadata:
            name: mongodb-init-pod
          spec:
            restartPolicy: OnFailure
            containers:
            - name: mongodb-init-container
              image: mongo:4.4.18 # Again: Do NOT set it to 'latest'.
              command: [ "mongo", "--host", "mongodb-0.mongodb-svc.default.svc.cluster.local", "--authenticationDatabase", "admin", "--username", "admin", "--password", "$(MONGO_INITDB_ROOT_PASSWORD)", "/mongo-init-script/init-script.js" ]
              
              env:
              - name: MONGO_INITDB_ROOT_PASSWORD
                valueFrom:
                  secretKeyRef:
                    name: mongodb-secret
                    key: password
              volumeMounts:
              - name: mongo-init-script
                mountPath: /mongo-init-script
            volumes:
            - name: mongo-init-script
              configMap:
                name: mongodb-init-script

A seção funciona bem.

A saída de kubectl logs mongodb-init-job-f5f54é a seguinte:

MongoDB shell version v4.4.18
connecting to: mongodb://mongodb-0.mongodb-svc.default.svc.cluster.local:27017/?authSource=admin&compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("39ad2f51-07a9-4e67-8c5b-68f6fff92872") }
MongoDB server version: 4.4.18
Successfully added user: {
        "user" : "unifi",
        "roles" : [
                {
                        "role" : "dbOwner",
                        "db" : "unifi-db"
                }
        ]
}
Successfully added user: {
        "user" : "unifi",
        "roles" : [
                {
                        "role" : "dbOwner",
                        "db" : "unifi-db_stat"
                }
        ]
}

O que significa que eu poderia fazer login admine criar um usuário MongoDB chamado unificom senha unifique tenha acesso ao banco de dados unifi-db.

Também sei que é acessível via DNS configurando o host do banco de dados para mongodb-0.mongodb-svc.default.svc.cluster.localusar port 27017.

A razão pela qual escolhi instalar a versão 4.4.18 do MongoDB é porque embora o Unifi Network Application suporte até a versão 7.0, não é o mesmo caso do suporte do MongoDB para as placas Raspberry Pi.

O MongoDB só pode ser executado até a versão 4.4.18 no Raspberry Pi.

O próximo passo é fazer com que o aplicativo de rede Unifi seja executado em meu servidor de cluster.

Estou usando as seguintes tarefas para fazer isso:

---
- name: Define storage space for Unifi
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: unifi-cluster-pvc
        namespace: default
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: longhorn
        resources:
          requests:
            storage: 5Gi

- name: Add unifi deployment
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: unifi
        namespace: default
        labels:
          app: unifi
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: unifi
        template:
          metadata:
            labels:
              app: unifi
          spec:
            volumes:
            - name: unifi-config
              persistentVolumeClaim:
                claimName: unifi-cluster-pvc
            containers:
            - name: unifi
              image: lscr.io/linuxserver/unifi-network-application:latest
              ports:
                - containerPort: 3478
                  protocol: UDP
                - containerPort: 10001
                  protocol: UDP
                - containerPort: 5514
                  protocol: UDP
                - containerPort: 8080
                - containerPort: 8443
                - containerPort: 8843
                - containerPort: 8880
                - containerPort: 6789
              volumeMounts:
              - name: unifi-config
                mountPath: /config
              env:
                - name: PUID
                  value: "1000"
                - name: GUID
                  value: "1000"
                - name: MONGO_USER
                  value: "unifi"
                - name: MONGO_PASS
                  value: "unifi"
                - name: MONGO_HOST
                  value: "mongodb-0.mongodb-svc.default.svc.cluster.local"
                - name: MONGO_PORT
                  value: "27017"
                - name: MONGO_DBNAME
                  value: "unifi-db"
                - name: MONGO_TLS
                  value: "false"

- name: Define unifi service ports
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: Service
      metadata:
        name: unifi
        namespace: default
      spec:
        type: LoadBalancer
        selector:
          app: unifi
        ports:
          - name: "8080"
            port: 8080
            targetPort: 8080
          - name: "8443"
            port: 8443
            targetPort: 8443
          - name: "8843"
            port: 8843
            targetPort: 8843
          - name: "8880"
            port: 8880
            targetPort: 8880
          - name: "6789"
            port: 6789
            targetPort: 6789
          - name: "3478"
            port: 3478
            protocol: UDP
            targetPort: 3478
          - name: "10001"
            port: 10001
            protocol: UDP
            targetPort: 10001
          - name: "5514"
            port: 5514
            protocol: UDP
            targetPort: 5514

- name: Add unifi ingress
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: networking.k8s.io/v1
      kind: Ingress
      metadata:
        name: unifi
        namespace: default
        annotations:
          nginx.ingress.kubernetes.io/backend-protocol: HTTPS
          cert-manager.io/cluster-issuer: letsencrypt-staging
          cert-manager.io/acme-challenge-type: dns01
      spec:
        ingressClassName: nginx
        tls:
        - hosts:
          - unifi.example.com
          secretName: unifi-tls
        rules:
        - host: 'unifi.example.com'
          http:
            paths:
            - path: /
              pathType: Prefix
              backend:
                service:
                  name: unifi
                  port:
                    number: 8443

A execução do comando kubectl get podsme dá a seguinte saída:

NAME                     READY   STATUS      RESTARTS   AGE
mongodb-0                1/1     Running     0          64m
unifi-5dcdbfb6d9-8wbbp   1/1     Running     0          64m
mongodb-init-job-f5f54   0/1     Completed   2          64m

E posso fazer login no unifi-dbbanco de dados com o comando:kubectl exec mongodb-0 -it -- mongo -u unifi -p unifi unifi-db

O comando:show collections

Dá-me, entre outros, o seguinte:

account
admin
alarm
crashlog
dashboard
device
...

Até agora tudo bem.

No entanto, não consigo colocar o site do aplicativo de rede Unifi em funcionamento.

A saída do comando kubectl log unifi-5dcdbfb6d9-8wbbpfornece, entre outras, esta mensagem:

Error creating bean with name 'statDbService' 
defined in com.ubnt.service.DatabaseSpringContext: 
Command failed with error 13 (Unauthorized): 'not 
authorized on unifi-db_stat to execute command { 
listCollections: 1, cursor: {}, nameOnly: true, $db: 
"unifi-db_stat", lsid: { id: UUID("99b4d07f-b3f3-49c9-9979-dbdd27445881") 
} }' on server mongodb-0.mongodb-svc.default.svc.cluster.local:27017. 
The full response is {"ok": 0.0, "errmsg": "not authorized on unifi-db_stat 
to execute command { listCollections: 1, cursor: {}, nameOnly: true, $db: 
\"unifi-db_stat\", lsid: { id: UUID(\"99b4d07f-b3f3-49c9-9979-dbdd27445881\") 
} }", "code": 13, "codeName": "Unauthorized"}

Como posso resolver esse problema?

Lendo a documentação sobre como funciona a atribuição de funções no MongoDB, posso ler que definir a função de um usuário como dbOwneré basicamente uma passagem de acesso total, pois combina as funções de readWritee dbAdminem userAdminuma função.

Uma das permissões que você obtém é listCollectionsa , referenciada no código de erro acima.

Então, o que está acontecendo?

Estou tentando instalar o Unifi em um servidor de cluster Kubernetes (K3S) usando Ansible e tive problemas ao tentar definir uma reivindicação de volume persistente.

Estou usando o módulo Kubernetes.Core e defini minha tarefa como:

- name: Define storage space for Unifi
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: unifi-cluster-pvc
        namespace: default
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: longhorn
      resources:
        requests:
          storage: 100Mi

No entanto, quando executo meu manual, recebo o seguinte erro:

TASK [unifi : Define storage space for Unifi] 
***********************************************************************
fatal: [central.example.com]: FAILED! => {"changed": false, "msg": 
"Failed to create object: b'{\"kind\":\"Status\",\"apiVersion\":\"v1\",
\"metadata\":{},\"status\":\"Failure\",\"message\":\"PersistentVolumeClaim 
\\\\\"unifi-cluster-pvc\\\\\" is invalid: spec.resources[storage]: Required 
value\",\"reason\":\"Invalid\",\"details\":{\"name\":\"unifi-cluster-pvc\",
\"kind\":\"PersistentVolumeClaim\",\"causes\":[{\"reason\":\"FieldValueRequired\",
\"message\":\"Required value\",\"field\":\"spec.resources[storage]\"}]},\"code\":422}\\n'", 
"reason": "Unprocessable Entity"}

Existe alguém que possa explicar o que está acontecendo?

Porque se eu criar um arquivo yaml chamado test.ymlcom o seguinte conteúdo:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: unifi-cluster-pvc
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 100Mi

e execute o comando: kubectl apply -f test.ymlno meu controlador

Então recebo a mensagem de volta:

persistentvolumeclaim/unifi-cluster-pvc created

Estou tentando aprender como o Kubernetes funciona, então criei meu próprio K3Scluster usando o guia de início rápido .

Então instalei o Cert Manager usando o guia do Helm .

Quero usar certificados Let's Encrypt para meu cluster e validá-los usando o dns01webhook com meu provedor DNS Simply.com.

Isso pode ser feito usando um webhook encontrado aqui:

https://github.com/RunnerM/simply-dns-webhook

Atualmente estou testando se consigo um certificado do Let's Encrypt usando seu servidor de teste.

Criei o arquivo Yaml letsencrypt-staging.yamlcom o seguinte conteúdo para ClusterIssuer:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
  namespace: default
spec:
  acme:
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-staging-key
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    solvers:
    - dns01:
        webhook:
          groupName: com.github.runnerm.cert-manager-simply-webhook
          solverName: simply-dns-solver
          config:
            secretName: simply-credentials # notice the name
      selector:
        dnsZones:
        - 'cluster.example.com'
        - '*.cluster.example.com'

Meu arquivo de configuração é basicamente um copiar e colar literalmente do exemplo encontrado na página RunnerM GitHub.

Para emitir um certificado criei um arquivo Yaml chamado certificate-test.yamlcom o seguinte conteúdo:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: test-certificate
spec:
  dnsNames:
  - test.cluster.example.com
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer

  secretName: test-certificate-tls

Devo então conseguir obter um certificado emitido usando os seguintes comandos:

kubectl apply -f letsencrypt-staging.yaml
kubectl apply -f certificate-test.yaml

No entanto, não estou recebendo um certificado emitido.

Ao executar kubectl describe challenge test-certificate-1-1965387138-1295925723recebo a seguinte mensagem de erro:

...
Status:
  Presented:   false
  Processing:  true
  Reason:      secrets "simply-credentials" is forbidden: User "system:serviceaccount:default:my-simply-dns-webhook" cannot get resource "secrets" in API group "" in the namespace "cert-manager"
  State:       pending
E
...

Entendo que o webhook do Simply DNS my-simply-dns-webhookestá em execução no defaultnamespace e as credenciais do Simply DNS estão armazenadas no cert-managernamespace.

Então, como faço para permitir que o webhook do Simply DNS acesse recursos no namespace cert-manager?

Informações adicionais

A execução do comando kubectl get clusterrolebindingsfornece, entre outras, as seguintes informações:

my-simply-dns-webhook:secret-access                    ClusterRole/my-simply-dns-webhook:secret-access                    76s
simply-dns-webhook:challenge-management                ClusterRole/simply-dns-webhook:challenge-management                76s
my-simply-dns-webhook:domain-solver                    ClusterRole/my-simply-dns-webhook:domain-solver                    76s
my-simply-dns-webhook:flow-control                     ClusterRole/my-simply-dns-webhook:flow-control                     76s
my-simply-dns-webhook:auth-delegator                   ClusterRole/system:auth-delegator                                  76s

A saída de kubectl get clusterrole my-simply-dns-webhook:secret-accessfornece o seguinte resultado:

Name:         my-simply-dns-webhook:secret-access
Labels:       app=simply-dns-webhook
              app.kubernetes.io/managed-by=Helm
              chart=simply-dns-webhook-1.5.4
              heritage=Helm
              release=my-simply-dns-webhook
Annotations:  meta.helm.sh/release-name: my-simply-dns-webhook
              meta.helm.sh/release-namespace: default
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  secrets.*  []                 []              [get]

E o comando kubectl describe clusterrolebindings my-simply-dns-webhook:secret-accessdá a saída:

Name:         my-simply-dns-webhook:secret-access
Labels:       app=simply-dns-webhook
              app.kubernetes.io/managed-by=Helm
              chart=simply-dns-webhook-1.5.4
              heritage=Helm
              release=my-simply-dns-webhook
Annotations:  meta.helm.sh/release-name: my-simply-dns-webhook
              meta.helm.sh/release-namespace: default
Role:
  Kind:  ClusterRole
  Name:  my-simply-dns-webhook:secret-access
Subjects:
  Kind            Name                   Namespace
  ----            ----                   ---------
  ServiceAccount  my-simply-dns-webhook  cert-manager

Então, o que estou perdendo?

Esta é uma continuação da minha pergunta anterior no envio de rotas estáticas da implementação do servidor Freeradius DHCP em combinação com o servidor Strongswan VPN.

Ao depurar o Freeradius usando o tcpdump e o Wireshark, descobri que posso enviar rotas estáticas sem classes do servidor DHCP do Freeradius adicionando DHCP-Classless-Static-Routee DHCP-Site-specific-25(também conhecido como rota estática da Microsoft) opções para minhas DHCP-Discovere DHCP-Requestseções do arquivo de configuração do servidor dhcp.

No entanto: Parece que as rotas estáticas não são aceitas pelo cliente VPN da Microsoft se eu definir o gateway padrão 0.0.0.0como sugerido pela documentação do Strongswan .

Pelo menos não consigo encontrar as rotas anunciadas no meu cliente Windows ao usar o route print -4.

Também não consigo adicionar as rotas manualmente no cliente Windows quando estou usando 0.0.0.0como gateway padrão sobre a interface VPN.

No entanto:

Digamos que eu queira acessar a sub -rede 192.168.200.0/24pela VPN e meu servidor VPN atribua o endereço 192.168.201.2/24ao meu cliente Windows. Então é realmente possível criar uma rota estática no lado do cliente Windows declarando que a sub-rede 192.168.200.0/24 é acessível via 192.168.201.2 usando o comando windows:

route add 192.168.200.0 mask 255.255.255.0 192.168.201.2

Eu sei que parece um pouco estranho, mas posso fazer ping em qualquer host na 192.168.200.0sub-rede, então, desde que funcione, estou feliz. :-)

Mas: eu ficaria mais feliz se pudesse fazer a mesma coisa anunciando as rotas do meu servidor VPN em vez de fazê-lo manualmente em todos os clientes VPN. :-)

Isso significa que eu tenho que fazer um pouco de programação dinâmica para a configuração do DHCP no Freeradius. No meu caso, significa que tenho que fazer uma referência a um módulo perl em DHCP-Discover e DHCP-request que pega o endereço IP vpn do cliente atribuído, converte-o em octetos e combina-o com as rotas estáticas que também são fornecidas como octetos.

Um exemplo:

A sub -rede 192.168.200.0/24será codificada como 0x18c0a8c8a máscara de sub-rede é codificada primeiro.

O cliente 192.168.201.2/24será codificado como se estivesse 0xc0a8c902apenas convertendo cada número no endereço IP para hexadecimal.

A codificação final para a rota será: 0x18c0a8c8c0a8c902pois é apenas uma concatinação das duas strings.

Então eu tenho que usar update replycom o seguinte código:

  update reply {
    &DHCP-Classless-Static-Route = 0x18c0a8c8c0a8c902
    &DHCP-Site-specific-25 = 0x18c0a8c8c0a8c902
  }

Se houver mais rotas, todas as rotas serão concatenadas em uma longa string.

A parte complicada:

Suponha que você tenha a configuração padrão do servidor DHCP do Freeradius conforme encontrado no freeradius/3.0/sites-available/dhcparquivo.

A estrutura geral do arquivo para DHCP-Discover e DHCP-Request é a seguinte:

dhcp DHCP-Request {
  update reply {
    &DHCP-Message-Type = DHCP-Ack
  }

  update reply {
    # General DHCP options, such as default GW, DNS, IP-address lease time etc.
  }

  update control {
    &Pool-Name := "vpn_pool"
  }

  dhcp_sqlippool

  ok
}

Então, pelo que entendi, preciso chamar meu módulo perl depois de dhcp_sqlippoolter sido chamado e antes de retornar ok, porque dhcp_sqlippoolé o módulo que atribui o endereço IP ao cliente VPN.

Isso significa que minha versão seria algo como:

dhcp DHCP-Request {
  update reply {
    &DHCP-Message-Type = DHCP-Ack
  }

  update reply {
    # General DHCP options, such as default GW, DNS, IP-address lease time etc.
  }

  update control {
    &Pool-Name := "vpn_pool"
  }

  dhcp_sqlippool

  perl

  # If perl module returned no error
  if(ok) {
    update reply {
      # Perl-Route contains a hex encoded string with all routes.
      &DHCP-Classless-Static-Route = Perl-Route
      &DHCP-Site-specific-25 = Perl-Route      
    }
  }

  # Not sure if this one is needed?
  update reply {
    &DHCP-End-Of-Options = 255
  }

  ok
}

Para fazê-lo funcionar, eu tenho que habilitar o perl na freeradius/3.0/mods-enabledpasta e modificar o nome do arquivo freeradius/3.0/mods-enabled/perlpara apontá-lo para o meu módulo perl. Como por exemplo:

filename = ${modconfdir}/${.:instance}/dhcp/Options.pm

Mas como faço para referenciar a chamada para perl da maneira correta?

Eu pensei que tinha que habilitar a linha func_post_auth = post_authe freeradius/3.0/mods-enabled/perlcriar uma sub post_authseção no meu módulo perl para lidar com chamadas do Freeradius, mas pelo que posso ver no meu log, recebo o seguinte erro no Freeradius:

(8) perl: perl_embed:: module = /etc/freeradius/3.0/mods-config/perl/dhcp/Options.pm , 
func = post_auth exit status= Undefined subroutine &main::post_auth called.
...
(8)     [perl] = fail
(8)   } # dhcp DHCP-Discover = fail

Então, o que é que eu não estou vendo?

Estou tentando configurar o Strongswan para o tunelamento dividido da VPN.

O que eu quero é apenas as sub-redes 10.88.0.0/16e 10.0.200.0/24é acessível através do túnel VPN. Todo o resto é tratado através default gatewayda rede.

Todos os clientes recebem um endereço IP pertencente à 10.0.201.0/24sub-rede.

No meu arquivo de configuração tenho entre outros o seguinte:

# Default login method
eap-defaults {
  remote {
   auth = eap-radius
   id = %any
   eap_id = %any
  }
}

connections
{
  conn-unix : conn-defaults, eap-defaults {
    children {
      net {
        local_ts = 10.0.200.0/24, 10.88.0.0/16
      }

      esp_proposals = aes128gcm128-x25519
    }

    pools = IkeVPN-ipv4
    proposals = aes128-sha256-x25519
  }

  conn-windows : conn-defaults, eap-defaults {
    children {
      net {
        local_ts = 10.0.200.0/24, 10.88.0.0/16
      }

      esp_proposals = aes256-sha256-prfsha256-modp1024
    }

    proposals = aes256-sha256-prfsha256-modp1024
    pools = IkeVPN-ipv4
  }
}

pools
{
  IkeVPN-ipv4 {
    addrs = 10.0.201.0/24
    dns = 10.0.88.2
  }
}

Quando faço login pela VPN, é possível fazer ping nos hosts pertencentes a 10.88.0.0/16e 10.0.200.0/24, para que eu saiba que posso usar o túnel VPN.

No entanto:

Se eu tentar acessar qualquer outro recurso na Internet enquanto ainda estiver conectado à VPN, não consigo nem mesmo pingar o endereço IP pertencente a esse recurso.

Na minha tabela de roteamento no meu computador Windows, posso encontrar as seguintes entradas:

Eu sei que quando você tem duas rotas para uma determinada sub-rede, como 0.0.0.0/0na tabela de roteamento, qualquer regra com a métrica mais baixa vence e o tráfego é encaminhado usando essa regra.

No entanto não quero que o servidor VPN instale uma rota padrão via VPN, mas apenas informe que as sub-redes 10.88.0.0/16e 10.0.200.0/24tem que ser roteado via VPN.

O que eu quero é que eu veja uma tabela de roteamento mais próxima disso sem ter que editar a tabela de roteamento manualmente em cada cliente VPN:

Então, como eu vou fazer isso?

Estou construindo um contêiner Podman que executa o Samba Active Directory com suporte a Bind9 e Freeradius usando o Ansible e encontrei um problema.

O Samba funciona bem com DLZ_BIND como backend no meu contêiner, mas preciso integrar o Freeradius ao contêiner, para que eu possa dar suporte a logins via VPN.

Estou tentando modelar a seguinte linha em /etc/freeradius/3.0/mods-available/mschap:

ntlm_auth = "/usr/bin/ntlm_auth --allow-mschapv2 
  --request-nt-key 
  --username={mschap:User-Name} 
  --domain={{ ad_info.netbios_domain }} 
  --challenge=%{%{mschap:Challenge}:-00} 
  --nt-response=%{%{mschap:NT-Response}:-00}"

Para o exercício, você pode assumir que o valor de {{ ad_info.netbios_domain }}é EXAMPLE.

É o único lugar no arquivo onde eu uso uma variável Jinja.

No entanto, a execução do ansible-playbook faz com que o Ansible basicamente exploda na minha cara, quando tenta modelar o arquivo.

Presumo que seja porque a variável Jinja é inserida dentro de uma string qouted? Porque um script de shell BASH contendo a seguinte linha não explodirá no ansible:

SAMBA_ADMIN_PASSWORD="{{ ad_info.admin_password }}"

Então, qual é a maneira certa de usar Jinja, quando você tem uma string entre aspas?

Editar

Fiz um template contendo apenas a linha em questão e obtive o seguinte erro do ansible:

failed: [myhost.example.com] (item=etc/freeradius/3.0/mods-available/mschap) => 
{
  "ansible_loop_var": "item", 
  "changed": false, "item": 
  "etc/freeradius/3.0/mods-available/mschap-jinja", 
  "msg": "AnsibleError: template error while templating string: tag name expected. 

  String: ntlm_auth = \"/usr/bin/ntlm_auth 
    --allow-mschapv2 
    --request-nt-key 
    --username={mschap:User-Name} 
    --domain={{ ad_info.netbios_domain }} 
    --challenge=%{%{mschap:Challenge}:-00} 
    --nt-response=%{%{mschap:NT-Response}:-00}\"
"}

Eu tenho uma VPN StrongSwan que por algum motivo desconhecido para mim não pode conectar usuários iOS ao meu servidor VPN.

Algumas notas rápidas:

• Meu servidor StrongSwan é a frente para clientes VPN que se conectam à minha rede. Eu usei WireGuardpara meu roteamento site a site de back-end.

• Todos os usuários do StrongSwan VPN são validados em um FreeRadiusservidor.

• Os clientes StrongSwan são atribuídos a um IP na 192.168.201.0/24sub-rede, enquanto a rede de backbone WireGuard está sendo executada na 192.168.200.0/24sub-rede.

• Todos os clientes também recebem um endereço IPv6 público pertencente a uma sub-rede /48 atribuída a mim.

Eu corro o StrongSwan no Ubuntu 20.04 e meu arquivo de configuração está localizado na /etc/swanctl/config/pasta e é incluído por padrão devido ao nome do arquivo terminar em .conf.

O conteúdo é o seguinte:

# Default VPN server settings for all connections
conn-defaults {
    local_addrs = PUBLIC_IPV4, PUBLIC_IPV6

    local {
      auth = pubkey
      certs = vpn-ecdsa.cer
      id = vpn.example.com
    }

    version = 2
    send_certreq = no
    send_cert = always
    unique = never
    fragmentation = yes
    encap = yes
    dpd_delay = 60s

    rekey_time = 0s
}

# Default login method
eap-defaults {
  remote {
   auth = eap-radius
   id = %any
   eap_id = %any
  }
}

connections
{
  # Generic Android configuration that is extended further down.
  #
  # Works with StrongSwan VPN client for Android
  conn-unix : conn-defaults, eap-defaults {
    children {
      net {
        local_ts = 0.0.0.0/0, ::/0
      }

      net-unix : child-defaults {
      }

      esp_proposals = aes128gcm128-x25519
    }

    proposals = aes128-sha256-x25519
  }

  # All Windows klients matches this rule as username validation 
  # is done by 'eap_start = yes' in strongswan.conf. 
  #
  # Works with Windows 10 built-in VPN client.
  conn-windows : conn-defaults, eap-defaults {
    children {
      net {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha256-prfsha256-modp1024
    }

    proposals = aes256-sha256-prfsha256-modp1024
    pools = IkeVPN-site-ipv4, IkeVPN-site-ipv6

  }

  # A very similar configuration to Windows clients 
  # configuration, except iOS uses 2048 bit keys, 
  # while Windows uses 1024 bit keys.
  #
  # Does NOT work in its current state.
  conn-ios : conn-defaults, eap-defaults {
    children {
      net {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha2_256
      pools = IkeVPN-site-ipv4, IkeVPN-site-ipv6

    }

    proposals = aes256-sha256-prfsha256-modp2048
  }

  # Android users is matched against this connection as they are 
  # running the app StrongSwan VPN client. Username is passed in the
  # 'id' field to StrongSwan VPN server.
  conn-unix-site : connections.conn-unix {
    remote {
      id = *@site.example.com
    }
    pools = IkeVPN-site-ipv4, IkeVPN-site-ipv6
  }
}

pools
{
   IkeVPN-site-ipv4 {
      addrs = 192.168.201.0/24
      dns = 192.168.200.1
   }

   IkeVPN-site-ipv6 {
      addrs = 2001:db8:cafe::/97
      dns = 2001:db8::1
   }
}

Minha configuração é criada usando a estrutura fornecida na seguinte página da web:

https://wiki.strongswan.org/projects/strongswan/wiki/Strongswanconf#Referencing-other-Sections

A razão pela qual eu o uso é evitar repetir as mesmas configurações em todos os meus perfis de conexão.

Se você não estiver familiarizado com essa configuração, a configuração a seguir conn-iosdeve ser considerada equivalente:

conn-ios {
   # Obtained from conn-default
   local_addrs = PUBLIC_IPV4, PUBLIC_IPV6

   local {
      auth = pubkey
      certs = vpn-ecdsa.cer
      id = vpn.example.com
   }

   version = 2
   send_certreq = no
   send_cert = always
   unique = never
   fragmentation = yes
   encap = yes
   dpd_delay = 60s

   rekey_time = 0s

   # Obtained from eap-defaults
   remote {
      auth = eap-radius
      id = %any
      eap_id = %any
   }

   # Obtained from original conn-ios profile above.
   children {
      net {
         local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha2_256
      pools = IkeVPN-site-ipv4, IkeVPN-site-ipv6
   }

   proposals = aes256-sha256-prfsha256-modp2048
}

O certificado do servidor listado na conn-defaultseção é um certificado ECDSA obtido da Let's Encrypt usando Acme.sh.

Os valores de criptografia para proposalse esp_proposalsna configuração do iOS são obtidos da dica em: https://wiki.strongswan.org/projects/strongswan/wiki/AppleClients .

Ao testar todas as combinações de usuários de Android ou Windows, os usuários se conectam sem problemas, mas quando alguém tenta fazer login usando o iPhone, a conexão é interrompida.

A saída do log quando um iPhone tenta se conectar é a seguinte:

10[IKE] CLIENT_IPV4 is initiating an IKE_SA
10[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
10[CFG] configured proposals: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519
10[IKE] no matching proposal found, trying alternative config
10[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
10[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
10[IKE] no matching proposal found, trying alternative config
10[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
10[IKE] remote host is behind NAT
10[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
10[NET] sending packet: from PUBLIC_IPV4[500] to CLIENT_IPV4[6452] (456 bytes)
06[NET] received packet: from CLIENT_IPV4[13549] to PUBLIC_IPV4[4500] (512 bytes)
06[ENC] unknown attribute type INTERNAL_DNS_DOMAIN
06[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR MASK DHCP DNS ADDR6 DHCP6 DNS6 DOMAIN) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr N(MOBIKE_SUP) ]
06[CFG] looking for peer configs matching PUBLIC_IPV4[vpn.example.com]...CLIENT_IPV4[PRIVATE_CLASS_A_ADDRESS]
06[CFG] selected peer config 'conn-ios'
06[IKE] initiating EAP_IDENTITY method (id 0x00)
06[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
06[IKE] peer supports MOBIKE
06[IKE] authentication of 'vpn.example.com' (myself) with ECDSA-256 signature successful
06[IKE] sending end entity cert "CN=vpn.example.com"
06[IKE] sending issuer cert "C=US, O=Let's Encrypt, CN=R3"
06[ENC] generating IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
06[ENC] splitting IKE message (2816 bytes) into 3 fragments
06[ENC] generating IKE_AUTH response 1 [ EF(1/3) ]
06[ENC] generating IKE_AUTH response 1 [ EF(2/3) ]
06[ENC] generating IKE_AUTH response 1 [ EF(3/3) ]
06[NET] sending packet: from PUBLIC_IPV4[4500] to CLIENT_IPV4[13549] (1236 bytes)
06[NET] sending packet: from PUBLIC_IPV4[4500] to CLIENT_IPV4[13549] (1236 bytes)
06[NET] sending packet: from PUBLIC_IPV4[4500] to CLIENT_IPV4[13549] (500 bytes)
11[JOB] deleting half open IKE_SA with CLIENT_IPV4 after timeout

Os usuários do iPhone estão se conectando usando o cliente VPN integrado usando as seguintes configurações:

• Digite IKEv2

• Descrição: servidor VPN

• Servidor: vpn.example.com

• ID remoto: vpn.example.com

• Código local: BRANCO

• Autenticação de nome de usuário e senha.

• Nome de usuário: [email protected]

• Senha: ItIsASecret

Alguém sabe por que a conexão trava para usuários do iOS quando carrega o conn-iosperfil?

ATUALIZAÇÃO E temos decolagem! :-)

De acordo com o conselho do @ecdsa, mudei o certificado para um certificado RSA de 2048 bits.

Meu servidor Radius é chamado. A autenticação do usuário é bem-sucedida e o cliente obtém um endereço IP atribuído. Eu estou feliz. :-)

Minha configuração para conn-iosagora é:

  conn-ios : conn-defaults, eap-defaults {

    # Overriding defaults from 'conn-default'
    local {
      auth = pubkey
      certs = vpn-rsa.cer
      id = vpn.example.com
    }

    children {
      net {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha256
    }

    pools = IkeVPN-site-ipv4, IkeVPN-site-ipv6
    proposals = aes256-sha256-prfsha256-modp2048
  }

Todo o resto está como está na minha configuração inicial.

Meu servidor VPN strongswan está autenticando clientes VPN em um servidor Freeradius local.

Todos os logs de usuários são enviados por proxy para o servidor radius remoto, que valida os usuários em relação a um servidor Samba Active Directory.

No entanto, eu me deparei com um pouco de um problema.

A seção a seguir funciona para usuários do Android usando o cliente VPN Strongswan:

connections
{
  rw-eap {
    local_addrs = SERVER_PUBLIC_IPV4, SERVER_PUBLIC_IPV6

    local {
      auth = pubkey
      certs = example-ecdsa.cer
      id = vpn.example.com
    }
    remote-android {
      auth = eap-radius
      id = *@example.com
    }
  }
}

A saída de monitoramento do Freeradius revela coisas como:

(5) Received Access-Request Id 135 from 192.168.200.1:47851 to 192.168.200.1:1812 length 193
(5)   User-Name = "[email protected]"
(5)   NAS-Port-Type = Virtual
(5)   Service-Type = Framed-User
(5)   NAS-Port = 4
(5)   NAS-Port-Id = "rw-eap"
(5)   NAS-IP-Address = SERVER_PUBLIC_IPV4
(5)   Called-Station-Id = "SERVER_PUBLIC_IPV4[4500]"
(5)   Calling-Station-Id = "CLIENT_IPV4[3988]"

E o log do Strongswan dá:

06[IKE] IKE_SA rw-eap[6] established between SERVER_PUBLIC_IPV4[vpn.example.com]...CLIENT_IPV4[[email protected]]

No entanto, ao tentar se conectar ao servidor a partir de um cliente Windows, ele está praticamente morto, a menos que eu use a seguinte configuração no Strongswan:

connections
{
  rw-windows {
    local_addrs = SERVER_PUBLIC_IPV4, SERVER_PUBLIC_IPV6

    local {
      auth = pubkey
      certs = example-ecdsa.cer
      id = vpn.example.com
    }

    remote-windows {
      auth = eap-radius

      # Don't use *@example.com here - as windows does not pass username as id, 
      # so this config will not match in that case.
      id = %any
    }
  }
}

Usando essa configuração, posso pelo menos fazer com que o Strongswan inicie a autenticação Radius, mas não vou muito além disso.

A saída do Freeradius me dá coisas como:

(21) Received Access-Request Id 151 from 192.168.200.1:47851 to 192.168.200.1:1812 length 306
(21)   User-Name = "\300\250\000d"
(21)   NAS-Port-Type = Virtual
(21)   Service-Type = Framed-User
(21)   NAS-Port = 7
(21)   NAS-Port-Id = "rw-windows"
(21)   NAS-IP-Address = SERVER_PUBLIC_IPV4
(21)   Called-Station-Id = "SERVER_PUBLIC_IPV4[4500]"
(21)   Calling-Station-Id = "CLIENT_PUBLIC_IPV4[3989]"

E isso resulta na seguinte entrada no log do Strongswan:

06[CFG] looking for peer configs matching SERVER_PUBLIC_IPV4[%any]...CLIENT_PUBLIC_IPV4[CLIENT_PRIVATE_IPV4]

Isso me leva a algumas perguntas como:

• Primeiro: Por que o cliente VPN do Windows não passa o nome de usuário como seu ID, como o Strongswan faz?

• Segundo: Por que o nome de usuário é passado de Strongswan para Freeradius "\300\250\000d"?

Um pouco mais de depuração no cliente Windows:

O exemplo acima é gerado ao usar EAP-TTLS no lado do cliente com MS-CHAP v2.

Ao usar o MS-CHAP, o Freeradius é invocado com o nome de usuário correto, mas quando a solicitação é proxy, a autenticação do nome de usuário/senha falha.

Acho que o login do MS-CHAP precisa ser encapsulado ou algo assim, pois a codificação da solicitação de autenticação não é a mesma de quando os usuários do Android se conectam?

Estou tentando configurar um servidor proxy Freeradius que encaminha todas as solicitações para outro servidor Freeradius.

Para referência veja a imagem a seguir:

A razão para esta configuração é que eu quero que os usuários se conectem à LAN local via VPN, mas o site local não está acessível devido à implementação de NAT no ISP.

No entanto, sou capaz de fazer uma conexão VPN site2site da LAN local para o servidor VPN, portanto, quero que os usuários possam fazer uma conexão VPN com a rede local através do servidor VPN público, desde que sejam um usuário válido na rede local .

Eu tenho um servidor Freeradius em execução na LAN local que valida os usuários em um banco de dados - e essa parte está funcionando bem.

Configuração do lado do servidor VPN

Pelo que entendi a única coisa que preciso modificar no servidor é o arquivo proxy.conf.

Supondo que os nomes de usuário que fazem login na VPN estejam no formulário [email protected], eu só precisaria adicionar a seguinte entrada a proxy.conf:

realm example.com {
    type = radius
    secret = VeryS3cretPassw0rd

    authhost = local-radius.example.com:1812
    accthost = local-radius.example.com:1813

    nostrip
}

A nostripentrada garante que a solicitação com proxy não remova o @-postfix do nome de usuário.

Eu também precisaria adicionar o seguinte a /etc/hosts:

   # VPN Address of local-radius.example.com
 
   192.168.100.2   local-radius.example.com

Configuração do lado do servidor radius local

No servidor radius local eu preciso atualizar client.confpara que quaisquer consultas ao servidor radius local e originadas do endereço IP da VPN sejam permitidas. Como por exemplo esta entrada:

client vpn-net {

        # Allow requests originating from VPN subnet.

        ipaddr          = 192.168.100.0/24
        secret          = VeryS3cretPassw0rd
}

A execução do seguinte comando no servidor VPN funciona conforme o esperado:

radtest -t mschap [email protected] SecretPassword local-radius.example.com:1812 0 VeryS3cretPassw0rd

Recebo a seguinte resposta:

Sent Access-Request Id 108 from 0.0.0.0:47466 to 192.168.100.2:1812 length 148
        User-Name = "[email protected]"
        MS-CHAP-Password = "SecretPassword "
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 0
        Message-Authenticator = 0x00
        Cleartext-Password = "SecretPassword"
        MS-CHAP-Challenge = ....
        MS-CHAP-Response = ...
Received Access-Accept Id 108 from 192.168.100.2:1812 to 192.168.100.1:47466 length 84
        MS-CHAP-MPPE-Keys = ...
        MS-MPPE-Encryption-Policy = Encryption-Required
        MS-MPPE-Encryption-Types = 4

No entanto, a execução do seguinte comando no servidor VPN falha:

radtest -t mschap [email protected] SecretPassword localhost:18120 0 testing123

A saída do comando é:

Sent Access-Request Id 104 from 0.0.0.0:39558 to 127.0.0.1:18120 length 148
        User-Name = "[email protected]"
        MS-CHAP-Password = "SecretPassword"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 0
        Message-Authenticator = 0x00
        Cleartext-Password = "SecretPassword"
        MS-CHAP-Challenge = ...
        MS-CHAP-Response = ...
Received Access-Reject Id 104 from 127.0.0.1:18120 to 127.0.0.1:39558 length 20
(0) -: Expected Access-Accept got Access-Reject

A execução do comando freeradius -Xno servidor VPN fornece, entre outros, esta saída:

(0) mschap: Found MS-CHAP attributes.  Setting 'Auth-Type  = mschap'
(0)     [mschap] = ok
(0) suffix: Checking for suffix after "@"
(0) suffix: Looking up realm "example.com" for User-Name = "[email protected]"
(0) suffix: Found realm "example.com"
(0) suffix: Adding Realm = "example.com"
(0) suffix: Proxying request from user [email protected] to realm example.com
(0) suffix: Preparing to proxy authentication request to realm "example.com"
(0)     [suffix] = updated
(0) ntdomain: Request already has destination realm set.  Ignoring
(0)     [ntdomain] = noop
(0) eap: No EAP-Message, not doing EAP
(0)     [eap] = noop
(0)     [files] = noop
(0)     [expiration] = noop
(0)     [logintime] = noop
(0)     [pap] = noop
(0)   } # authorize = updated
(0) There was no response configured: rejecting request

Monitorar o freeradius na rede local indica que o servidor nunca foi chamado, do servidor vpn, então o que estou perdendo?

Estou tentando fazer um servidor DNS de cache/encaminhamento somente usando Bind9 com validação DNSSEC sendo habilitada por padrão.

Suponha que você tenha as seguintes informações do meu arquivo de configuração:

acl "home-net"
{
    127.0.0.1;
    ::1;
    192.168.1.0/24;
    2000:db8:cafe:100::/64;
};

options
{
    forwarders
    {
       # Use Google DNS either by IPv6 or IPv4 is fine.
       2001:4860:4860::8888;
       2001:4860:4860::8844;

       8.8.8.8;
       8.8.4.4;
    };

   dnssec-enable yes;
   dnssec-validation auto;

   allow-query { any; };
   allow-query-cache { home-net; };
   allow-recursion { home-net; };
};

zone "subdomain.example.net" {
    type forward;
    forward only;

    forwarders 
    { 
       # SAMBA PDC1 (Active Directory)
       2000:db8:cafe:100::1;
    
       # SAMBA PDC2 (Active Directory)
       2000:db8:cafe:100::2;    
    };
};

Pelo que entendi:

Sempre que eu quiser pesquisar um host registrado no subdomínio subdomain.example.net, o servidor de nomes entrará em contato com um dos dois PDC do SAMBA que listei na seção de encaminhadores na configuração da zona.

O servidor de nomes, por sua vez, faria a validação do DNSSEC para garantir que os dois PDCs do SAMBA estejam realmente autorizados a responder a solicitações ao domínio subdomain.example.net.

Se a resposta dos PDCs do SAMBA não puder ser validada por meio de DNSSEC, o servidor de nomes se voltará para o DNS do Google e perguntará se eles podem fornecer uma resposta validada por DNSSEC.

Agora, aqui está o problema:

Pelo que entendi, não há suporte a DNSSEC no SAMBA nem pelo uso do SAMBA INTERNAL_DNS ou pelo BIND9_DLZ, portanto, você não pode fazer a validação do DNSSEC em nenhuma zona mantida pelo SAMBA.

Pelo que entendi, existem 3 opções:

• Desabilite a validação DNSSEC globalmente.
• Use âncoras de confiança negativas.
• Use a opção 'validar-exceto'.

Eu vou lidar com eles um por um.

Desativar DNSSEC

Não é realmente uma opção no meu livro. Ele basicamente reduz sua configuração para "funciona em todo o mundo" ... exceto em um pequeno canto específico do mundo, então é melhor desativá-lo todos juntos.

Isso pode ser feito apenas alterando o valor de dnssec-enablee dnssec-validationpara no.

Vou usá-lo apenas como uma correção temporária até que eu possa ativar o DNSSEC novamente.

Use âncoras de confiança negativas

No início, meu interesse atingiu o pico. A ideia é você registrar uma chave criptografada especial rndce então ela não fará nenhuma validação DNSSEC para o domínio que você deseja.

No entanto, é uma correção temporária, pois a chave tem uma vida útil de no máximo uma semana .

Isso significa que você tem que fazer o mesmo tipo de fonte que os certificados do Let's Encrypt - só que o cron job precisa ser acionado com mais frequência.

Use a opção 'validate-except'

Em teoria, esta deve ser a solução mais fácil de todas.

Eu só tenho que adicionar uma nova seção ao optionschamado validate-except.

Igual a:

options
{

   dnssec-enable yes;
   dnssec-validation auto;

   validate-except
   {
       "subdomain.example.net";
       "another.example.net";
   };
};

Parece bastante simples - certo? :-)

... Exceto que meu servidor de nomes não foi iniciado devido a "opção desconhecida - validar exceto".

EDIT: Acontece que o Raspberry OS usa o Bind versão 9.11 enquanto a validate-exceptopção foi implementada apenas no Bind versão 9.13 .

Para referência, o Ubuntu 20.04 para Raspberry usa o Bind versão 9.16.

Então, alguém por aí tem experiência com uma configuração de modo misto em relação ao DNSSEC?

... ou a solução mais fácil seria admitir a falha e instalar o Ubuntu 20.04? :-)

Eu tenho um dispositivo executando o Samba como um controlador de domínio do Active Directory usando BIND_DLZ como back-end.

Além disso, estou executando um dispositivo secundário também configurado como um controlador de domínio do Active Directory também com BIND_DLZ como back-end para fins de redundância.

Os endereços IP são atribuídos pelo servidor DHCP ISC que pode atualizar os registros de recursos DNS usando uma chave de criptografia (TSIG).

De qualquer forma: para o meu problema.

Aqui está minha configuração atual

named.conf.options:

options 
{
     directory "/var/cache/bind";

     forwarders {
            2001:4860:4860::8888;
            2001:4860:4860::8844;
            8.8.8.8;
            8.8.4.4;
     };

     auth-nxdomain no;    # conform to RFC1035
     listen-on-v6 { any; };

     listen-on port 53 { 192.168.1.240; };
     listen-on port 5353 { 127.0.0.1; }; <-- Used for Netflix IPv6 filter only.

     tkey-gssapi-keytab "/var/lib/samba/bind-dns/dns.keytab";
     minimal-responses yes;
     recursion yes;
};

acl "home-net"
{
    127.0.0.1;
    192.168.1.0/24;
    2001:db8:cafe:beef::/56; # <-- I am using a IPv6 range from Tunnelbroker in real life.
};

view "normal"
{
    include "/etc/bind/named.conf.default-zones";
    include "/etc/bind/named.conf.internal";

    # Netflix really dislike Tunnelbroker IPv6, so I am dropping any Netflix AAAA ressources records.
    include "/etc/bind/netflix-ipv6-blackhole.conf";  

    match-clients
    {
        home-net; # <-- Only respond to queries originating from my own network.
    };

    dnssec-enable yes;
    dnssec-validation auto;

    allow-query { any; };
    allow-query-cache { home-net; };
    allow-recursion { home-net; };

    forwarders {
      8.8.8.8;
      8.8.4.4;
      2001:4860:4860::8888;
      2001:4860:4860::8844;
   };
};

nomeado.conf.internal:

zone "1.168.192.in-addr.arpa"
{
    type master;
    file "/etc/bind/db.192.168.1.rev";
    notify yes;

    allow-query { any; };
    allow-transfer { xfer; };

    # If allow-update is enabled instead of the include named.conf.update line, 
    # then Dynamic DNS works fine due to ISC DHCP can update the ressource records. 
    #
    # Sadly you can't have both lines enabled. It is either / or.

    // allow-update { key ddns-key; };

    include "/var/lib/samba/bind-dns/named.conf.update"; # <-- Having issues with THIS line only.
};

include "/var/lib/samba/bind-dns/named.conf";

/var/lib/samba/bind-dns/named.conf:

dlz "AD DNS Zone" {
    # For BIND 9.11.x
    database "dlopen /usr/lib/arm-linux-gnueabihf/samba/bind9/dlz_bind9_11.so";
};

/var/lib/samba/bind-dns/named.conf.update:

/* this file is auto-generated - do not edit */
update-policy {
        grant EXAMPLE.COM ms-self * A AAAA;
        grant [email protected] wildcard * A AAAA SRV CNAME;

        # Main Active Directory Domain Controller
        grant [email protected] wildcard * A AAAA SRV CNAME;

        # Backup Active Directory Domain Controller
        grant [email protected] wildcard * A AAAA SRV CNAME;
};

Se eu tentar iniciar o bind com esta configuração, obterei um erro bastante estranho que não consigo descobrir:

/var/lib/samba/bind-dns/named.conf.update:3: name field not set to placeholder value '.'

Existe alguém que possa me dar uma pista sobre o que está errado com o named.conf.update?

Estou tentando depurar minha rede IPv6 e me deparei com um problema que não consigo entender.

Estou usando o OpenVPN como meu servidor VPN e aqui está um pequeno diagrama da configuração:

Todos os pacotes são descartados, quando tento fazer ping do VPN Client ( 2001:470:7875:1::2) para o VPN Server ( 2001:470:7875:1::1), mas aqui está o curioso:

Posso pingar qualquer outro host em IPv6 (como o Google) ou qualquer outro cliente VPN conectado ao mesmo servidor VPN em IPv6.

Também posso pingar meu servidor VPN em sua interface IPv6 nativa ( ens3). É apenas a interface do servidor VPN ( tun0) que não responde quando pingado diretamente.

Por isso estou me perguntando o que está acontecendo?

Como tenho dois links IPv6 para a versão IPv6 da internet, tenho roteamento baseado em política de tarefas. As regras são bem simples.

• Somente pacotes IPv6 originados do próprio servidor VPN podem ser enviados pelo link IPv6 nativo.
• Todos os outros pacotes IPv6 devem ser tratados pelo túnel Hurricane Electric IPv6.

Isso me leva à seguinte tabela de roteamento no servidor VPN:

O comando ip -6 rule showtem a seguinte configuração:

0:      from all lookup local
32000:  from 2001:470:7875::/48 lookup openvpn
32766:  from all lookup main

Tabela local:

local ::1 dev lo proto kernel metric 0 pref medium
anycast 2001:470:1f14:2c7:: dev he-ipv6 proto kernel metric 0 pref medium
local 2001:470:1f14:2c7::2 dev he-ipv6 proto kernel metric 0 pref medium
anycast 2001:470:7875:1:: dev tun0 proto kernel metric 0 pref medium
local 2001:470:7875:1::1 dev tun0 proto kernel metric 0 pref medium
anycast 2a01:xxx:xxxx:: dev ens3 proto kernel metric 0 pref medium
local 2a01:xxx:xxxx:xxx::1 dev ens3 proto kernel metric 0 pref medium
anycast fe80:: dev ens3 proto kernel metric 0 pref medium
anycast fe80:: dev tun0 proto kernel metric 0 pref medium
anycast fe80:: dev he-ipv6 proto kernel metric 0 pref medium
local fe80::95d2:9e6b dev he-ipv6 proto kernel metric 0 pref medium
local fe80::5054:ff:fe66:f97f dev ens3 proto kernel metric 0 pref medium
local fe80::af96:f1e3:dbf3:96a7 dev tun0 proto kernel metric 0 pref medium
ff00::/8 dev ens3 metric 256 pref medium
ff00::/8 dev tun0 metric 256 pref medium
ff00::/8 dev he-ipv6 metric 256 pref medium

Tabela main:

local ::1 dev lo proto kernel metric 256 pref medium
2001:470:1f14:2c7::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:470:7875:1::/64 dev tun0 proto kernel metric 256 pref medium
unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium
2xxx:xxx:xxxx::/48 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev he-ipv6 proto kernel metric 256 pref medium
default via 2a01:xxx:xxxx::1 dev ens3 metric 1024 pref medium

Tabela openvpn:

unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium
default via 2001:470:1f14:2c7::1 dev he-ipv6 metric 1024 pref medium

Tem alguém que possa me dar uma dica? :-)

Uma rápida recapitulação das linhas inacessíveis na tabela de roteamento

2001:470:1f14:2c7::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:470:7875:1::/64 dev tun0 proto kernel metric 256 pref medium
unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium

O intervalo de 2001:470:7875::/48é de 2001:470:7875:0:0:0:0:0a 2001:470:7875:ffff:ffff:ffff:ffff:ffff.

Eu atribuí a sub -rede 2001:470:7875:1::/64ao túnel VPN.

• 2001:470:7875:1::/64faz parte da 2001:470:7875::/48sub-rede, o que pode levar a um conflito na tabela de roteamento.
• 2001:470:1f14:2c7::/64não faz parte da 2001:470:7875::/48sub-rede e, portanto, não entra em conflito com a tabela de roteamento.

Nenhum outro intervalo de IP está em uso, mas estará em uma data posterior indeterminada.

Tendo em mente que as vitórias de prefixo mais longas nos dá o seguinte comportamento:

• Quaisquer pacotes IP para 2001:470:1f14:2c7::/64sub-rede serão tratados pela interface he-ipv6.
• Quaisquer pacotes IP para 2001:470:7875:1::/64sub-rede serão tratados pela interface tun0.
• Todos os outros pacotes de IP para a sub-rede 2001:470:7875::/48 serão respondidos com inacessível.

Estou meio que me encarando cego em como fazer o ActiveSync funcionar corretamente com meu servidor de e-mail, então talvez alguém aqui tenha uma ideia?

O negócio é que o servidor de e-mail está hospedando quatro domínios e eu quero que todos os e-mails enviados tenham assinatura DKIM.

Consegui que funcione ao enviar via SMTP, mas falha na assinatura quando o cliente usa o ActiveSync para enviar o email.

De qualquer forma, aqui está um diagrama de como funciona para o SMTP:

A maior parte da mágica em como o Postfix decide como identificar e-mails enviados de um usuário autenticado, que pertence a um dos meus domínios hospedados versus um e-mail de algum lugar na Internet vem desta linha em /etc/postfix/main.cf:

smtpd_sender_restrictions = 
    check_sender_access regexp:/etc/postfix/tag_as_originating.re, 
    permit_mynetworks, 
    permit_sasl_authenticated, 
    check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf, 
    check_sender_access regexp:/etc/postfix/tag_as_foreign.re

content_filter = amavis:[127.0.0.1]:10024

O conteúdo de /etc/postfix/tag_as_foreign.re:

/^/ FILTER amavis:[127.0.0.1]:10024

Amavis enviou o resultado de volta ao Postfix usando a porta 10025 que é tratada /etc/postfix/master.cfcom esta configuração:

127.0.0.1:10025 inet n - n - - smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks, reject
    -o mynetworks=127.0.0.0/8
    -o strict_rfc821_envelopes=yes
    -o receive_override_options=no_unknown_recipient_checks, no_header_body_checks
    -o smtp_send_xforward_command=yes
    -o disable_dns_lookups=yes

O conteúdo de /etc/postfix/tag_as_originating.re:

/^/ FILTER amavis:[127.0.0.1]:10026

O resultado é enviado de volta ao Postfix usando a porta 10027 e tratado por este código em /etc/postfix/master.cf:

127.0.0.1:10027 inet n - n - - smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks, reject
    -o mynetworks=127.0.0.0/8
    -o strict_rfc821_envelopes=yes
    -o receive_override_options=no_unknown_recipient_checks, no_header_body_checks
    -o smtp_send_xforward_command=yes
    -o milter_default_action=accept
    -o milter_macro_daemon_name=ORIGINATING
    -o disable_dns_lookups=yes

Finalmente, aqui estão as linhas relevantes master.cfsobre como os e-mails são apresentados ao Postfix em primeiro lugar:

smtp      inet  n       -       y       -       -       smtpd

pickup    unix  n       -       y       60      1       pickup

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated, reject

smtps     inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated, reject

Estou usando Z-pushpara lidar com conexões via ActiveSync, mas meu problema é o seguinte:

Eu notei no mail.log que, embora declarado nos arquivos de configuração do z-push que ele deve passar os e-mails de entrada para o postfix via SMTP, ele ainda insiste em colocar os e-mails de entrada diretamente no diretório maildrop que, por sua vez, é tratado pelo deamon de coleta do Postfix.

A partir daí, o correio é encaminhado diretamente para o endereço de destino, mesmo sem ser DKIM assinado pela Amavis.

A questão é: Como posso fazer com que o Postfix passe e-mails do daemon de coleta para o Amavis, para que ele possa obter uma assinatura DKIM, antes de ser encaminhado ao destino?

É tão simples como apenas inserir uma linha abaixo pickupcom master.cfo texto:

-o content_filter = amavis:[127.0.0.1]:10026

... ou o conflito com a configuração já existente? :-)