Jake's questions

Eu criei um par de dispositivos veth da seguinte forma no Ubuntu 16.04:

$ sudo ip link add veth1 type veth peer name veth2
$ sudo ip link set dev veth1 up
$ sudo ip link set dev veth2 up
$ sudo ip address add 10.0.10.50/24 dev veth1
$ sudo ip address add 10.0.10.51/24 dev veth2

O par de dispositivos veth está no mesmo namespace. Estou tentando testar o ping de um dispositivo veth para o outro. Então eu tento o ping da seguinte forma:

$ ping -I veth1 10.0.10.51
PING 10.0.10.51 (10.0.10.51) from 10.0.10.50 veth1: 56(84) bytes of data.
From 10.0.10.50 icmp_seq=1 Destination Host Unreachable
From 10.0.10.50 icmp_seq=2 Destination Host Unreachable
From 10.0.10.50 icmp_seq=3 Destination Host Unreachable

Quando eu faço check in wireshark trace para veth2, a solicitação ARP não obtém nenhuma resposta (trace semelhante também é observado para veth1):

 Broadcast  ARP 42  Who has 10.0.10.51? Tell 10.0.10.50

Eu quero perguntar por que veth2 não pode responder à solicitação ICMP quando está no mesmo namespace que veth1 ?

Atualização : Se eu tentar o ping da seguinte forma, recebo uma resposta ICMP, mas o wireshark não mostra nenhum rastreamento para os dispositivos veth1 e veth2.

 $ ping -I 10.0.10.50 10.0.10.51
 PING 10.0.10.51 (10.0.10.51) from 10.0.10.50 : 56(84) bytes of data.
 64 bytes from 10.0.10.51: icmp_seq=1 ttl=64 time=0.016 ms
 64 bytes from 10.0.10.51: icmp_seq=2 ttl=64 time=0.022 ms

Alguém pode explicar a diferença de resultado para os dois testes de ping?

Eu quero entender as mensagens do netlink trocadas com o kernel quando executo o seguinte comando para criar um par de dispositivos veth (estou usando Ubuntu 16.04):

$ sudo ip link add veth1 type veth peer name veth2

Tentei seguir o tutorial neste link . Usei strace e obtive o seguinte trace relacionado ao netlink:

$ sudo strace -e trace=network -x -s 16384 -f -o out ip link add veth1 type veth peer name veth2
$ cat out 
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=6001, groups=00000000}, [12]) = 0
send(3, "\x20\x00\x00\x00\x10\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 32, 0) = 32
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\x34\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\x71\x17\x00\x00\xed\xff\xff\xff\x20\x00\x00\x00\x10\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 16384}], msg_controllen=0, msg_flags=0}, 0) = 52
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4
sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\x5c\x00\x00\x00\x10\x00\x05\x06\x38\xa2\x16\x5d\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0a\x00\x03\x00\x76\x65\x74\x68\x31\x00\x00\x00\x30\x00\x12\x00\x08\x00\x01\x00\x76\x65\x74\x68\x24\x00\x02\x00\x20\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0a\x00\x03\x00\x76\x65\x74\x68\x32\x00\x00\x00", 92}], msg_controllen=0, msg_flags=0}, 0) = 92
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\x24\x00\x00\x00\x02\x00\x00\x00\x38\xa2\x16\x5d\x71\x17\x00\x00\x00\x00\x00\x00\x5c\x00\x00\x00\x10\x00\x05\x06\x38\xa2\x16\x5d\x00\x00\x00\x00", 32768}], msg_controllen=0, msg_flags=0}, 0) = 36

Por exemplo, tento decodificar as mensagens relacionadas ao envio.

// my test did not have any line breaks
$ echo'\x20\x00\x00\x00\x10\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00' >> message
$ python tests/decoder/decoder.py pyroute2.netlink.rtnl.rtmsg.rtmsg message
20:00:00:00:10:00:05:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
:00:00:00:00:00:00:00:00:00:00
{'attrs': [('RTA_UNSPEC', None)],
 'dst_len': 0,
 'family': 0,
 'flags': 0,
 'header': {'flags': 5,
            'length': 32,
            'pid': 0,
            'sequence_number': 0,
            'type': 16},
 'proto': 0,
 'scope': 0,
 'src_len': 0,
 'table': 0,
 'tos': 0,
 'type': 0}
........................................ 

