Jump to content
Калькуляторы

Проблема с туннелями во FreeBSD gif tunnels problem

Помогите разобратся с проблемой туннеля.

Имеются 2 сервера FreeBSD1, FreeBSD2

 

Настроенны они таким образом:

 

FreeBSD1

vlan2 ip 192.168.10.113/24 локалка

vlan4 ip 10.0.28.194/30 провайдер

 

Настройки туннеля:

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
       tunnel inet 10.0.28.194 --> 10.0.28.170
       inet 192.168.10.113 --> 192.168.14.1 netmask 0xffffffff
       options=1<ACCEPT_REV_ETHIP_VER>

 

 

Правила ipfw:

# ipfw sh | more
ipfw: DEPRECATED: 'sh' matched 'show' as a sub-string
00001    1568      93712 allow ip from any to any via gif0
00100    9549    5434190 allow ip from any to any via lo0
00200       0          0 deny ip from any to 127.0.0.0/8
00300       0          0 deny ip from 127.0.0.0/8 to any
00400   34173   33074300 allow tcp from me 20,21 to any keep-state
00600     380      16356 deny tcp from any 135,137-139 to any
00700  564793   52470603 deny udp from any 135,137-139 to any
00800 4401150 3586422614 allow ip from 172.16.16.0/24 to 192.168.10.100
00900 2260086  173715574 allow ip from 192.168.10.100 to 172.16.16.0/24
01000     107      13276 allow ip from 172.16.16.0/24 to 192.168.10.103
01000      83      11590 allow ip from 192.168.10.103 to 172.16.16.0/24
10000   85025    4724201 divert 8668 ip from 172.16.16.0/24 to any out via vlan2
10100   36172    9143413 divert 8668 ip from 192.168.10.0/24 to any out via vlan2
10200  172805    7545755 divert 8668 ip from 192.168.11.0/24 to any out via vlan2
10300  396447  483817456 divert 8668 ip from any to 172.16.24.113 in via vlan2
10400   13698    1886743 divert 8668 ip from any to 192.168.10.113 in via vlan2
10500   33984    1361253 allow icmp from any to any icmptypes 0,3,4,8,11
10600  739095  507665509 allow ip from me to any
10700  439696  490862792 allow ip from any to any in recv vlan2
10800    7042     695318 allow tcp from any to me established
10900       0          0 allow ospf from any to me
11000      68       4352 allow ospf from any to 224.0.0.5
11100       0          0 allow ospf from any to 224.0.0.6
11200       0          0 allow ospf from me to any
11300      61       2996 allow tcp from any to me dst-port 22,80,53,1723,3128 setup
11400       0          0 allow gre from any to me setup
11500   34912    3318242 fwd 127.0.0.1,3128 tcp from 192.168.11.0/24 to any dst-port 80
11600    3265     208018 allow udp from any to any dst-port 53
11900  171551    7495224 allow ip from 192.168.11.0/24 to any
12000  349204  463288016 allow ip from any to 192.168.11.0/24
12100   85904    4766726 allow ip from 172.16.16.0/24 to any
12200   29036    4911698 allow ip from any to 172.16.16.0/24
12300   11950    3913962 allow ip from 192.168.10.0/24 to any
12400   35614   16199332 allow ip from any to 192.168.10.0/24
12500  348917   24633634 allow ip from 10.0.28.160/27 to any
12600       0          0 allow ip from any to 10.0.28.160/27
12650    3094     148512 allow ip from 192.168.14.0/24 to any
12650       0          0 allow ip from any to 192.168.14.0/24
65535     396      84389 deny ip from any to any

Если я допустил ошибку в правилах, буду очень благодарен за исправку.

 

# netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            172.16.24.1        UGS       608   261835  vlan2
10.0.15.0/24       10.0.28.193        UG1         0        0  vlan4
10.0.28.160/27     10.0.28.193        UG1         0   421333  vlan4
10.0.28.192/30     link#10            U           0       30  vlan4
10.0.28.194        link#10            UHS         0      186    lo0
127.0.0.1          link#6             UH          0     1434    lo0
172.16.0.0/24      link#9             U           0     6707  vlan3
172.16.0.1         link#9             UHS         0        0    lo0
172.16.16.0/24     link#11            U           1  1162067  vlan5
172.16.16.1        link#11            UHS         0        0    lo0
172.16.24.0/24     link#8             U          13    12554  vlan2
172.16.24.113      link#8             UHS         0        0    lo0
172.18.18.0/24     link#3             U           0        0    xl0
172.18.18.1        link#3             UHS         0        0    lo0
192.168.10.0/24    link#8             U           1  2589004  vlan2
192.168.10.113     link#7             UHS         1     3357    lo0
192.168.14.0/24    192.168.14.1       UGS         0      112   gif0
192.168.14.1       link#7             UH          0      790   gif0

 

 

