PPPoE

aus PUG, der Penguin User Group
Wechseln zu: Navigation, Suche

PPPoE

Unter PPPoE versteht man PPP over Ethernet. Diese Protokoll wird als Zugangsprotokoll für IP über DSL verwendet. PPP dient hier nur als Authentifizierungsmöglichkeit beim Provider, der will ja wissen, wer sich da einwählt. Unter Debian sind zunächst folgende Pakete zu installieren:

  • ppp
  • pppoe

Unter /etc/ppp sind alle relevanten Konfigurationsdateien zu finden. Aus Sicherheitsgründen sollten Verzeichnisse die Rechte -rwx------ (0700) und Dateien -rw------- (0600) haben. Hier werden nämlich auch Usernamen und Passwörter gespeichert, deren Verwendung möglicherweise Kosten verursachen (Volumen-/Zeittarife).

Benutzerkennung

Vom Provider gibt es einer Benutzerkennung und ein Passwort, diese sind in den Dateien pap-secrets bzw. chap-secrets einzutragen. Wie der Dateiname schon sagt, wird pap-secrets für PAP Authentifizierung und chap-secrets für die CHAP Authentifizierung verwendet. Auf der sicheren Seite ist man, wenn beide Dateien konfiguriert werden. Bei freenet.de war schon festzustellen, dass manchmal nur PAP funktioniert hat und manchmal nur CHAP. Die Hotlines mancher Provider sind auch mit der Frage PAP oder CHAP überfordert. Beide Dateien haben das gleiche Format, hier wurden mal zwei Provider konfiguriert: 

"username@irgendein.provider" * "geheim"
"irgendeinandererprovider/username" * "geheim"

PPPoE Optionen

Unter /etc/ppp/peers muss eine Datei dsl-provider vorhanden sein. Hier werden die Parameter der jeweiligen Verbindung konfiguriert. Im folgenden Beispiel sind alle relevanten Parameter gesetzt, es wird einer der beiden Provider aus das pap-secrets verwendet. 

user username@irgendein.provider           # Der zu verwendende Username
                                           # (eigentlich handelt es sich um einen Hostnamen)
pty "/usr/sbin/pppoe -I eth1 -T 80"        # Es wird eth1 verwendet, Timeout 80s
                                           # Im Falle von MTU Problemen sollte noch der Parameter
                                           # -m 1412 angegeben werden
noipdefault                                # Die IP Adresse kommt vom Provider
# usepeerdns                               # Falls DNS des ISPs benutzt werden soll
                                           # In NRW auf jeden Fall eigenen DNS aufsetzen
                                           # wegen der dortigen Zensur
defaultroute                               # die Defaultroute auch
hide-password
lcp-echo-interval 20                       # LCP Echos alle 20s
lcp-echo-failure 3                         # Bleiben die LCP Echos 3*20s aus,
                                           # dann ist die Verbindung als tot anzusehen
connect /bin/true                          # Kein connect Skript
noauth                                     # ISP braucht sich nicht zu authentifizieren
persist                                    # Verbindung automatisch wieder aufbauen
                                           # Nicht bei Arcor und Zeittarifen verwenden !!!
noaccomp                                   # Keine Address-and-Control-Field-Compression
default-asyncmap                           # Asynchronous-Control-Character-Map

Das Thema MTU scheint ohnehin einige Provider zu überfordern, häuft übermittelt der ISP Router eine falsche MTU, was dann zu Problemen bei Datenpaketen ab so 1450 Bytes führen kann. Das muss nämlich entweder im Radiusserver oder dem Router des ISP korrekt konfiguriert werden, was oft genug unterbleibt.

Jetzt sollte es möglich sein, mit pon die Verbindung zu aktivieren. Wenn alles funktioniert, dann sollte im syslog etwa folgendes stehen (natürlich andere IP-Adressen): 