$ echo '\x5c\x00\x00\x00\x10\x00\x05\x06\x38\xa2\x16\x5d\x00\x00
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x0a\x00\x03\x00\x76\x65\x74\x68\x31\x00\x00\x00\x30\x00
\x12\x00\x08\x00\x01\x00\x76\x65\x74\x68\x24\x00\x02\x00\x20\x00
\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x0a\x00\x03\x00\x76\x65\x74\x68\x32\x00\x00\x00' >> 
message

 $ python tests/decoder/decoder.py pyroute2.netlink.rtnl.rtmsg.rtmsg message
 5c:00:00:00:10:00:05:06:38:a2:16:5d:00:00:00:00:00:00:00:00:00:00:
 00:00:00:00:00:00:00:00:00:00:0a:00:03:00:76:65:74:68:31:00:00:00:
 30:00:12:00:08:00:01:00:76:65:74:68:24:00:02:00:20:00:01:00:00:00:
 00:00:00:00:00:00:00:00:00:00:00:00:00:00:0a:00:03:00:76:65:74:68:
 32:00:00:00
 {'attrs': [('RTA_UNSPEC', None),
           ('RTA_IIF', 1752458614),
           ('RTA_VIA', {'addr': 
 '01:00:76:65:74:68:24:00:02:00:20:00:01:00:00:00:00:00:00:00:00:
  00:00:00:00:00:00:00:00:00:0a:00:03:00:76:65:74:68:32:00:00:00', 
 'family': 8})],
 'dst_len': 0,
 'family': 0,
 'flags': 0,
 'header': {'flags': 1541,
        'length': 92,
        'pid': 0,
        'sequence_number': 1561764408,
        'type': 16},
 'proto': 0,
 'scope': 0,
 'src_len': 0,
 'table': 0,
 'tos': 0,
 'type': 0}

Eu esperava que a decodificação indicasse algo sobre veth1ou veth2, mas a decodificação não parece se correlacionar com os dispositivos veth. Eu repeti a decodificação em um tutorial relacionado e consegui o mesmo resultado que no tutorial. Eu quero perguntar se a decodificação acima está correta e, em caso afirmativo, como ela pode ser interpretada?

Eu tenho as seguintes regras de roteamento (exibidas usando route -n):

Kernel IP routing table
Destination  Gateway    Genmask         Flags Metric Ref Use Iface
0.0.0.0      10.0.2.1   0.0.0.0         UG    100    0     0 enp0s3
10.0.2.0     0.0.0.0    255.255.255.192 U     100    0     0 enp0s3.100
10.0.2.0     0.0.0.0    255.255.255.0   U     100    0     0 enp0s3
169.254.0.0  0.0.0.0    255.255.0.0     U     1000   0     0 enp0s3

A interface enp0s3.100é uma interface com ID de VLAN 100.

Se eu tentar obter a rota para 10.0.2.70, espero que use a interface VLAN, mas não:

# ip route get 10.0.2.70
10.0.2.70 dev enp0s3  src 10.0.2.11 
    cache

Alguém sabe por que a correspondência de prefixo mais longa não está sendo usada aqui?

Estou verificando os namespaces associados a um processo de shell da seguinte maneira:

# ll /proc/$$/ns
total 0
dr-x--x--x 2 root root 0 May  2 15:10 ./
dr-xr-xr-x 9 root root 0 May  1 18:39 ../
lrwxrwxrwx 1 root root 0 May  2 15:11 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 root root 0 May  2 15:11 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 root root 0 May  2 15:11 mnt -> mnt:[4026531840]
lrwxrwxrwx 1 root root 0 May  2 15:11 net -> net:[4026531957]
lrwxrwxrwx 1 root root 0 May  2 15:11 pid -> pid:[4026531836]
lrwxrwxrwx 1 root root 0 May  2 15:11 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 May  2 15:11 uts -> uts:[4026531838]

Eu entendo que as entradas indicam a quais namespaces um processo está associado. Eu quero perguntar de onde vêm os números, identificando cada namespace?

Por exemplo, a saída acima indica que o namespace de montagem do processo é mnt:[4026531840]. Eu verifiquei a estrutura do namespace de montagem :

 8  struct mnt_namespace {
 9      atomic_t        count;
10      struct ns_common    ns;
11      struct mount *  root;
12      struct list_head    list;
13      struct user_namespace   *user_ns;
14      struct ucounts      *ucounts;
15      u64         seq;    /* Sequence number to prevent loops */
16      wait_queue_head_t poll;
17      u64 event;
18      unsigned int        mounts; /* # of mounts in the namespace */
19      unsigned int        pending_mounts;
20  } __randomize_layout;

Não vejo um campo que sirva como identificador a ser usado nas /proc/PID/ns/entradas. Então, como esses identificadores são gerados?

Inspecionei os links simbólicos em uma VM do Ubuntu para os diretórios relacionados ao namespace em /proc/PID/ns. Vejo que todos os links estão na cor vermelha.

Eu até tentei testar usando unsharepara ver se consigo criar um novo namespace. Eu testei usando mount namespace e um novo namespace é atribuído ao novo processo.