=======================================================================================

FreeBSD2

rl0 ip 192.168.14.1/24 локалка

rl1 ip 10.0.28.170/27 провайдер

 

настройки туннеля:

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
       tunnel inet 10.0.28.170 --> 10.0.28.194
       inet 192.168.14.1 --> 192.168.10.113 netmask 0xffffff00
       options=1<ACCEPT_REV_ETHIP_VER>

 

Правила ipfw:

 

# ipfw sh|more
ipfw: DEPRECATED: 'sh' matched 'show' as a sub-string
00001  2584  199072 allow ip from any to any via gif0
65000 14555 3110317 allow ip from any to any
65535     0       0 deny ip from any to any

 

# netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.10.113     UGS         0     2943   gif0
10.0.28.160/27     link#2             U           0        0    re1
10.0.28.170        link#2             UHS         0        0    lo0
10.0.28.194        10.0.28.161        UGHS        0     4267    re1
127.0.0.1          link#6             UH          0      136    lo0
192.168.10.0/24    192.168.10.113     UGS         0        0   gif0
192.168.10.113     link#7             UH          0     1327   gif0
192.168.14.0/24    link#3             U           0      306    re2
192.168.14.1       link#3             UHS         1        0    lo0

 

Временами связь с FreeBSD1 на FreeBSD2 пропадает, даже подвисает ssh но PING стабильно проходит.

Сразу после подвисания ssh, начинаю коннектится опять по этой схеме FreeBSD1 > ssh > FreeBSD2 все нормально. Минут через 3-5 опять ситуация повторяется. Клиенты со стороны FreeBSD2 жалуются на то что на FTP сервер (на стороне FreeBSD1) при загрузке файлов останавливается на 10-20%.

 

 

Кусочек логов tcpdump с сервера FreeBSD1 именно в тот момент когда подвисает ssh и все остальные службы:

 

# tcpdump -i gif0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gif0, link-type NULL (BSD loopback), capture size 96 bytes
17:35:00.364239 IP 192.168.14.1.22 > 192.168.10.113.16901: Flags [.], ack 64, win 8326, options [nop,nop,TS val 2253429692 ecr 89255782], length 0
17:35:00.687251 IP 192.168.14.7.3384 > 192.168.0.20.3402: Flags [s], seq 219138927, win 65535, options [mss 1460,nop,nop,sackOK], length 0
17:35:02.318831 IP 192.168.14.10.2693 > 192.168.0.20.3402: Flags [s], seq 2070203026, win 65535, options [mss 1460,nop,nop,sackOK], length 0
17:35:03.642198 IP 192.168.14.7.3384 > 192.168.0.20.3402: Flags [s], seq 219138927, win 65535, options [mss 1460,nop,nop,sackOK], length 0
17:35:05.282035 IP 192.168.10.113.16901 > 192.168.14.1.22: Flags [P.], ack 1, win 8326, options [nop,nop,TS val 89260679 ecr 2253367905,nop,nop,sack 1 {49:1105}], length 48
17:35:05.359738 IP 192.168.14.1.22 > 192.168.10.113.16901: Flags [P.], ack 112, win 8326, options [nop,nop,TS val 2253434727 ecr 89260679], length 48
17:35:05.359758 IP 192.168.10.113.16901 > 192.168.14.1.22: Flags [.], ack 1, win 8326, options [nop,nop,TS val 89260754 ecr 2253367905,nop,nop,sack 1 {49:1153}], length 0
17:35:05.371363 IP 192.168.14.1.22 > 192.168.10.113.16901: Flags [P.], ack 112, win 8326, options [nop,nop,TS val 2253434728 ecr 89260679], length 48
17:35:05.371377 IP 192.168.10.113.16901 > 192.168.14.1.22: Flags [.], ack 1, win 8326, options [nop,nop,TS val 89260765 ecr 2253367905,nop,nop,sack 1 {49:1201}], length 0
17:35:05.377967 IP 192.168.14.1.22 > 192.168.10.113.16901: Flags [P.], ack 112, win 8326, options [nop,nop,TS val 2253434728 ecr 89260679], length 48
17:35:05.377980 IP 192.168.10.113.16901 > 192.168.14.1.22: Flags [.], ack 1, win 8326, options [nop,nop,TS val 89260771 ecr 2253367905,nop,nop,sack 1 {49:1249}], length 0
17:35:05.384620 IP 192.168.14.1.22 > 192.168.10.113.16901: Flags [P.], ack 112, win 8326, options [nop,nop,TS val 2253434728 ecr 89260679], length 48
17:35:05.384633 IP 192.168.10.113.16901 > 192.168.14.1.22: Flags [.], ack 1, win 8326, options [nop,nop,TS val 89260778 ecr 2253367905,nop,nop,sack 1 {49:1297}], length 0
17:35:05.391272 IP 192.168.14.1.22 > 192.168.10.113.16901: Flags [P.], ack 112, win 8326, options [nop,nop,TS val 2253434728 ecr 89260679], length 48
17:35:05.391285 IP 192.168.10.113.16901 > 192.168.14.1.22: Flags [.], ack 1, win 8326, options [nop,nop,TS val 89260784 ecr 2253367905,nop,nop,sack 1 {49:1345}], length 0

 

