Ich habe eine L2TP / IPsec-Clientverbindung auf dem Gateway hergestellt, und ich versuche, meinen Host im LAN umzuleiten, um diese Verbindung beim Zugriff auf das Internet zu verwenden.
Hier ist die Netzwerktopologie.
Dies ist die Routing-Tabelle meines Gateways:
$ 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 Das Problem ist, dass mein Host nach dem Hinzufügen der Standardroute zu Tabelle 10 nicht mehr auf das Internet zugreifen kann. Die Verwendung von tcpdump zum Abhören der Schnittstelle ppp1 ( tcpdump -i ppp1) zeigt, dass keine Pakete durch sie laufen .
Ich habe versucht, die ppp1-Schnittstelle mit zu maskieren:
$ iptables -t nat -A POSTROUTING -o ppp1 -j MASQUERADE Es hat nicht geholfen, dennoch flossen keine Pakete durch die Schnittstelle. Der Kernel darf auch Pakete umleiten:
$ cat /proc/sys/net/ipv4/ip_forward 1 Wenn ich die Schnittstelle jedoch direkt am Gateway verwende, funktioniert das problemlos:
$ 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> So wie es aussieht, hat der Linux-Kernel des Gateways irgendwie die Pakete von meinem Host verworfen. Bei keiner der Schnittstellen ist die umgekehrte Pfadfilterung aktiviert:
$ cat /proc/sys/net/ipv4/conf/ppp1/rp_filter 0 $ cat /proc/sys/net/ipv4/conf/pppoe-wan/rp_filter 0 Ich bin also am Ende meines Verstandes. Warum durchläuft der Host-Verkehr niemals ppp1? Wie kann ich meinen Host zur L2TP / IPsec-Clientverbindung umleiten?
Ich habe dieselbe Konfiguration für einen PPTP-Client verwendet, und es hat gut funktioniert. Irgendwie funktioniert es nicht für einen L2TP / IPsec-Client.
Das Gateway ist eine OpenWrt-Box (Chaos Calmer 15.05-rc2, Kernel 3.18.14). Ich verwende strongSwan (5.3.0) + xl2tpd (1.3.6), um den L2TP / IPsec-Client einzurichten.
Dies ist die Konfiguration für 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 und Konfiguration für xl2tpd
[lac example] lns = server.example.com length bit = yes redial = yes max redials = 5 pppoptfile = /etc/ppp/options.xl2tpd und Konfiguration für PPP
noauth mru 1452 mtu 1452 nomppe ipcp-accept-remote ipcp-accept-local nopcomp noaccomp lcp-echo-interval 10 lcp-echo-failure 5 Der Host ist ein Mac (Yosemite 10.10.3).
Vielen Dank im Voraus für die Hilfe.
PS Nur die Internet-IP des Gateways und die Internet-IP des Servers wurden durch gefälschte IPs ersetzt, alle anderen IPs sind die tatsächlich verwendeten.
Ich habe es endlich gelöst. Die Pakete werden von netfilter (iptables) verworfen.
OpenWrt löscht standardmäßig Pakete, die von br-lan weitergeleitet werden. Wir müssen also die Weiterleitung von Paketen von br-lan nach ppp1 zulassen.
$ iptables -I FORWARD -i br-lan -o ppp1 -j ACCEPT Danach erhält der Host Internetzugang.
Beachten Sie, dass Sie -Idiese Regel verwenden müssen, damit diese Regel vor der Löschregel eingefügt wird, sodass sie Vorrang hat.
Sie maskieren die falsche Schnittstelle. Sie müssen sich maskieren, da Sie im Grunde NATTING sind, die virtuelle Schnittstelle jedoch nicht direkt maskiert werden kann.
Verwenden Sie stattdessen:
iptables -t nat -A POSTROUTING -o pppoe-wan -j MASQUERADE Dadurch wird alles maskiert, was sich aus Ihrer regulären Benutzeroberfläche ergibt. Darunter befinden sich die NATted-Pakete Ihres Yosemite-Hosts.
Es fiel mir auf, dass dies der einzige Schwachpunkt in Ihrer obigen Diskussion ist. Nach einiger Suche konnte ich bestätigen, dass dies tatsächlich der Fall sein sollte, indem ich diese Debian-Wiki-Webseite lese . Mein geliebtes Arch Linux Wiki hat mich ausnahmsweise mal im Stich gelassen.