root@VM:/# ll /proc/$$/ns
total 0
dr-x--x--x 2 root root 0 Apr 21 01:56 ./
dr-xr-xr-x 9 root root 0 Apr 21 01:56 ../
lrwxrwxrwx 1 root root 0 Apr 21 01:56 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 root root 0 Apr 21 01:56 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 root root 0 Apr 21 01:56 ** mnt -> mnt:[4026531840] **
lrwxrwxrwx 1 root root 0 Apr 21 01:56 net -> net:[4026531957]
lrwxrwxrwx 1 root root 0 Apr 21 01:56 pid -> pid:[4026531836]
lrwxrwxrwx 1 root root 0 Apr 21 01:56 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Apr 21 01:56 uts -> uts:[4026531838]
root@VM:/# 
root@VM:/# unshare --mount
root@VM:/# 
root@VM:/# ll /proc/$$/ns
total 0
dr-x--x--x 2 root root 0 Apr 21 01:56 ./
dr-xr-xr-x 9 root root 0 Apr 21 01:56 ../
lrwxrwxrwx 1 root root 0 Apr 21 01:56 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 root root 0 Apr 21 01:56 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 root root 0 Apr 21 01:56 ** mnt -> mnt:[4026532226] **
lrwxrwxrwx 1 root root 0 Apr 21 01:56 net -> net:[4026531957]
lrwxrwxrwx 1 root root 0 Apr 21 01:56 pid -> pid:[4026531836]
lrwxrwxrwx 1 root root 0 Apr 21 01:56 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Apr 21 01:56 uts -> uts:[4026531838]

Alguém pode dizer por que os links simbólicos estão em vermelho? Isso significa que o recurso de namespace não está funcionando?

Estou tentando experimentar o namespace de montagem no Ubuntu. Até agora, posso criar um namespace de montagem vazio usando o seguinte:

# mkdir test
# unshare --mount
# mount none test -t tmpfs
# cd test
# pivot_root . . 
# cd / <--- test becomes /

Quando verifico um LXCcontêiner do Ubuntu, o mountcomando exibe o seguinte:

Como o namespace mount inicialmente obtém uma cópia dos pontos de montagem, presumo que o /dev/sda1interior do contêiner seja o global /dev/sda1(porque não há /dev/sda1dentro do contêiner uma vez iniciado), e ainda assim o conteúdo do /interior do contêiner corresponde ao seu rootfs. Alguém familiarizado com o LXC pode explicar quais operações de montagem o LXC faz antes de fazer pivot_rootdentro do contêiner?

Estou tentando testar o unsharecomando no Linux. Estou usando-o para criar um novo namespace de usuário. Tentei o seguinte teste:

user1@myPC$ strace -e clone,unshare,fork,execve unshare --user
execve("/usr/bin/unshare", ["unshare", "--user"], [/* 71 vars */]) = 0
unshare(CLONE_NEWUSER)                  = 0
execve("/bin/bash", ["-bash"], [/* 71 vars */]) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7275768) = 9153
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9153, si_uid=65534, si_status=0, si_utime=0, si_stime=0} ---
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7275768) = 9155
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9155, si_uid=65534, si_status=0, si_utime=0, si_stime=0} ---
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7275768) = 9160
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9160, si_uid=65534, si_status=0, si_utime=0, si_stime=0} ---
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7275768) = 9162
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9162, si_uid=65534, si_status=0, si_utime=0, si_stime=0} ---
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7275768) = 9164
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9164, si_uid=65534, si_status=0, si_utime=0, si_stime=0} ---
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7275768) = 9167
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9167, si_uid=65534, si_status=0, si_utime=0, si_stime=0} ---
nobody@MyPC:~$

Eu quero perguntar por que há tantas chamadas a serem clone()feitas?

Estou tentando experimentar com DNAT em PREROUTING. Achei um tutorial aqui . Contém a seguinte frase:

Isso é feito na cadeia PREROUTING, assim que o pacote chega; isso significa que qualquer outra coisa na própria caixa do Linux (roteamento, filtragem de pacotes) verá o pacote indo para seu destino 'real'.

Eu quero perguntar o que o autor quer dizer com a última parte ou seja anything else on the Linux box itself will see the packet going to its 'real' destination?

Eu tentei um teste em que tenho um dispositivo virtual (tap) e redirecionei os pacotes ICMP de entrada para esse dispositivo de toque (meu endereço de dispositivo de toque é 10.0.4.1/24e há um programa ouvindo o dispositivo de toque, então seu estado é UP):

# iptables -t nat -A PREROUTING -i eth0 -p icmp -j DNAT --to-destination 10.0.4.2

Quando faço ping em um IP externo, essa regra nunca é usada ( pktscontagem em iptables permanece 0 para esta regra). Esta observação está relacionada com o que o autor está dizendo?

Estou tentando encontrar o motivo correto para a pergunta feita. Meu entendimento é que:

• sudoprecisa ler o /etc/sudoersarquivo que só pode ser lido pelo root, e é por isso que ele precisa ser definido como root UID
• suvai criar um novo shell com um UID real e efetivo diferente e precisa verificar a senha. Para verificar a senha, ele precisa ler /etc/shadow, e é por isso que ele precisa ser definido como root UID. Depois de verificar a senha, ele precisaria chamar setuid()o processo bifurcado e, para usar um argumento UID arbitrário, seu processo pai deve ter root como UID efetivo, então isso também é outro motivo.

As razões acima estão corretas?