Telekom (FON) Hotspot DNS-Server bzw. Port 53 gesperrt
4 years ago
Hallo,
ich glaube zwar nicht, dass etwas geändert wird, aber ich möchte dieses Verhalten gerne dokumentieren. Es hat mich einige Zeit gekostet herauszufinden, warum nichts funktioniert.
Ich bin am Telekom FON Hotspot und weil die Google-DNS-Server 8.8.8.8 bei mir standardmäßig eingestellt sind, ging kein Internet, bis ich gemerkt habe, dass es an den DNS-Servern liegt. Soetwas ist mir bis jetzt noch nicht untergekommen. Ich hatte schon Hotspots da wird Port 53 transparent auf den eigenen DNS-Server umgeleitet, was auch nicht in Ordnung ist, aber fremde DNS-Server sperren, das geht gar nicht.
Beweise:
1. Fremde DNS-Server nicht erreichbar
dig telekom.de @8.8.8.8
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> telekom.de @8.8.8.8
;; global options: +cmd
;; connection timed out; no servers could be reached
dig telekom.de @9.9.9.9
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> telekom.de @9.9.9.9
;; global options: +cmd
;; connection timed out; no servers could be reached
Über den von der Telekom ausgelieferten DNS-Server funktioniert es
dig telekom.de
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> telekom.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23639
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;telekom.de. IN A
;; ANSWER SECTION:
telekom.de. 293 IN A 80.158.67.40
;; Query time: 20 msec
;; SERVER: 172.17.2.1#53(172.17.2.1)
;; WHEN: Fr Mai 21 15:54:35 CEST 2021
;; MSG SIZE rcvd: 55
Traceroute via UDP und Port 53 (=DNS) zu Quad 9 DNS und Google-DNS wird gefiltert
traceroute -U -p 53 9.9.9.9
traceroute to 9.9.9.9 (9.9.9.9), 30 hops max, 60 byte packets
1 172.17.2.1 (172.17.2.1) 6.894 ms 7.826 ms 7.697 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 *^C
traceroute -U -p 53 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 172.17.2.1 (172.17.2.1) 5.676 ms 5.359 ms 6.549 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 *^C
Ein normaler Traceroute ohne UDP Port 53 geht problemlos durch
traceroute 9.9.9.9
traceroute to 9.9.9.9 (9.9.9.9), 30 hops max, 60 byte packets
1 172.17.2.1 (172.17.2.1) 18.624 ms 19.520 ms 19.364 ms
2 10.18.0.1 (10.18.0.1) 39.710 ms 47.762 ms 47.609 ms
3 172.23.49.22 (172.23.49.22) 43.031 ms 54.572 ms 56.314 ms
4 80.157.129.245 (80.157.129.245) 87.955 ms 89.562 ms 91.908 ms
5 pd900c966.dip0.t-ipconnect.de (217.0.201.102) 91.763 ms 93.516 ms 94.979 ms
6 80.157.200.214 (80.157.200.214) 94.825 ms 71.560 ms 79.050 ms
7 dns9.quad9.net (9.9.9.9) 70.909 ms !X 26.437 ms 24.583 ms !X
traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 172.17.2.1 (172.17.2.1) 11.184 ms 10.865 ms 12.109 ms
2 10.18.0.1 (10.18.0.1) 27.104 ms 28.473 ms 44.129 ms
3 172.23.49.22 (172.23.49.22) 36.698 ms 36.559 ms 37.500 ms
4 80.157.129.245 (80.157.129.245) 44.782 ms 44.637 ms 46.279 ms
5 217.5.116.98 (217.5.116.98) 485.280 ms 487.583 ms 488.462 ms
6 80.150.170.30 (80.150.170.30) 48.675 ms 49.946 ms 51.409 ms
7 108.170.251.193 (108.170.251.193) 49.306 ms 27.016 ms 108.170.251.129 (108.170.251.129) 27.096 ms
8 142.250.214.197 (142.250.214.197) 26.939 ms 142.250.46.249 (142.250.46.249) 34.241 ms 142.251.64.181 (142.251.64.181) 30.412 ms
9 dns.google (8.8.8.8) 36.207 ms 37.953 ms 38.848 ms
Fazit: Die Telekom sperrt zumindest an den Telekom FON Hotspots fremde DNS-Server aus. Das finde ich alles andere als in Ordnung. Mit solchen Infrastrukturen eröffnet man DNS-Manipulation wie bei s.to, Überwachung und Zensur Tür und Tor.
960
6
This could help you too
5 years ago
1619
0
2
1224
0
4
4 years ago
293
0
4
4 years ago
Ich habe aus Neugier mal in die Telekom - FON AGB reingeschaut.
Es wird ein Zugang zum "kabellosen Surfen" bereitgestellt und kein "uneingeschränkter Internetzugriff".
Somit gehe ich mit Deiner Aussage "das geht garnicht" nicht konform, da es sich nicht um eine zugesicherte Eigenschaft handelt.
Portsperren sind an Hotspots übliche Praxis. Ich finde oft Hotspots, bei denen gerade eben nur die remote Ports für Web und Mail offen sind. DNS ist häufiger umgeleitet oder gesperrt. Zugriff auf IPSecVPN ist meist auch gesperrt.
Aus diesem Grund habe ich explizit einen OpenVPN-Server laufen auf Port 443. Damit umgehe ich dann die meisten Beschränkungen solcher Spots. DNS-Anfragen muss man dann natürlich auch tunneln. Nicht optimal von der Latenz, aber es geht.
1
Answer
from
4 years ago
Sicherlich hast du aus rein rechtlicher Sicht Recht. Nur finde ich dieses Verhalten weiterhin nicht in Ordnung. Es kostet Zeit und Geld zusätzliche Portsperren einzurichten. Auch braucht man dafür mehr Hardware. Das treibt alles die Kosten in die Höhe und die Nutzer verägert es. Wenn weitere Ports gesperrt sind, geht ganz schnell keine Whatsapp-Telefonie, Wifi-Calling oder auch Dienste wie Jitsi.
Von daher kann ich es nicht verstehen, dass man die Nutzer mit solchen Maßnahmen behelligt. Das klappt aus meiner Sicht auch nur so gut, weil dem Standardnutzer das technische Verständnis dafür fehlt. Wenn die Leute die Hotline mit Anrufen deswegen überfluten würden, würde es ganz schnell funktionieren.
Unlogged in user
Answer
from
4 years ago
Hallo @Zufall Rainer ,
an deiner Stelle würde ich keine Zeit mehr in dieses Thema stecken. Es wird gemunkelt, dass WLAN to go bis Ende des Jahres eingestellt wird. Neuanmeldungen sind ja schon jetzt nicht mehr möglich.
https://de.wikipedia.org/wiki/Fon_%28Unternehmen%29#Internetdienstanbieter
3
Answer
from
4 years ago
Als erstes mal ein Danke an @Patti Müller . Dem ist fast nix hinzuzufügen.
@Zufall Rainer
In Europa und speziell Deutschland ist es garnicht so ohne, einen öffentlichen Hotspot anzubieten. Das Damoklesschwert der Störerhaftung wurde zwar über ein Providerprivileg entschärft. Ohne Maßnahmen zur Einschränkung oder Verhinderung mißbräuchlicher Nutzung kann es trotzdem zu teuren Auseinandersetzungen zwischen Hotspotbetreibern und (vermeintlichen) Rechteinhabern kommen. Also wirft man sich das Schamtuch gewisser Diensteeinschränkungen um.
Wie ich oben schon schrieb, sind oft IPSec-Tunnel an diesen Hotspots nicht möglich - das schließt dann Dein geliebtes WiFi-Calling mit ein.
Answer
from
4 years ago
Hier werden wieder Dinge durcheinander geschmissen, die überhaupt nichts miteinander zu tun haben.
Bei Telekom FON Hotspots wird, wie bei anderen Hotspots, der Datenverkehr über ein VPN zur Telekom geroutet. Das heißt, jeder, der diesen Hotspot anbietet, hat überhaupt kein Risiko einer Störerhaftung, da der Zugriff über die IP-Adresse des Telekomrechenzentrums erfolgt. Wenn hier also jemand Filesharing oder Ähnliches betreibt hat der Rechteinhaber niemals eine Möglichkeit an denjenigen zu gelangen über dessen "Telekom FON" Anschluss die Rechteverletzung begangen wurde.
Nachdem der Zugang nur nach Login möglich ist, verfügt wahrscheinlich die Telekom über Aufzeichnung um direkt den Verursacher zu finden, völlig vorbei am Hotspotbetreiber.
VPNs wie IP-SEC Tunnel zu sperren ist in Sachen Störerhaftung absolut kontraproduktiv. Leitet man den Datenverkehr durch ein VPN , tritt nach außenhin die IP des VPN Endpunkts in Erscheinung. Wenn es also das Risiko einer Störerhaftung gäbe, müsste jeder Hotspotbetreiber glücklich sein, wenn die Nutzer ihre Verbindung durch ein VPN Tunneln, weil deren IP dann nirgends (außer am VPN Einwahlknoten) geloggt wird.
Answer
from
4 years ago
Was Du sagst, ist korrekt.
Ich habe zu keinem Zeitpunkt mit "Betreiber" einen WLtG-Router-Aufsteller gemeint, sondern jeweils den eigentlichen Betreiber.
Aber auch die sind nicht unanagreifbar und haben daher zumindest pro Forma gewisse Einschränkungen. Und ja, in Deutschland musst Du Dich an vielen Hotspots eindeutig identifizieren.
Ich wollte nur nochmal anmerken, woher die Einschränkungen (historisch) kommen.
Und es ist nicht zu erwarten, dass jemand speziell an WLTG-Hotspots irgendentwas davon anfasst zwecks Änderung.
Ich vermute stark, in den Firewalls wird nicht gesperrt, sondern gefolgt von einer "deny all" Regel einzelnes erlaubt. Ist weniger Arbeit und deutlich weniger fehleranfällig. Das ist Dir aber sicher auch bekannt.
Unlogged in user
Answer
from
Unlogged in user
Ask
from