Не удается подключиться к службам TCP через vpn при использовании другого шлюза до успешного пинга
Я не могу понять этого, более того, я не уверен, какая сторона виновата, но я думаю, что проблема на стороне pfsense. См. Схему ниже:
У меня в центральном офисе два роутера:
- Первый - это mikrotik CCR1009-7G-1C-1S +, подключенный к Интернету через провайдера очень быстрого оптического волокна (интерфейс pppoe со статическим IP), этот маршрутизатор имеет локальный IP 192.168.25.62. Этот маршрутизатор представляет собой сервер IPSEC / l2tp для другого офиса, который использует mikrotik 951G-2HnD и очень хороший VDSL с локальным IP 192.168.26.1. Все работает, и я могу пинговать и подключаться ко всему на другой стороне, например к веб-серверам, файлообменникам (например, на сервере схемы 192.168.25.100) и т. Д., И у меня очень хорошая производительность.
- второй - виртуализированный kvm pfsense, подключенный к Интернету через другого очень быстрого провайдера оптического волокна (интерфейс pppoe со статическим IP-адресом), этот маршрутизатор является шлюзом только для определенного веб-сервера debian 192.168.25.136 и дистрибутива freepbx / asterisk 192.168.25.200. У этого роутера локальный IP 192.168.25.76.
Мои проблемы влияют на серверы, которые используют pfsense как gw: я настроил все маршруты и маршруты возврата как для mikrotiks, так и для pfsense, и я могу пинговать из удаленной сети mikrotik 192.168.26.0/24, веб-сервера debian и freepbx, я даже могу зарегистрировать телефоны к серверу freepbx, и я могу получить доступ к интерфейсу pfsense .. но по какой-то причине я не могу получить доступ к любой службе TCP, такой как веб-интерфейсы, ssh, samba и т. д. на этих серверах с pfsense gw, если я нахожусь в удаленной сети 192.168.26.0/24 .
Очень странно то, что если я запускаю ping или tracert с удаленной рабочей станции в примере 192.168.26.20 к удаленным службам TCP с помощью pfsense gw, у меня будет доступ на несколько минут к этому конкретному серверу .. действительно странно выглядит как-то с открытыми состояниями.
Я думал о mtu на стороне удаленного mikrotik, но, похоже, ничего не изменилось, снижая значения mtu, даже если я изменяю значения непосредственно на интерфейсе Ethernet рабочих станций или серверов. Я попытался добавить правила ввода / вывода прохода, чтобы увидеть, не изменится ли что-то, но безрезультатно.
Итак, проблема в том, что я могу пинговать с обеих сторон через vpn, но я не могу связаться с TCP-сервисами, которые используют шлюз pfsense, только после попытки пинга все будет работать в течение нескольких минут.
вот tcpdump, который я получил на веб-сервере 192.168.25.136 при попытке открыть страницу с удаленной рабочей станции 192.168.26.20
16:10:26.764026 IP 192.168.26.20.51372 > freepbx.sangoma.local.http: Flags [S], seq 976993469, win 64240, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
16:10:26.764084 IP freepbx.sangoma.local.http > 192.168.26.20.51372: Flags [S.], seq 1214405327, ack 976993470, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:27.014422 IP 192.168.26.20.51373 > freepbx.sangoma.local.http: Flags [S], seq 2419313814, win 64240, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
16:10:27.014452 IP freepbx.sangoma.local.http > 192.168.26.20.51373: Flags [S.], seq 1721642903, ack 2419313815, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:27.764852 IP 192.168.26.20.51372 > freepbx.sangoma.local.http: Flags [S], seq 976993469, win 64240, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
16:10:27.764895 IP freepbx.sangoma.local.http > 192.168.26.20.51372: Flags [S.], seq 1214405327, ack 976993470, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:28.014830 IP 192.168.26.20.51373 > freepbx.sangoma.local.http: Flags [S], seq 2419313814, win 64240, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
16:10:28.014855 IP freepbx.sangoma.local.http > 192.168.26.20.51373: Flags [S.], seq 1721642903, ack 2419313815, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:28.766953 IP freepbx.sangoma.local.http > 192.168.26.20.51372: Flags [S.], seq 1214405327, ack 976993470, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:29.166956 IP freepbx.sangoma.local.http > 192.168.26.20.51373: Flags [S.], seq 1721642903, ack 2419313815, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:29.765511 IP 192.168.26.20.51372 > freepbx.sangoma.local.http: Flags [S], seq 976993469, win 64240, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
16:10:29.765537 IP freepbx.sangoma.local.http > 192.168.26.20.51372: Flags [S.], seq 1214405327, ack 976993470, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:30.015698 IP 192.168.26.20.51373 > freepbx.sangoma.local.http: Flags [S], seq 2419313814, win 64240, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
16:10:30.015742 IP freepbx.sangoma.local.http > 192.168.26.20.51373: Flags [S.], seq 1721642903, ack 2419313815, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:31.766918 IP freepbx.sangoma.local.http > 192.168.26.20.51372: Flags [S.], seq 1214405327, ack 976993470, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:32.166957 IP freepbx.sangoma.local.http > 192.168.26.20.51373: Flags [S.], seq 1721642903, ack 2419313815, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:33.765739 IP 192.168.26.20.51372 > freepbx.sangoma.local.http: Flags [S], seq 976993469, win 64240, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
16:10:33.765783 IP freepbx.sangoma.local.http > 192.168.26.20.51372: Flags [S.], seq 1214405327, ack 976993470, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:34.016993 IP 192.168.26.20.51373 > freepbx.sangoma.local.http: Flags [S], seq 2419313814, win 64240, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
16:10:34.017020 IP freepbx.sangoma.local.http > 192.168.26.20.51373: Flags [S.], seq 1721642903, ack 2419313815, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:37.766944 IP freepbx.sangoma.local.http > 192.168.26.20.51372: Flags [S.], seq 1214405327, ack 976993470, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:38.166943 IP freepbx.sangoma.local.http > 192.168.26.20.51373: Flags [S.], seq 1721642903, ack 2419313815, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:41.765829 IP 192.168.26.20.51372 > freepbx.sangoma.local.http: Flags [S], seq 976993469, win 64240, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
16:10:41.765859 IP freepbx.sangoma.local.http > 192.168.26.20.51372: Flags [S.], seq 1214405327, ack 976993470, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:42.017096 IP 192.168.26.20.51373 > freepbx.sangoma.local.http: Flags [S], seq 2419313814, win 64240, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
16:10:42.017117 IP freepbx.sangoma.local.http > 192.168.26.20.51373: Flags [S.], seq 1721642903, ack 2419313815, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:49.966944 IP freepbx.sangoma.local.http > 192.168.26.20.51372: Flags [S.], seq 1214405327, ack 976993470, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:10:50.366943 IP freepbx.sangoma.local.http > 192.168.26.20.51373: Flags [S.], seq 1721642903, ack 2419313815, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:11:05.966987 IP freepbx.sangoma.local.http > 192.168.26.20.51372: Flags [S.], seq 1214405327, ack 976993470, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:11:06.366951 IP freepbx.sangoma.local.http > 192.168.26.20.51373: Flags [S.], seq 1721642903, ack 2419313815, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
Это traceroute, который работает должным образом от удаленной рабочей станции до freepbx (с pfsense как gw)
[root@freepbx ~]# traceroute 192.168.26.20
traceroute to 192.168.26.20 (192.168.26.20), 30 hops max, 60 byte packets
1 192.168.25.62 (192.168.25.62) 0.301 ms 0.244 ms 0.204 ms //this is the central mikrotik router
2 10.0.25.2 (10.0.25.2) 37.522 ms 37.611 ms 37.647 ms //this is the l2pt remote client
3 192.168.26.20 (192.168.26.20) 38.085 ms * * //workstation reached
это с freepbx на удаленную рабочую станцию:
[root@freepbx ~]# traceroute 192.168.26.20
traceroute to 192.168.26.20 (192.168.26.20), 30 hops max, 60 byte packets
1 192.168.25.62 (192.168.25.62) 0.301 ms 0.244 ms 0.204 ms //this is the central mikrotik router
2 10.0.25.2 (10.0.25.2) 37.522 ms 37.611 ms 37.647 ms //this is the l2pt remote client
3 192.168.26.20 (192.168.26.20) 38.085 ms * * //workstation reached
это таблица маршрутизации в моем pfsense, вы заметите, что запросы к удаленной сети 192.168.26.0/24 маршрутизируются через mikrotik gw 192.168.25.62, это самый важный маршрут, который дает доступ с удаленной стороны при использовании другого gw :
default xx.xx.xx.xx UGS 1139654 1492 pppoe0
10.0.25.0/24 192.168.25.62 UGS 1 1500 vtnet1
10.0.40.0/24 10.0.40.2 UGS 49992 1500 ovpns1
10.0.40.1 link#9 UHS 0 16384 lo0
10.0.40.2 link#9 UH 2343778 1500 ovpns1
10.0.90.0/24 10.0.90.2 UGS 0 1500 ovpns2
10.0.90.1 link#10 UHS 0 16384 lo0
10.0.90.2 link#10 UH 0 1500 ovpns2
127.0.0.1 link#3 UH 1244 16384 lo0
192.168.25.0/24 link#2 U 754126 1500 vtnet1
192.168.25.76 link#2 UHS 0 16384 lo0
192.168.26.0/24 192.168.25.62 UGS 90979 1500 vtnet1
192.168.27.0/24 192.168.25.62 UGS 326 1500 vtnet1
195.96.194.18 link#8 UH 39459 1492 pppoe0
195.96.195.62 link#8 UHS 0 16384 lo0
На данный момент единственное исправление, которое мне действительно не нравится использовать, - это замаскировать на центральном микротике всю удаленную сеть 192.168.26.0/24 на интерфейс mikrotik LAN 192.168.25.62, таким образом все запросы будут представлены в pfsense gw с IP 192.168.25.62, и все будет работать, но я хочу избежать этого решения. Я читал, что, возможно, что-то связано с таблицей arp, но не могу найти решение.