помогите разобраться с маршрутизацией

Questions related to general functionality
xmana
Posts: 7
Joined: 13 Jun 2019, 09:37

помогите разобраться с маршрутизацией

Post by xmana »

Доброго времени суток!

Не могу разобраться с маршрутизацией, голова уже дымит:) Надеюсь на сообщество:)

Вкратце ситуация такая:

есть сервер vpn (accel-ppp, l2tp/pptp, ubuntu), есть много удаленных офисов, на офисах клиентом впн и роутером выступают микротики (RB941), за ними соотевтственно небольшие сетки (3-10 компов).
суть проблемы, собственно, такая: если в правилах iptables на сервере включен masquerade или SNAT в локалку, все чудесно летает, если маскарад выключаем, то начинают твориться какие-то непонятки. В части филиалов перестают ходить пакеты, в части все продолжает работать, в тех что перестали , если пустить пинг например на внутреннюю сетку центрального офиса, то через 10-15 провалов - маршрут поднимается и все работает....
весь прикол в том что все работает по "фазам луны"...

Где рыть уже не знаю. Теперь подробности:

сервер:

Code: Select all

VERSION="16.04.5 LTS (Xenial Xerus)"

Code: Select all

root@vpnnn:~# uname -a
Linux vpnnn 4.4.0-134-generic #160-Ubuntu SMP Wed Aug 15 14:58:00 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Code: Select all

root@vpnnn:~# accel-cmd -V
accel-cmd 1.11.2
Интерфейсы:
ens3 - локалка
ens4 - WAN
pppNN - интерфейсы входящих соединений (vpn тунелей).
ppp92 - стенд.

Code: Select all

root@vpnnn:~# ifconfig | grep -A 1 'Link encap'
ens3      Link encap:Ethernet  HWaddr 52:54:00:ac:ea:ff
          inet addr:192.168.2.103  Bcast:192.168.3.255  Mask:255.255.252.0
--
ens4      Link encap:Ethernet  HWaddr 52:54:00:e1:82:06
          inet addr:192.168.4.4  Bcast:192.168.4.255  Mask:255.255.255.0
--
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
--
ppp0      Link encap:Point-to-Point Protocol
          inet addr:10.255.255.1  P-t-P:10.255.253.91  Mask:255.255.255.255
--
ppp1      Link encap:Point-to-Point Protocol
          inet addr:10.255.255.1  P-t-P:10.255.253.71  Mask:255.255.255.255
--
...
ppp92     Link encap:Point-to-Point Protocol
          inet addr:10.255.255.1  P-t-P:10.255.253.19  Mask:255.255.255.255
--
...
маршруты:
10.x.y.z/24 - сетки филиалов, 10.255.253.i - ip, получаемая из параметров лдапа для юзера или из пула сервера, если параметр отсутствует на интерфейс впн соединения.
(маршруты на pppNN поднимаются после авторизации через /etc/ppp/ip-up)

Code: Select all

root@vpnnn:~# ip r
default via 192.168.4.1 dev ens4 onlink
...
10.14.31.0/24 via 10.255.253.91 dev ppp0
...
10.14.78.0/24 via 10.255.253.71 dev ppp1
...
10.21.11.0/24 via 10.255.253.19 dev ppp92
...
10.255.253.71 dev ppp1  proto kernel  scope link  src 10.255.255.1
...
10.255.253.91 dev ppp0  proto kernel  scope link  src 10.255.255.1
...
10.255.253.19 dev ppp92  proto kernel  scope link  src 10.255.255.1
...
192.168.0.0/22 dev ens3  proto kernel  scope link  src 192.168.2.103
192.168.4.0/24 dev ens4  proto kernel  scope link  src 192.168.4.4
iptables: (на период тестирования сведено к минимуму)

Code: Select all

root@vpnnn:~# iptables -L -n -v
Chain INPUT (policy ACCEPT 8873K packets, 964M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 21M packets, 22G bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 16M packets, 22G bytes)
 pkts bytes target     prot opt in     out     source               destination