Feb 20 03:00:07 my-gw pppd[5913]: pppd 2.4.3 started by root, uid 0
Feb 20 03:00:07 my-gw pppd[5913]: Serial connection established.
Feb 20 03:00:07 my-gw pppd[5913]: using channel 244
Feb 20 03:00:07 my-gw pppd[5913]: Using interface ppp0
Feb 20 03:00:07 my-gw pppd[5913]: Connect: ppp0 <--> /dev/pts/0
Feb 20 03:00:07 my-gw pppoe[5914]: PADS: Service-Name: ''
Feb 20 03:00:07 my-gw pppoe[5914]: PPP session is 675
Feb 20 03:00:08 my-gw pppd[5913]: PAP authentication succeeded
Feb 20 03:00:08 my-gw pppd[5913]: local  IP address 192.168.123.234
Feb 20 03:00:08 my-gw pppd[5913]: remote IP address 10.47.58.1
Feb 20 03:00:08 my-gw pppd[5913]: Script /etc/ppp/ip-up started (pid 5925)
Feb 20 03:00:08 my-gw pppd[5913]: Script /etc/ppp/ip-up finished (pid 5925), status = 0x0

Erste Tests

Nun sollte man sich davon überzeugen, dass eine Verbindung zum Internet besteht. Erstmal wird festgestellt, welche IP Adresse wir haben: 

my-gw# ip addr list dev ppp0
254: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 3
    link/ppp
    inet 192.168.123.234 peer 10.47.58.1/32 scope global ppp0

Ein cat /etc/resolv.conf sollte Klarheit darüber verschaffen, ob und welche DNS Server verwendet werden. Ein Blick in die Routingtabelle kann auch nicht schaden: 

my-gw:/etc/ppp/peers# ip route list
10.47.58.1 dev ppp0  proto kernel  scope link  src 192.168.123.234
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1
default via 10.47.58.1 dev ppp0

Wie man sieht, gibt es nun eine Defaultroute in das Internet. Ein Ping sollte nun letzte Zweifel zerstreuen: 

my-gw:/etc/ppp/peers# ping www.heise.de
PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp_seq=1 ttl=250 time=12.8 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=2 ttl=250 time=14.1 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=3 ttl=250 time=12.7 ms
--- www.heise.de ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 12.742/13.269/14.169/0.646 ms

my-gw:/etc/ppp/peers# ping -s 2000 www.heise.de
PING www.heise.de (193.99.144.85) 2000(2028) bytes of data.
2008 bytes from www.heise.de (193.99.144.85): icmp_seq=1 ttl=250 time=54.8 ms
2008 bytes from www.heise.de (193.99.144.85): icmp_seq=2 ttl=250 time=56.6 ms
--- www.heise.de ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 54.866/55.761/56.657/0.926 ms

Mit der Option -s 2000 konnte auch festgestellt werden, dass die MTU "passt".

IP-NAT

Damit auch das LAN etwas davon hat, soll unsere Linux Box auch routen und die RFC1918 Adressen übersetzen. Dazu ist auch nur ein wenig Handarbeit erforderlich. Das Paket iptables wird ja von Debian bereits per Default installiert. Erstmal muss dem Kernel gesagt werden, dass er auch routen soll, denn das macht er sonst nicht: 

echo "1" > /proc/sys/net/ipv4/ip_forward

erledigt das. Jetzt müssen die LAN Adressen noch via NAT in die vom Provider vergebene IP Adresse umgesetzt werden. Das macht iptables: 

iptables -A POSTROUTING -s 192.168.0.0/255.255.255.0 -j MASQUERADE

Es sei noch angemerkt, dass bestimmte Anwendungen neu gestartet werden müssen, wenn sich die IP ändert:

  • ntpd stürzt ab, wenn sich die IP ändert. Ein Neustart /etc/init.d/ntp-server restart genügt.
  • bind (alle Versionen) kann die Antworten nicht mehr empfangen, wenn sich die Internet IP geändert hat. Auch hier sollte sich das Problem mit /etc/init.d/bind restart lösen lassen.
  • Wer ganz sicher gehen will, kann auch alle Serveranwendungen, die auf dem ppp Interface laufen, neu starten. Anwendungen, die z.B. nur an lo gebunden sind, betrifft das natürlich nicht.

