Início / user-321907

Younes's questions

Martin Hope
Younes
Asked: 2023-06-22 13:06:51 +0800 CST
  • 5

Estou configurando uma VLAN na nuvem onde vários servidores irão se conectar a um host remoto via VPN. A configuração é a seguinte:


           Their Host d.d.d.72
                     |
                     |
                     |
       Their VPN Public IP b.b.b.116
                     |
                     |
                  Internet
                     |
                     |
        Our VPN Public IP a.a.a.101
                     |
         Our VPN Local IP s.s.s.31
                     |
  Our VLAN ----------+-----------+-------------------+--------...--------+--
                                 |                   |                   |
                             s.s.s.111           s.s.s.112    ...    s.s.s.nnn
                                 |                   |                   |
                                UAT1                UAT2      ...       UATn

strongswané usado por Our VPNe o objetivo é permitir UAT1que UATnos hosts Our VLANse conectem Their Hostusando um soquete TCP bruto.

SYNos pacotes são enviados de UAT2e alcançam Their Hostquais respostas com SYN ACK. SYN ACKsão recebidos por Our VPNe encaminhados para UAT2. O PROBLEMA É que SYN ACKnão são recebidos por UAT2!

Aqui estão os logs do tcpdump UAT2:

root@uat2:~# tcpdump -ttnnvvS -i any host d.d.d.72
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
1687385350.426771 ens7  Out IP (tos 0x10, ttl 64, id 38370, offset 0, flags [DF], proto TCP (6), length 60)
    s.s.s.112.54838 > d.d.d.72.9990: Flags [S], cksum 0x324d (incorrect -> 0x3ba1), seq 4126082045, win 62720, options [mss 8960,sackOK,TS val 4002865714 ecr 0,nop,wscale 7], length 0
1687385351.445963 ens7  Out IP (tos 0x10, ttl 64, id 38371, offset 0, flags [DF], proto TCP (6), length 60)
    s.s.s.112.54838 > d.d.d.72.9990: Flags [S], cksum 0x324d (incorrect -> 0x37a6), seq 4126082045, win 62720, options [mss 8960,sackOK,TS val 4002866733 ecr 0,nop,wscale 7], length 0
1687385353.461982 ens7  Out IP (tos 0x10, ttl 64, id 38372, offset 0, flags [DF], proto TCP (6), length 60)
    s.s.s.112.54838 > d.d.d.72.9990: Flags [S], cksum 0x324d (incorrect -> 0x2fc6), seq 4126082045, win 62720, options [mss 8960,sackOK,TS val 4002868749 ecr 0,nop,wscale 7], length 0

Aqui estão os logs do tcpdump Our VPN:

root@vpn1:~# tcpdump -ttnnvvS -i any host d.d.d.72
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
1687385350.426647 ens4  In  IP (tos 0x10, ttl 64, id 38370, offset 0, flags [DF], proto TCP (6), length 60)
    s.s.s.112.54838 > d.d.d.72.9990: Flags [S], cksum 0x3ba1 (correct), seq 4126082045, win 62720, options [mss 8960,sackOK,TS val 4002865714 ecr 0,nop,wscale 7], length 0
1687385350.468411 ens3  In  IP (tos 0x0, ttl 57, id 11319, offset 0, flags [DF], proto TCP (6), length 60)
    d.d.d.72.9990 > s.s.s.112.54838: Flags [S.], cksum 0x94f0 (correct), seq 1695227873, ack 4126082046, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 1699598776 ecr 4002865714], length 0
1687385350.469803 ens4  Out IP (tos 0x0, ttl 56, id 11319, offset 0, flags [DF], proto TCP (6), length 60)
    d.d.d.72.9990 > s.s.s.112.54838: Flags [S.], cksum 0x94f0 (correct), seq 1695227873, ack 4126082046, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 1699598776 ecr 4002865714], length 0
1687385351.445122 ens4  In  IP (tos 0x10, ttl 64, id 38371, offset 0, flags [DF], proto TCP (6), length 60)
    s.s.s.112.54838 > d.d.d.72.9990: Flags [S], cksum 0x37a6 (correct), seq 4126082045, win 62720, options [mss 8960,sackOK,TS val 4002866733 ecr 0,nop,wscale 7], length 0
1687385351.484746 ens3  In  IP (tos 0x0, ttl 57, id 11635, offset 0, flags [DF], proto TCP (6), length 60)
    d.d.d.72.9990 > s.s.s.112.54838: Flags [S.], cksum 0x90f3 (correct), seq 1695227873, ack 4126082046, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 1699598778 ecr 4002866733], length 0
1687385351.484783 ens4  Out IP (tos 0x0, ttl 56, id 11635, offset 0, flags [DF], proto TCP (6), length 60)
    d.d.d.72.9990 > s.s.s.112.54838: Flags [S.], cksum 0x90f3 (correct), seq 1695227873, ack 4126082046, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 1699598778 ecr 4002866733], length 0
1687385353.461170 ens4  In  IP (tos 0x10, ttl 64, id 38372, offset 0, flags [DF], proto TCP (6), length 60)
    s.s.s.112.54838 > d.d.d.72.9990: Flags [S], cksum 0x2fc6 (correct), seq 4126082045, win 62720, options [mss 8960,sackOK,TS val 4002868749 ecr 0,nop,wscale 7], length 0