Никак не пойму что происходит, уважаемые форумчане кто сталкивался с такой траблой пожалуйста поделитесь информацией. Как быть где копать?

Share this post


Link to post
Share on other sites

покажите MTU на vlan2 и vlan4

Имхо, понижайте MTU на gif0 до 1460 и ниже.

Edited by vlad11

Share this post


Link to post
Share on other sites

покажите MTU на vlan2 и vlan4

Имхо, понижайте MTU на gif0 до 1460 и ниже.

# ifconfig vlan4

vlan4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

ether 00:01:02:fa:c2:9c

inet 10.0.28.194 netmask 0xfffffffc broadcast 10.0.28.195

media: Ethernet autoselect (100baseTX <full-duplex>)

status: active

vlan: 4 parent interface: xl0

 

# ifconfig vlan2

vlan2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

ether 00:01:02:fa:c2:9c

inet 172.16.24.113 netmask 0xffffff00 broadcast 172.16.24.255

inet 192.168.10.113 netmask 0xffffff00 broadcast 192.168.10.255

media: Ethernet autoselect (100baseTX <full-duplex>)

status: active

vlan: 2 parent interface: xl0

Share this post


Link to post
Share on other sites

покажите MTU на vlan2 и vlan4

Имхо, понижайте MTU на gif0 до 1460 и ниже.

Сменил MTU проблема не исчезла:

 

логи tcpdump^

18:35:17.534612 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [P.], ack 1, win 8272, options [nop,nop,TS val 92727911 ecr 2848036599,nop,nop,sack 1 {49:1553}], length 48
18:35:17.605998 IP 192.168.14.1.ssh > 192.168.10.113.30076: Flags [P.], ack 240, win 8272, options [nop,nop,TS val 2848085361 ecr 92727911], length 48
18:35:17.606021 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [.], ack 1, win 8272, options [nop,nop,TS val 92727979 ecr 2848036599,nop,nop,sack 1 {49:1601}], length 0
18:35:18.419620 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [P.], ack 1, win 8272, options [nop,nop,TS val 92728760 ecr 2848036599,nop,nop,sack 1 {49:1601}], length 48
18:35:18.492299 IP 192.168.14.1.ssh > 192.168.10.113.30076: Flags [P.], ack 288, win 8272, options [nop,nop,TS val 2848086254 ecr 92728760], length 48
18:35:18.492323 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [.], ack 1, win 8272, options [nop,nop,TS val 92728830 ecr 2848036599,nop,nop,sack 2 {1649:1697}{49:1601}], length 0
18:35:18.498892 IP 192.168.14.1.ssh > 192.168.10.113.30076: Flags [P.], ack 288, win 8272, options [nop,nop,TS val 2848086254 ecr 92728760], length 48
18:35:18.498906 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [.], ack 1, win 8272, options [nop,nop,TS val 92728836 ecr 2848036599,nop,nop,sack 2 {1649:1745}{49:1601}], length 0
18:35:19.564209 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [P.], ack 1, win 8272, options [nop,nop,TS val 92729858 ecr 2848036599,nop,nop,sack 2 {1649:1745}{49:1601}], length 48
18:35:19.638435 IP 192.168.14.1.ssh > 192.168.10.113.30076: Flags [P.], ack 336, win 8272, options [nop,nop,TS val 2848087408 ecr 92729858], length 48
18:35:19.638457 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [.], ack 1, win 8272, options [nop,nop,TS val 92729930 ecr 2848036599,nop,nop,sack 2 {1649:1793}{49:1601}], length 0
18:35:19.648337 IP 192.168.14.1.ssh > 192.168.10.113.30076: Flags [P.], ack 336, win 8272, options [nop,nop,TS val 2848087408 ecr 92729858], length 48
18:35:19.648352 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [.], ack 1, win 8272, options [nop,nop,TS val 92729939 ecr 2848036599,nop,nop,sack 2 {1649:1841}{49:1601}], length 0

