TCP syn, ack Lost перед входом в IPsec VPN-туннель
Я настроил VPN на сайт, который работает нормально, так как трафик проходит через туннель. Я могу пропинговать и Telnet-хосты в другой сети, и они могут пинговать меня обратно.
У меня проблема в том, что, когда узлы в другой сети отправляют HTTP-запросы приложению на веб-сервере (на самом деле это приложение для доставки USSD-меню обратно абоненту мобильной связи. Другие узлы - это серверы от поставщика мобильной сети), Я могу запросы и рукопожатие запускается с SYN от других хостов! Мой сервер отвечает SYN, ACK, но, к удивлению каждого, эти ответы не приходят с другой стороны. Я использую Cisco 820 в качестве маршрутизатора и VPN-сервера. Насколько я могу судить, проверка конфигурации маршрутизатора не показывает ничего необычного. У меня не включен брандмауэр, и я использую списки доступа для маршрутизации и контроля доступа.
Я подозреваю, что пакеты отбрасываются маршрутизатором до того, как они могут быть зашифрованы и отправлены по туннелю Ipsec. Пожалуйста, кто-нибудь посоветует, что может сбрасывать эти пакеты.
Дальнейшего общения не происходит, потому что трехстороннее рукопожатие не удается.
Это трассировка пакета:
25.690224 200.32.15.154 -> 192.168.0.2 TCP 74 45367 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1452 SACK_PERM=1 TSval=610983874 TSecr=0 WS=128
25.690267 192.168.0.2 -> 200.32.15.154 TCP 74 http > 45367 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=763845089 TSecr=610983874 WS=128
26.687067 192.168.0.2 -> 200.32.15.154 TCP 74 http > 45367 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=763845339 TSecr=610983874 WS=128
28.687066 192.168.0.2 -> 200.32.15.154 TCP 74 http > 45367 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=763845839 TSecr=610983874 WS=128
31.688116 200.32.15.154 -> 192.168.0.2 TCP 74 45367 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1452 SACK_PERM=1 TSval=610989874 TSecr=0 WS=128
31.688147 192.168.0.2 -> 200.32.15.154 TCP 74 http > 45367 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=763846589 TSecr=610983874 WS=128
32.687068 192.168.0.2 -> 200.32.15.154 TCP 74 http > 45367 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=763846839 TSecr=610983874 WS=128
40.687059 192.168.0.2 -> 200.32.15.154 TCP 74 http > 45367 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=763848839 TSecr=610983874 WS=128
43.689503 200.32.15.154 -> 192.168.0.2 TCP 74 45367 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1452 SACK_PERM=1 TSval=611001874 TSecr=0 WS=128
43.689531 192.168.0.2 -> 200.32.15.154 TCP 74 http > 45367 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=763849589 TSecr=610983874 WS=128
56.887060 192.168.0.2 -> 200.32.15.154 TCP 74 http > 45367 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=763852889 TSecr=610983874 WS=128
Это мои Iptables на сервере:
Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-dovecot-pop3imap tcp -- anywhere anywhere multiport dports pop3,pop3s,imap2,imaps
fail2ban-pureftpd tcp -- anywhere anywhere multiport dports ftp
fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh
fail2ban-dovecot-pop3imap tcp -- anywhere anywhere multiport dports pop3,pop3s,imap2,imaps
fail2ban-pureftpd tcp -- anywhere anywhere multiport dports ftp
fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain fail2ban-dovecot-pop3imap (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain fail2ban-pureftpd (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain fail2ban-ssh (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere
RETURN all -- anywhere anywhere
Это список доступа, указывающий на интернет и как я запрограммировал эти адреса:
150 deny ip 192.168.0.0 0.0.0.255 host 200.32.15.152 log (306 matches)
160 deny ip 192.168.0.0 0.0.0.255 host 200.32.15.153 log (101 matches)
170 deny ip 192.168.0.0 0.0.0.255 host 200.32.15.154 log (141 matches)
180 deny ip 192.168.0.0 0.0.0.255 host 200.32.15.155 log (74 matches)
Это список доступа, указывающий на VPN:
60 permit ip host 192.168.0.2 host 200.32.15.152 (132 matches)
70 permit ip host 192.168.0.2 host 200.32.15.153 (74 matches)
80 permit ip host 192.168.0.2 host 200.32.15.154 (146 matches)
90 permit ip host 192.168.0.2 host 200.32.15.155 (72 matches)
Это SA для этих адресов:
local ident (addr/mask/prot/port): (192.168.0.2/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (200.32.15.154/255.255.255.255/0/0)
current_peer 41.72.111.122 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 28, #pkts encrypt: 28, #pkts digest: 28
#pkts decaps: 68, #pkts decrypt: 68, #pkts verify: 68
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 41.222.240.23, remote crypto endpt.: 41.72.111.122
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet4.1
current outbound spi: 0x8FD440DA(2413052122)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0xD6FEA63C(3607012924)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 19, flow_id: Onboard VPN:19, sibling_flags 80000040, crypto map: sshlink-to-savannah
sa timing: remaining key lifetime (k/sec): (4263446/2717)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x8FD440DA(2413052122)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 20, flow_id: Onboard VPN:20, sibling_flags 80000040, crypto map: sshlink-to-savannah
sa timing: remaining key lifetime (k/sec): (4263446/2717)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
Пожалуйста, кто-нибудь помогите!!!
1 ответ
Наконец, найдя решение, я должен был включить свой публичный IP-адрес в ACL. Из-за натинга ответная ветвь рукопожатия отправлялась с использованием общедоступного IP-адреса, следовательно, после добавления общедоступного IP-адреса в ACL, PRESTO!!! Все работало