Code: Select all

root@vpnnn:~# iptables-save
# Generated by iptables-save v1.6.0 on Thu Jun 13 13:51:25 2019
*nat
:PREROUTING ACCEPT [48656:4305598]
:INPUT ACCEPT [6991:1036079]
:OUTPUT ACCEPT [1029:73424]
:POSTROUTING ACCEPT [1358:89530]
-A POSTROUTING -o ens4 -j MASQUERADE
-A POSTROUTING -o ens3 -j MASQUERADE
COMMIT
# Completed on Thu Jun 13 13:51:25 2019
# Generated by iptables-save v1.6.0 on Thu Jun 13 13:51:25 2019
*filter
:INPUT ACCEPT [9052833:982199847]
:FORWARD ACCEPT [21790142:22517472879]
:OUTPUT ACCEPT [16557537:22688780309]
COMMIT
# Completed on Thu Jun 13 13:51:25 2019
# Generated by iptables-save v1.6.0 on Thu Jun 13 13:51:25 2019
*mangle
:PREROUTING ACCEPT [1804259276:1418061587813]
:INPUT ACCEPT [532812691:57256939703]
:FORWARD ACCEPT [1271131631:1360766991873]
:OUTPUT ACCEPT [990481415:1373320415759]
:POSTROUTING ACCEPT [2261621546:2734088415308]
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# Completed on Thu Jun 13 13:51:25 2019
ну и некоторые настройки сервера:

Code: Select all

root@vpnnn:~# cat /proc/sys/net/ipv4/ip_forward
1
root@vpnnn:~# cat /proc/sys/net/ipv4/ip_no_pmtu_disc
0
root@vpnnn:~# cat /proc/sys/net/ipv4/ip_forward_use_pmtu
0
root@vpnnn:~# cat /proc/sys/net/ipv4/conf/all/proxy_arp
0
ну вроде и все... В такой конфигурации все летает. Единственный нюанс в том, что на серверах в сегменте LAN события логируются от имени 192.168.2.103 (маскарад на впн сервере) а необходимо логировать явные айпишки.
убираем правило
-A POSTROUTING -o ens3 -j MASQUERADE (ну или iptables -t nat -D POSTROUTING -s 10.0.0.0/8 -j SNAT --to-source 192.168.2.103)
и примерно четверть филиалов "отваливается", 3/4 продолжает работать и логируют реальные айпишки. Конфигурации микротиков и версии прошивки идентичны за исключением номеров сетей.
На четверти филиалов наблюдается такая картина:
например с машинки 10.11.24.11 вин приложение не может установить https на хост 192.168.2.11 и в тоже время в браузере открывется страничка https с хоста 192.168.2.8 (дефолт гейтвеи на них одинаковые).
пускаем пинг на 192.168.2.11, наблюдаем порядка 10-15 "провалов, потом пинг начинает идти и "вдруг" начинают устанавливаться соединения, на стенде и на 3/4 филиалов никаких проблем не наблюдается.
только на сервисах начинают логироваться реальные айпишки....