1687385354.421463 ens3  In  IP (tos 0x0, ttl 57, id 13219, offset 0, flags [DF], proto TCP (6), length 60)
    d.d.d.72.9990 > s.s.s.112.54838: Flags [S.], cksum 0x90ee (correct), seq 1695227873, ack 4126082046, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 1699598783 ecr 4002866733], length 0
1687385354.421495 ens4  Out IP (tos 0x0, ttl 56, id 13219, offset 0, flags [DF], proto TCP (6), length 60)
    d.d.d.72.9990 > s.s.s.112.54838: Flags [S.], cksum 0x90ee (correct), seq 1695227873, ack 4126082046, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 1699598783 ecr 4002866733], length 0
1687385359.466543 ens3  In  IP (tos 0x10, ttl 253, id 37551, offset 0, flags [DF], proto TCP (6), length 40)
    d.d.d.72.9990 > s.s.s.112.54838: Flags [R.], cksum 0x019a (correct), seq 1695227874, ack 4126082046, win 0, length 0
1687385359.466573 ens4  Out IP (tos 0x10, ttl 252, id 37551, offset 0, flags [DF], proto TCP (6), length 40)
    d.d.d.72.9990 > s.s.s.112.54838: Flags [R.], cksum 0x019a (correct), seq 1695227874, ack 4126082046, win 0, length 0

Como você pode ver:

  • UAT2enviou SYNcomid 38370
  • Esse pacote foi recebido por Our VPNquem o encaminhou paraTheir Host
  • Their Hostrespondeu com SYN ACKcomid 11319
  • Esse pacote foi recebido por Our VPNquem o encaminhou paraUAT2
  • O PROBLEMA É: UAT2não recebiSYN ACK

Alguma ideia de como investigar esse problema?

Durante o teste acima:

  • Our VPN, UAT1para UATntodas as Debian 11VMs na nuvem

  • iptablesem UAT2estava vazio:

    root@uat2:~# iptables -L -v --line-numbers
Chain INPUT (policy ACCEPT 65 packets, 26451 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 64 packets, 26539 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
root@uat2:~# telnet d.d.d.72 9990
Trying d.d.d.72...
^C

  • Uma rota estática foi definida dentro UAT2para alcançarTheir Host

  • Para Our VPN, ip_forwardé ativado:

    net.ipv4.ip_forward = 1

  • O túnel ipsec está bem estabelecido:

    root@vpn1:~# ipsec status
Security Associations (1 up, 0 connecting):
our_conn[2]: ESTABLISHED 24 minutes ago, a.a.a.101[a.a.a.101]...b.b.b.116[b.b.b.116]
our_conn{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c38c258f_i c727e8a0_o
our_conn{2}:   s.s.s.0/24 === d.d.d.72/32
root@vpn1:~#

  • Our VPNpings com sucessoUAT2

firewall
Martin Hope
Younes
Asked: 2020-11-12 06:06:37 +0800 CST
  • 9

Eu tenho dois segmentos de rede conectados usando um túnel IPSEC-VPN:

  • NET#1: ab0.0/16 com gateway LAN ab0.1
  • NET#2: xy0.0/16 com gateway LAN xy130.1

Eu inicio um ping de ab0.1 para xy130.100 e iniciei um tcpdump. Mais tarde, isso mostra os pacotes de respostas de eco, mas não mostra os pacotes de solicitação de eco.

Isso é normal? Como posso obter os pacotes de solicitação de eco também?

Aqui está um exemplo de sessão de testes:

O PING:

# ping x.y.130.100
PING x.y.130.100 56(84) bytes of data.
64 bytes from x.y.130.100: icmp_seq=1 ttl=63 time=1.87 ms
64 bytes from x.y.130.100: icmp_seq=2 ttl=63 time=1.38 ms
64 bytes from x.y.130.100: icmp_seq=3 ttl=63 time=1.27 ms
64 bytes from x.y.130.100: icmp_seq=4 ttl=63 time=3.93 ms
64 bytes from x.y.130.100: icmp_seq=5 ttl=63 time=1.15 ms
64 bytes from x.y.130.100: icmp_seq=6 ttl=63 time=1.16 ms

O TCPDUMP:

# tcpdump -nn 'icmp and (src a.b.0.1 or dst a.b.0.1)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:54:27.607103 IP x.y.130.100 > a.b.0.1: ICMP echo reply, id 22607, seq 1, length 64
13:54:28.608433 IP x.y.130.100 > a.b.0.1: ICMP echo reply, id 22607, seq 2, length 64
13:54:29.610167 IP x.y.130.100 > a.b.0.1: ICMP echo reply, id 22607, seq 3, length 64
13:54:30.614716 IP x.y.130.100 > a.b.0.1: ICMP echo reply, id 22607, seq 4, length 64
13:54:31.613417 IP x.y.130.100 > a.b.0.1: ICMP echo reply, id 22607, seq 5, length 64
13:54:32.615054 IP x.y.130.100 > a.b.0.1: ICMP echo reply, id 22607, seq 6, length 64
ping tcpdump