Как перенаправить трафик локальной сети к клиентскому соединению L2TP/IPsec на шлюзе?

Я установил на шлюзе соединение клиента L2TP/IPsec и пытаюсь перенаправить свой хост в локальной сети, чтобы использовать это соединение при доступе в Интернет.

Вот топология сети.

топология сети

Это таблица маршрутизации моего шлюза:

$ ip route
default dev pppoe-wan  scope link 
1.0.0.1 dev ppp1  proto kernel  scope link  src 192.168.179.11
6.6.6.6 dev pppoe-wan  scope link 
5.5.5.5 dev pppoe-wan  proto kernel  scope link  src 5.5.5.5
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1 

$ ip rule
1:  from all lookup local 
10: from 192.168.1.2 lookup 10 
32766:  from all lookup main 
32767:  from all lookup default 

$ ip route show table 10
default dev ppp1  scope link 
6.6.6.6 via 5.5.5.5 dev pppoe-wan 
192.168.1.0/24 via 192.168.1.1 dev br-lan

Проблема в том, что после добавления маршрута по умолчанию в таблицу 10 мой хост больше не может выходить в Интернет. Использование tcpdump для прослушивания интерфейса ppp1 (tcpdump -i ppp1) показывает, что через него не проходят никакие пакеты.

Я попытался замаскировать интерфейс ppp1:

$ iptables -t nat -A POSTROUTING -o ppp1 -j MASQUERADE

Это не помогло, до сих пор пакеты не проходили через интерфейс. Также ядру разрешено перенаправлять пакеты:

$ cat /proc/sys/net/ipv4/ip_forward
1

Но если я использую интерфейс непосредственно на шлюзе, он работает просто отлично:

$ curl --interface ppp1 google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.com.hk/?gfe_rd=cr&amp;ei=suORVbLfOKXC8Af3noGwDA">here</A>.
</BODY></HTML>

Похоже, ядро ​​Linux шлюза каким-то образом сбросило пакеты с моего хоста. Но ни в одном интерфейсе не включена фильтрация обратного пути:

$ cat /proc/sys/net/ipv4/conf/ppp1/rp_filter
0

$ cat /proc/sys/net/ipv4/conf/pppoe-wan/rp_filter
0

Так что я в своем уме. Почему трафик хоста никогда не проходит через ppp1? Как я могу перенаправить свой хост к клиентскому соединению L2TP/IPsec?

Я использовал ту же конфигурацию для клиента PPTP, и она работала просто отлично. Как-то это не работает для клиента L2TP/IPsec.

Шлюз представляет собой коробку OpenWrt (Chaos Calmer 15.05-rc2, ядро ​​3.18.14). Я использую strongSwan(5.3.0) + xl2tpd(1.3.6) для настройки клиента L2TP/IPsec.

Это конфигурация для strongSwan:

conn example
    auto=start
    keyexchange=ikev1
    type=transport
    left=%defaultroute
    leftauth=psk
    right=server.example.com
    rightid=%any
    rightauth=psk
    dpdaction=restart
    dpddelay=10s
    dpdtimeout=60s

и конфигурация для xl2tpd

[lac example]
lns = server.example.com
length bit = yes
redial = yes
max redials = 5
pppoptfile = /etc/ppp/options.xl2tpd

и конфигурация для ppp

noauth
mru 1452
mtu 1452
nomppe
ipcp-accept-remote
ipcp-accept-local
nopcomp
noaccomp
lcp-echo-interval 10
lcp-echo-failure 5

Хост - это Mac (Yosemite 10.10.3).

Заранее спасибо за помощь.

PS Только IP-адрес шлюза и IP-адрес сервера были заменены поддельными IP-адресами, все остальные IP-адреса являются реальными.

Источник

2 ответа

Решение

Я наконец решил это. Пакеты отбрасываются сетевым фильтром (iptables).

OpenWrt по умолчанию отбрасывает пакеты, пересылаемые с br-lan. Поэтому нам нужно разрешить пересылку пакетов из br-lan в ppp1.

$ iptables -I FORWARD -i br-lan -o ppp1 -j ACCEPT

После этого хозяин получает доступ в интернет.

Обратите внимание, что вам нужно использовать -I так что это правило вставляется перед правилом удаления, что делает его приоритетным.

Источник

Вы маскируете не тот интерфейс. Вы должны маскироваться, потому что, по сути, вы НАСТАИВАЕТЕ, но виртуальный интерфейс не может быть напрямую маскирован.

Вместо этого вы должны использовать:

      iptables -t nat -A POSTROUTING -o pppoe-wan -j MASQUERADE

Это маскирует все, что выходит из вашего обычного интерфейса, среди которых будут NAT-пакеты от вашего хоста Yosemite.

Меня поразило, что это единственное слабое место в вашей дискуссии выше. После некоторых поисков я смог подтвердить, что это действительно так, прочитав эту веб-страницу Debian Wiki. На этот раз моя любимая Arch Linux Wiki бросила меня.

Источник
Другие вопросы по тегам