Подскажите куда рыть..... идей уже нет:(

P.S.: есил нужны дополнительные данные, скажите какие - выложу.
dimka88
Posts: 866
Joined: 13 Oct 2014, 05:51
Contact:

Re: помогите разобраться с маршрутизацией

Post by dimka88 »

Давайте попробуем схематично отобразить карту сети на draw.io.
Потом нужно посмотреть traceroute не работающих направлений.
xmana
Posts: 7
Joined: 13 Jun 2019, 09:37

Re: помогите разобраться с маршрутизацией

Post by xmana »

да, сейчас попробую изобразить схему, вероятно ззаймет какое-то время, отпишусь
dimka88
Posts: 866
Joined: 13 Oct 2014, 05:51
Contact:

Re: помогите разобраться с маршрутизацией

Post by dimka88 »

Еще посмотрите traceroute до того как убираете правила NAT, на клиентах которые не работают в дальнейшем.
xmana
Posts: 7
Joined: 13 Jun 2019, 09:37

Re: помогите разобраться с маршрутизацией

Post by xmana »

https://drive.google.com/file/d/14b1CG4 ... sp=sharing
схемка примерно такая - тут немного упрощенный вариант, выкинул все, что не влияяет на данный трафик.
трассировка с хоста 10.14.31.11 на 192.168.2.11 при включенном максараде:

Code: Select all

C:\Windows\system32>tracert 192.168.2.11

Tracing route to 192.168.2.11 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  router [10.14.31.1] 
  2    18 ms    17 ms    16 ms  10.255.255.1 
  3    17 ms    17 ms    18 ms  192.168.2.11 

Trace complete.
та же трассировка при выключенном маскараде:

Code: Select all

  1    <1 ms    <1 ms    <1 ms  router [10.14.31.1] 
  2    17 ms    17 ms    16 ms  10.255.255.1 
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        46 ms    17 ms  192.168.2.11 

Trace complete.
  
с пингом примерно та же картина. т.е. 1-5 провалов и пинг начинает идти.
кроме того, если не пускать трассировку или пинг, то хттпс соединение не устанавливается в принципе. там есть апликуха на компах, клиент owncloud, работает по https на 443 порт. - так вот ошибка - таймаут соединения. Ровно до того момента, пока не пройдет первый пинг или трассировка. В браузере на хосте тоже не открываются ни на 80 порт ни на 443 странички на 192.168.2.11, 2.14, .2.8 и т.п., до первого пинга - таймаут соединения.
Такое впечатление, что пинг поднимает маршрутизацию, хотя везде по сути статические маршруты...

Мистика в общем....
dimka88
Posts: 866
Joined: 13 Oct 2014, 05:51
Contact:

Re: помогите разобраться с маршрутизацией

Post by dimka88 »

rp_filter в каком состоянии?

Code: Select all

sysctl net.ipv4.conf.all.rp_filter
С сервера еще сделайте traceroute на 192.168.2.11 и 10.14.31.1
xmana
Posts: 7
Joined: 13 Jun 2019, 09:37

Re: помогите разобраться с маршрутизацией

Post by xmana »

Code: Select all

root@vpnnn:~# sysctl net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 0
закомментировано по дефолту:

Code: Select all

root@vpnnn:~# cat /etc/sysctl.conf | grep rp_filter
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1
маскарад включен:

Code: Select all

root@vpnnn:~# iptables-save | grep MASQ
-A POSTROUTING -o ens4 -j MASQUERADE
-A POSTROUTING -o ens3 -j MASQUERADE

Code: Select all

root@vpnnn:~# traceroute 192.168.2.11
traceroute to 192.168.2.11 (192.168.2.11), 30 hops max, 60 byte packets
 1  192.168.2.11 (192.168.2.11)  0.251 ms  0.231 ms  0.158 ms

Code: Select all

root@vpnnn:~# traceroute 10.14.31.1
traceroute to 10.14.31.1 (10.14.31.1), 30 hops max, 60 byte packets
 1  10.14.31.1 (10.14.31.1)  18.645 ms  19.544 ms  19.670 ms
dimka88
Posts: 866
Joined: 13 Oct 2014, 05:51
Contact:

Re: помогите разобраться с маршрутизацией

Post by dimka88 »

Есть догадки. Я думаю стоит попробовать поставить

Code: Select all

sysctl -w net.ipv4.ip_forward_use_pmtu=1
Разорвать проблемный проблемный тунель, дать возможность ему переустановить соединение.
И на время убрать.

Code: Select all

-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Правила NAT кстати вообще остаются, для доступа клиентов в интернет?
xmana
Posts: 7
Joined: 13 Jun 2019, 09:37

Re: помогите разобраться с маршрутизацией

Post by xmana »

Добрый день!
сорри, были выходные, не имел возможности продолжить разбор полетов....
нат на ван работает, в инет люди ходят нормально, соответственно с айпишкой сервака, на данный момент не играет роли.
с пмту проекспериментирую, отпишусь... сейчас разгребу немного поточку...
спасибо за поддержку...
xmana
Posts: 7
Joined: 13 Jun 2019, 09:37

Re: помогите разобраться с маршрутизацией

Post by xmana »

dimka88 wrote: 15 Jun 2019, 04:05 Есть догадки. Я думаю стоит попробовать поставить

Code: Select all

sysctl -w net.ipv4.ip_forward_use_pmtu=1
Разорвать проблемный проблемный тунель, дать возможность ему переустановить соединение.
И на время убрать.

Code: Select all

-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Правила NAT кстати вообще остаются, для доступа клиентов в интернет?
Доброго дня!

значит по порядку:

Code: Select all

root@vpnnn:~# cat /proc/sys/net/ipv4/ip_forward_use_pmtu
1

Code: Select all

root@vpnnn:~# iptables-save
# Generated by iptables-save v1.6.0 on Wed Jun 19 12:52:08 2019
*mangle
:PREROUTING ACCEPT [1041805723:804140439005]
:INPUT ACCEPT [307363356:31459883031]
:FORWARD ACCEPT [734147934:772465186684]
:OUTPUT ACCEPT [569215988:781109381731]
:POSTROUTING ACCEPT [1303369067:1553575179649]
COMMIT
# Completed on Wed Jun 19 12:52:08 2019
# Generated by iptables-save v1.6.0 on Wed Jun 19 12:52:08 2019
*filter
:INPUT ACCEPT [307363356:31459883031]
:FORWARD ACCEPT [734147934:772465186684]
:OUTPUT ACCEPT [569215988:781109381731]
COMMIT
# Completed on Wed Jun 19 12:52:08 2019
# Generated by iptables-save v1.6.0 on Wed Jun 19 12:52:08 2019
*nat
:PREROUTING ACCEPT [1527201:137782897]
:INPUT ACCEPT [307788:44972367]
:OUTPUT ACCEPT [95370:9462161]
:POSTROUTING ACCEPT [375497:26091651]
-A POSTROUTING -o ens4 -j MASQUERADE
COMMIT
# Completed on Wed Jun 19 12:52:08 2019
т.е. ip_forward_use_pmtu включил, FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu убрал, после рестартнул тунели (systemctl restart accel-ppp.service), маскарад на WAN остался, люди в нет ходят.
К сожалению ситуация не изменилась вообще. пинги - провалов 4 (100% потерь), трейс - провалл два хопа, потом поехал, и после этого поехали хттпс и пинг. Т.е. все то же что и было:(

У мен ятоже небольшие догадки... Ситуация лечится 2-мя способами.
1-й - это маскарад на LAN, что в принципе не приемлемо в моем случае, но работает. В таком случае все пакеты в LAN сегменте ходят от адреса 192.168.2.103, т.е. не используется по факту маршриутизатор на адресе 192.168.2.1.
2-й - это без маскарада, а на конечных серверах ( в данном случае на 192.168.2.11) прописываем маршруты:

Code: Select all

root@drive:~# cat /etc/network/interfaces | grep 'up ip'
up ip ro add 10.0.0.0/8 via 192.168.2.103
up ip ro add 172.16.0.0/12 via 192.168.2.103

Code: Select all

root@drive:~# ip r
default via 192.168.2.1 dev ens3 onlink
10.0.0.0/8 via 192.168.2.103 dev ens3
172.16.0.0/12 via 192.168.2.103 dev ens3
192.168.0.0/22 dev ens3  proto kernel  scope link  src 192.168.2.11
те.. 10-ю сетку маршрутизируем в обход того ж таки 192.168.2.1.... и снова все летает...

что не может не наводить на некоторые подозрения в адрес 192.168.2.1...

больше идей нет...:(
Post Reply