LINUX.ORG.RU
Форум — General  

debian: vpn+route?=проблема


0

0

Есть "белые" сетевые реквизиты и есть "серые" -- для VPN-соединения. Последнее успешно устанавливается, но после этого перестает пинговаться "белый" шлюз: подробнее...

Обычные сетевые реквизиты от провайдера:

IP 87.224.188.198

GW 87.224.188.193

Реквизиты для VPN

IP 10.0.107.56

GW 10.0.107.1

На интерфейсе eth1 в /etc/network/interfaces прописаны VPN-реквизиты -- IP, GW и маска. При этом пинг до 87.224.188.193 естественно проходит. Я делаю pppd call provider -- появляется интерфейс ppp0, дальше я добавляю "себя"

route add default gw 87.224.188.198

но пинга до 87.224.188.193 (как и в другие места) тупо нет.

На eth1 должна быть сетка провайдера, впн заворачивается в tun0 или wlan0. И роутить надо не в 87.блаблабла а в тот самый впн.

one117 ★★★★★
() 

route add -host 172.21.128.7 gw IP_GW
route del default
/usr/sbin/pppd call vpn

127.21.128.7 - мой сервер, где авторизация порходит
IP_GW - шлюз в локалку

Freek ★
() 

eth0      Link encap:Ethernet  HWaddr 00:16:D4:CF:97:4C
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:66

eth1      Link encap:Ethernet  HWaddr 00:19:D2:3B:36:40
          inet addr:10.0.107.56  Bcast:10.0.107.255  Mask:255.255.255.0
          inet6 addr: fec0::8:219:d2ff:fe3b:3640/64 Scope:Site
          inet6 addr: 2002:57e0:acfb:8:219:d2ff:fe3b:3640/64 Scope:Global
          inet6 addr: fe80::219:d2ff:fe3b:3640/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:84876 errors:0 dropped:170 overruns:0 frame:0
          TX packets:1728 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10263153 (9.7 MiB)  TX bytes:139671 (136.3 KiB)
          Interrupt:193 Base address:0xa000 Memory:d2100000-d2100fff

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:118 errors:0 dropped:0 overruns:0 frame:0
          TX packets:118 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8468 (8.2 KiB)  TX bytes:8468 (8.2 KiB)

ppp0      Link encap:Point-to-Point Protocol
          inet addr:87.224.188.198  P-t-P:172.30.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:18 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:1472 (1.4 KiB)  TX bytes:32 (32.0 b)

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.30.0.1      0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
10.0.107.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         87.224.188.198  0.0.0.0         UG    0      0        0 ppp0
0.0.0.0         10.0.107.1      0.0.0.0         UG    0      0        0 eth1

Unforgiven ★
() автор топика
Ответ на: комментарий от v12aml

хотя поясни что за vpn

это доступ в удаленную сетку (я привел решение проблемы для этого варианта), или через него трафик в инет должен ходить (маловероятно, но мало ли)?

v12aml ★★
()

понял свою ошибку
ip r d default via 10.0.107.1
ip r a 10.0.0.0/8 via 10.0.107.1
адрес vpn сервера скажи, а то нифига не понятно

v12aml ★★
()
Ответ на: комментарий от v12aml 

Под виндой все работает: там таблица маршрутизации выглядит так

===========================================================================
Список интерфейсов
0x1 ........................... MS TCP Loopback interface
0x2 ...00 e0 4d 01 d8 8f ...... Realtek RTL8139 Family PCI Fast Ethernet NIC - ╠шэшяюЁЄ яырэшЁют∙шър яръхЄют
0x3 ...00 17 31 51 95 63 ...... Intel(R) PRO/1000 PL Network Connection - ╠шэшяюЁЄ яырэшЁют∙шър яръхЄют
0x4 ...00 ff 75 74 c5 61 ...... TAP-Win32 Adapter V8 - ╠шэшяюЁЄ яырэшЁют∙шър яръхЄют
0x40006 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0       10.0.107.1     10.0.107.56	  21
          0.0.0.0          0.0.0.0   87.224.188.198  87.224.188.198	  1
         10.0.0.1  255.255.255.255       10.0.107.1     10.0.107.56	  20
       10.0.107.0    255.255.255.0      10.0.107.56     10.0.107.56	  20
      10.0.107.56  255.255.255.255        127.0.0.1       127.0.0.1	  20
   10.255.255.255  255.255.255.255      10.0.107.56     10.0.107.56	  20
   87.224.188.198  255.255.255.255        127.0.0.1       127.0.0.1	  50
   87.255.255.255  255.255.255.255   87.224.188.198  87.224.188.198	  50
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1	  1
        224.0.0.0        240.0.0.0      10.0.107.56     10.0.107.56	  20
        224.0.0.0        240.0.0.0   87.224.188.198  87.224.188.198	  1
  255.255.255.255  255.255.255.255      10.0.107.56     10.0.107.56	  1
  255.255.255.255  255.255.255.255   87.224.188.198               2	  1
  255.255.255.255  255.255.255.255   87.224.188.198  87.224.188.198	  1
  255.255.255.255  255.255.255.255   87.224.188.198               4	  1
Основной шлюз:      87.224.188.198
===========================================================================
Постоянные маршруты:
  Отсутствует

Unforgiven ★
() автор топика
Ответ на: комментарий от v12aml

2 v12aml -- респект. Заработало :)

Три вопроса:

1) Курил man ip -- просветления не настало, можно пояснить что сие значит? :)

2) Как избавиться от этого танца с бубном? Ну то есть как не делать этого руками при каждом соединении?

3) До этого в lenny (а сейчас это был etch) я готов поклясться, что я просто делал

route add default gw 87.224.188.198

и все работало. Может ли быть так, что в разных версиях (ppp, pptp илм вообще системы) по-разному?

Unforgiven ★
() автор топика
Ответ на: комментарий от Unforgiven

все крайне просто:

у тебя сервер vpn находится вне твоей подсетки (которая на eth1), маршрут до той подсетки, где vpn у тебя указан как default через 10.0.107.56 после поднятия тоннеля появляется ВТОРОЙ default второй поднятый маршрут является более приоритетным в результате пакеты до VPN-сервера просто перестают доходить

решение - прописать не default, а нормальный маршрут до сетки с vpn-сервером (ip r a 10.0.0.0/8 via 10.0.107.1) и удалить нах никому не нужный default

проблема очень частая

v12aml ★★
()
Ответ на: комментарий от v12aml

в винде работает так как во-первых новоподнятый default имеет метрику не

во-вторых у нее там искуственный интеллект :) она понимает, что если до vpn сервака надо ходить через старый деволт, то это НАДО делать, не смотря на то, что в таблице маршрутизации после поднятия VPN указано совсем другое :)

v12aml ★★
()
Ответ на: комментарий от v12aml

И все-таки моя была прав :) После успешного обнлвления до lenny достаточно сделать шлюзом себя -- и все работает. Но тебе все равно огромное спасибо! :)

Unforgiven ★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
General