Я установил на шлюзе соединение клиента 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&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-адреса являются реальными.
Я наконец решил это. Пакеты отбрасываются сетевым фильтром (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 Это маскирует все, что выходит из вашего обычного интерфейса, среди которых будут пакеты NATted с вашего хоста Yosemite.
Меня поразило, что это единственное слабое место в вашей дискуссии выше. После некоторых поисков я смог убедиться, что это действительно так, прочитав эту вики-страницу Debian . На этот раз мой любимый Arch Linux Wiki бросил меня.