chr.istoph, der Blog

Damit man Router remote vorspielen kann das man im gleichem Netz ist muss man ein wenig Aufwand treiben. Zu erst mal redirencten die Kisten immer dafür muss man die /etc/hosts Datei anpassen. Da man Ports als nicht root nur über halb von 1024 binden kann muss man den Port noch mittels iptables redirecten. Dann kann man den Port via SSH Durchschleifen und die Webseite ist so erreichbar wie der Router das gerne hätte.

/etc/hosts:
127.0.0.1 vodafonemobile.cpe

iptables:
sudo iptables -t nat -I OUTPUT --src 0/0 --dst 127.0.0.1 -p tcp --dport 80 -j REDIRECT --to-ports 8080

ssh auf den Server:
ssh -L 8080:192.168.1.1:80 server

Hier eine Beschreibung für den Speedport

OpenVPN nutzt zur Bestimmung der Maximum Transmission Unit (MTU) ICMP Pakete des Typs 3. Dafür ist es dringend erforderlich das man diese auch an der Firewall zulässt.

If a software or hardware firewall is in place (especially if the firewall is whitelisting connections), make sure it is allowing ICMP Destination Unreachable: Fragmentation Needed (ICMP Type 3, Code 4) into your network. Windows Firewall, by default, has this rule configured, and there is no need to add this rule explicitly on Windows machines.
Quelle: docs.openvpn.net

Wenn man sich das auf dem VPN Server anschaut sieht das so aus:

tcpdump -i eth0 -p icmp
11:01:01.298080 IP 1.1.1.1 > vpn.chr.istoph.de: ICMP 1.1.1.1 unreachable - need to frag (mtu 1418), length 36
11:01:01.298084 IP 1.1.1.1 > vpn.chr.istoph.de: ICMP 1.1.1.1 unreachable - need to frag (mtu 1418), length 36

Als Empfehlung gebe ich mit mindestens die folgende Pakete freizuschalten.

iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT -m comment --comment "ICMP  Echo Reply"
iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT -m comment --comment "ICMP  Destination Unreachable"
iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT -m comment --comment "ICMP  Echo Request"
iptables -A INPUT -p icmp --icmp-type 11 -j ACCEPT -m comment --comment "ICMP  Time Exceeded"

Nach der Neuinstallation konnte ich auf keine Updateserver zugreifen, da IPv6 nicht mehr funktionierte. So schreib ich folgende Nachricht an den Support:
Nach dem Neuaufsätzen des Servers ist mit den von Ihnen voreingestellten
Konfigurationen keine IPv6 Kommunikation möglich:
iface eth0 inet6 static
address 2a01:4f8:
...

Eine halbe Stunde später bekam ich die nachreicht das alles wieder funktioniert.
könnten Sie bitte prüfen, ob das Problem weiterhin besteht?

Keine 24 Stunden später funktionierte dann aber nichts mehr und mir wurde einfach das Netz gekappt und ein neues zugewiesen:
bei der IPv6 Überprüfung unseres Netzbereiches ist uns aufgefallen
das Sie ein falsches IPv6 Netz benutzen. Dieses ist nicht für den
aktuellen Standort Ihres Servers vorgesehen. Wir bitten Sie Ihre
Konfiguration anzupassen und das alte Subnetz von Ihrem Server zu entfernen.

Es handelt sich dabei um den Server EQ 4 - RZ 14 und
das nicht mehr gültige dem IPv6 Netz: 2a01:4f8

Mann kann es sich auch echt einfach machen. Da dies bei mir nun wieder zu Problemen führt Interessiert Hetzner gar nicht erst. Den jetzt muss ich wieder Firewalls und DNS anpassen, was recht ärgerlich ist da DNS Einträge bekanntlich bis zu 24 Stunden brauchen.

Es passiert immer wieder das irgendein Depp im Wohnheimnetz einen DHCP Server anschließt. Dies kann zur folge haben das Bewohner aufgrund einer falschen IP und default route kein Internet haben, im schlimmsten Fall kann man dadurch man in the middle attacken fahren.

Mittels dhcping bekommt man heraus welche DHCP Server im Netz antworten verteilen. So ist schnell ein Übeltäter lokalisiert.
dhcping -s 255.255.255.255 -r -v

Um dieses Problem aber generell in den Griff zu bekommen haben ich auf dem Cisco Switch DHCP snooping eingerichtet. Dafür habe ich erst alle möglichen Server Ports freigeschaltet. So kann es nicht Passieren das bei Umbauarbeiten am Netzwerk keiner mehr eine DHCP Adresse bekommt. Anschließend habe ich für das gesamte 240 VLAN das dhcp snooping aktiviert.

switch(config)#interface range GigabitEthernet 2/1-48
switch(config-if-range)#ip dhcp snooping trust
switch(config-if-range)#exit
switch(config)#ip dhcp snooping vlan 240
switch(config)#do show ip dhcp snooping

Switch DHCP snooping is disabled
DHCP snooping is configured on following VLANs:
none
Insertion of option 82 is enabled
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Interface Trusted Rate limit (pps)
------------------------ ------- ----------------
GigabitEthernet2/1 yes unlimited


Beim Neuaufsätzen unseres Graphen Servers konnte snmpget keine Daten mehr von den Switches empfangen und schmiss folgende Fehlermeldung, das ein Modul nicht vorhanden sei.

/usr/bin/snmpget -v1 -c pw localhost -Oq IF-MIB::ifDescr.1
MIB search path: /root/.snmp/mibs:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
Cannot find module (IF-MIB): At line 0 in (none)
IF-MIB::ifDescr.1: Unknown Object Identifier


Nach etwas strace und apt-file seach Pfand ich heraus auf welle Module snmpget zugreifen wollte. Diese konnten mit dem nachinstallierten von snmp-mibs-downloader behoben werden.

apt-get install snmp-mibs-downloader