Wer einen Provider nutzt, der statische IP Adressen vergibt, sollte stattdessen 

iptables -A POSTROUTING -s 192.168.0.0/255.255.255.0 -j SNAT --to-source <provider-ip>

verwenden. Die Verbindungsunterbrechung stört die o.g. Anwendungen nicht, daher ist kein Neustart der Anwendungen erforderlich.

Sicherheit

Es ist nun nicht so schön, wenn das ganze Internet alle Samba Shares oder sonstwas sieht. Daher sollte der Router mit den folgenden Maßnahmen gesichert werden:

  • Alle nicht benötigten Dienste abschalten, ein Blick in /etc/inetd, /etc/xinetd.conf und /etc/xinetd.d hilft hier weiter, oder inetd bzw. xinetd gleich ganz abschalten.
  • MySQL gehört auch zu den üblichen verdächtigen, wenn es schon laufen muss, dann sollte in my.cnf wenigstens bind-address = 127.0.0.1 stehen, oder TCP Verbindungen ganz abschalten, über UNIX Sockets geht es ja auch.
  • Ein lsof -i -P -n zeigt alles an, was auf IP Pakete lauscht
  • In der /etc/ssh/sshd.conf sollten zumindest stehen:
    • Protocol 2
    • RhostsRSAAuthentication no
    • HostbasedAuthentication no
    • PermitEmptyPasswords no
    • ChallengeResponseAuthentication no
    • PasswordAuthentication no

Bei SSH Zugang aus dem Internet sollte nichts anderes als private/public Key Authentifizierung benutzt werden.

Accesslisten

Als zweite Maßnahme werden Accesslisten gesetzt: 

iptables -P INPUT DROP
iptables -A INPUT -s 127.0.0.0/255.0.0.0 -j ACCEPT
iptables -A INPUT -s 192.168.0.0/255.255.0.0 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 32768:61000 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 32768:61000 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.0.0/255.255.255.0 -j ACCEPT
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i ppp0 -m state --state NEW,INVALID -j DROP
iptables -A FORWARD -o ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -A FORWARD -j REJECT --reject-with icmp-admin-prohibited

Diese Accessliste verwendet die Policy "es ist alles verboten, was nicht ausdrücklich erlaubt ist". Das LAN (192.168.0.0/24) und localhost dürfen alles. Da der Beispielrechner mehr als 256MB RAM hat, liegen die default local Ports im Bereich 32768-61000. Man kann das mit cat /proc/sys/net/ipv4/ip_local_port_range feststellen. Der dort angezeigte Bereich muss freigegeben werden, sonst funktioniert z.B. ftp nicht. Alle Welt darf auf den SSH. Falls nötig, können auch SMTP, HTTP(S), POP3 und IMAP4 aufgemacht werden. Es sollte allerdings immer genau überlegt werden, ob die ganze Welt Zugriff benötigt. Die FORWARD Regeln legen hier fest, das das LAN zwar uneingeschränkt in das Internet darf, aber Zugriffe aus dem Internet ins LAN verboten sind. Mit diesem Beispiel ist dann das Gröbste gemacht, im Einzelfall muss noch entschieden werden, ob wirklich aus dem LAN alles Richtung Internet erlaubt sein sollte.

Nun sollten alle Clients in unserem Beispielnetz 192.168.0.0/24 einen Ping auf z.B. www.heise.de machen können. Auch hier muss zur Kontrolle der MTU der Versuch mit -s 2000 wiederholt werden.Benutzer:Christian

Abgerufen von „https://www.pug.org/mediawiki/index.php?title=PPPoE&oldid=7042“