Share this post


Link to post
Share on other sites

Менять надо с помощью pf, см. нотацию "scrub".

Share this post


Link to post
Share on other sites

покажите MTU на vlan2 и vlan4

Имхо, понижайте MTU на gif0 до 1460 и ниже.

Сменил MTU проблема не исчезла:

 

 

Упорно не вижу в tcpdump'e новых данных о MTU

Share this post


Link to post
Share on other sites

покажите MTU на vlan2 и vlan4

Имхо, понижайте MTU на gif0 до 1460 и ниже.

Сменил MTU проблема не исчезла:

 

Упорно не вижу в tcpdump'e новых данных о MTU

 

 

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
       tunnel inet 10.0.28.194 --> 10.0.28.170
       inet 192.168.10.113 --> 192.168.14.1 netmask 0xffffff00
       options=1<ACCEPT_REV_ETHIP_VER>

 

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
       tunnel inet 10.0.28.170 --> 10.0.28.194
       inet 192.168.14.1 --> 192.168.10.113 netmask 0xffffff00
       options=1<ACCEPT_REV_ETHIP_VER>

 

Если подразумевалось снизить mtu

набрал команду ifconfig gif0 mtu 1460

Результат тот-же:

21:37:16.635427 IP 192.168.14.1.22 > 192.168.10.113.65531: Flags [.], ack 17296, win 8289, options [nop,nop,TS val 562597805 ecr 103                                    199933,nop,nop,sack 1 {17344:17920}], length 0
21:37:16.701190 IP 192.168.10.113.65531 > 192.168.14.1.22: Flags [P.], ack 26753, win 8289, options [nop,nop,TS val 103208618 ecr 56                                    2597805], length 48
21:37:16.769711 IP 192.168.14.1.22 > 192.168.10.113.65531: Flags [.], ack 17296, win 8289, options [nop,nop,TS val 562597946 ecr 103                                    199933,nop,nop,sack 1 {17344:17968}], length 0
21:37:17.010323 IP 192.168.10.113.65531 > 192.168.14.1.22: Flags [P.], ack 26753, win 8289, options [nop,nop,TS val 103208914 ecr 56                                    2597946], length 48
21:37:17.085822 IP 192.168.14.1.22 > 192.168.10.113.65531: Flags [.], ack 17296, win 8289, options [nop,nop,TS val 562598259 ecr 103                                    199933,nop,nop,sack 1 {17344:18016}], length 0
21:37:17.239656 IP 192.168.10.113.65531 > 192.168.14.1.22: Flags [P.], ack 26753, win 8289, options [nop,nop,TS val 103209134 ecr 56                                    2598259], length 48
21:37:17.311279 IP 192.168.14.1.22 > 192.168.10.113.65531: Flags [.], ack 17296, win 8289, options [nop,nop,TS val 562598487 ecr 103                                    199933,nop,nop,sack 1 {17344:18064}], length 0
21:37:17.389902 IP 192.168.10.113.65531 > 192.168.14.1.22: Flags [P.], ack 26753, win 8289, options [nop,nop,TS val 103209279 ecr 56                                    2598487], length 48
21:37:17.461813 IP 192.168.14.1.22 > 192.168.10.113.65531: Flags [.], ack 17296, win 8289, options [nop,nop,TS val 562598645 ecr 103                                    199933,nop,nop,sack 1 {17344:18112}], length 0
21:37:17.580265 IP 192.168.10.113.65531 > 192.168.14.1.22: Flags [P.], ack 26753, win 8289, options [nop,nop,TS val 103209461 ecr 56                                    2598645], length 48
21:37:17.654233 IP 192.168.14.1.22 > 192.168.10.113.65531: Flags [.], ack 17296, win 8289, options [nop,nop,TS val 562598834 ecr 103                                    199933,nop,nop,sack 1 {17344:18160}], length 0

Edited by fetch001

Share this post


Link to post
Share on other sites

Компьютер(MTU 1500)<-->router|IPSec(MTU 1460)<-->router|IPSec(MTU 1460)<-->Сервер(MTU 1500)

Компьютер обращается к серверу, MTU 1500 с обоих сторон.

Откуда сервер узнает, что по дороге есть туннель, с меньшим MTU?

Написал же, scrub в pf - валидный вариант.

Share this post


Link to post
Share on other sites

Нужны такие пакеты:

 


17:35:00.687251 IP 192.168.14.7.3384 > 192.168.0.20.3402: Flags [s], seq 219138927, win 65535, options [mss 1460,nop,nop,sackOK], length 0

 

Откуда сервер узнает, что по дороге есть туннель, с меньшим MTU?

Написал же, scrub в pf - валидный вариант.

роутеры в прямой видимости.

На линии нет никакого оборудования типа конвертеров оптика/медь?

Share this post


Link to post
Share on other sites

Нужны такие пакеты:

 


17:35:00.687251 IP 192.168.14.7.3384 > 192.168.0.20.3402: Flags [s], seq 219138927, win 65535, options [mss 1460,nop,nop,sackOK], length 0

 

Откуда сервер узнает, что по дороге есть туннель, с меньшим MTU?

Написал же, scrub в pf - валидный вариант.

роутеры в прямой видимости.

На линии нет никакого оборудования типа конвертеров оптика/медь?

Оборудования только ADSL модем Huawei SmartAX MT880.

Схема подключения:

FreeBSD1 <провайдер>--VPN(routing)--<провайдер> FreeBSD2

Share this post


Link to post
Share on other sites

Понижайте mtu на обоих линках, пока не заработает.

Share this post


Link to post
Share on other sites

Вообще-то тогда уж scrub on gif0 all max-mss 1240.

 

MSS = MTU - 40 bytes.

 

 

 

 

А вообще на вопрос "Откуда сервер узнает, что по дороге есть туннель, с меньшим MTU?" давно придуман ответ в виде path MTU discovery. И даже целых два варианта :) Ну это так, к слову.

 

 

Share this post


Link to post
Share on other sites

А вообще на вопрос "Откуда сервер узнает, что по дороге есть туннель, с меньшим MTU?"

давно придуман ответ в виде path MTU discovery. И даже целых два варианта :)

Открой для себя rfc2923 "TCP Problems with Path MTU Discovery".

Share this post


Link to post
Share on other sites

Краткое прочтение RFC 2000 года показало некоторое устаревание проблем, изложенных в нём. Вернее, принятие во внимание путей их решения, предложенных в нём же - особенно это касается TCP: открой для себя RFC 4821. "Packetization Layer Path MTU Discovery".

Edited by Dyr

Share this post


Link to post
Share on other sites

IPSec занимает промежуточное положение между IP уровнем и уровнем пакетирования и как выражаются авторы RFC 4821 "может быть отнесена" либо туда, либо туда.

Однако сама идеология IPSec, "шифровать, но не изменять содержимое" делает отсылку каких либо сообщений внутри шифруемого пакета делом безнадёжным, а отсылка сообщения публичными узлами, являющимися сторонами туннеля во первых - не всегда возможна, а во вторых - бессмысленна, т.к. с точки зрения "клиент-сервер", этих узлов просто нет.

Всё это сильно затрудняет PMTU в системах, содержащих туннель на базе IPSec и "scrub" в pf является наиболее приемлемым вариантом.

Share this post


Link to post
Share on other sites

Краткое прочтение RFC 2000 года показало некоторое устаревание проблем, изложенных в нём.

Они не только не устарели, но стали более актуальны, т.к. в свежих фикспаках

для Windows брандмауэр, похоже, блокирует работу собственного pmtud.

 

Единственное решение проблемы - mssfix на шлюзе при входе в IP-туннель.

Share this post


Link to post
Share on other sites
Они не только не устарели, но стали более актуальны, т.к. в свежих фикспаках для Windows брандмауэр, похоже, блокирует работу собственного pmtud.

 

Эм...ссылко?

 

 

Share this post


Link to post
Share on other sites

helpdesk.sertolovo.ru

 

Смешно, да. Я там как-то не присутствую.

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this