Diskussion:WLAN: Unterschied zwischen den Versionen
(→Linux) |
|||
(7 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt) | |||
Zeile 3: | Zeile 3: | ||
Die DNS-Konfig von Tubit ist - seltsam. Eventuell kann man hier | Die DNS-Konfig von Tubit ist - seltsam. Eventuell kann man hier | ||
mal mit einem Zuständigen sprechen. | mal mit einem Zuständigen sprechen. | ||
− | Es sollte bei den DNS-Antworten auf jeden Fall eine TTL=0 kommen, | + | Es sollte bei den DNS-Antworten auf jeden Fall eine TTL=0 kommen, für die Weiterleitungsseiten. Ausserdem wäre es sinnvoll, innerhalb des WLAN und des VPN identische IP's für den DNS-Server zu benutzen und dies via routing oder DNAT so umzubiegen, dass man jeweils auf anderen Servern landet. --[[Benutzer:Mutax|florian]] 12:52, 28. Okt. 2008 (UTC) |
Das mit dem DNS ist echt komisch. Unter OS X in "Tunnelblick" gibt es so eine Option "Set Nameserver", wo es aussieht als wenn er einen nimmt, der beim Aufbau des Tunnels übertragen wird. Dort funktioniert das immer direkt. Vielleicht gibts sone Option ja auch irgendwie für OpenVPN unter Linux. --[[Benutzer:Stefan|Stefan]] 02:19, 20. Jan. 2009 (UTC) | Das mit dem DNS ist echt komisch. Unter OS X in "Tunnelblick" gibt es so eine Option "Set Nameserver", wo es aussieht als wenn er einen nimmt, der beim Aufbau des Tunnels übertragen wird. Dort funktioniert das immer direkt. Vielleicht gibts sone Option ja auch irgendwie für OpenVPN unter Linux. --[[Benutzer:Stefan|Stefan]] 02:19, 20. Jan. 2009 (UTC) | ||
+ | |||
+ | Naja, das Problem ist mehrschichtig. Ich hatte bei Tubit auch schonmal vorgesprochen, weiss aber nicht ob da was gemacht wird. Beim Verbinden mit dem WLAN wird per DHCP unter anderem der DNS-Server gesetzt. Baut man den VPN-Tunnel auf, wird aber ein anderer DNS übertragen, der dann nicht mehr alle requests auf die Hinweisseite umlenkt. Läuft nun die DHCP-Lease des WLAN ab oder ist die Verbindung unterbrochen und ein NetworkManager stellt sie neu her, wird dort per DHCP der Nameserver wieder auf den ausserhalb des Tunnels gültigen gesetzt. Damit landet man trotz bestehendem VPN immer auf dieser Hinweisseite und meint, das VPN sei zusammengebrochen. --[[Benutzer:Mutax|florian]] 11:01, 20. Jan. 2009 (UTC) | ||
+ | |||
+ | : Bei mir ging die DNS-Zuweisung nach VPN-Einwahl unter OpenVPN unter Linux überhaupt nicht. Es müsste sich so beheben lassen (jedoch nocht nicht genau getestet): Zwei neue Zeilen in die .conf rein: "script-security 2" und "up ./tubit.up". Dann Shellscript /etc/openvpn/tubit.up anlegen, was mittels env die foreign_options rausgreppt und parsed. Eine Variable die gesetzt wird heisst z.B. foreign_option_2 und die enthält als Value "dhcp-option DNS 130.149.2.12". Damit könnte man sich dann die resolv.conf neu schreiben. Down-Scripte sind wohl auch möglich, damit könnte man eine gebackuppte resolv.conf wieder zurückkopieren.--[[Benutzer:Stefan|Stefan]] 02:54, 24. Feb. 2010 (CET) | ||
+ | |||
+ | :: Das sollte funktionieren, problem ist nur, wenn der DHCP-Client (via Networkmanager oder so) die DHCP-Lease erneuert, überschreibt der die resolv.conf wieder mir der des WLANS und nicht der des VPN. Man könnte natürlich sehr fies per iptables ein SNAT/DNAT machen um die DNS-Requests...ehhhm...oder tubit treten, views in den bind einzubauen und innerhalb und ausserhalb dieselben IPs für den DNS zu nehmen... --[[Benutzer:Mutax|Florian]] 12:15, 24. Feb. 2010 (CET) | ||
+ | |||
+ | ==Linux== | ||
+ | Ein Verwies auf http://www.tubit.tu-berlin.de/wlan/zugang_und_anleitungen/eduroam_mit_linux_gnome/ wäre eventuell hilfreich, nachdem ich diese Seite gefunden und die Anleitung befolgt habe hat es dann sofort funktioniert. Die im Wiki vorgeschlagenen Lösungen haben mir leider nicht wirklich weiter geholfen. (Nutze ein Netbook mit Ubuntu 12.04.) | ||
+ | (leafar1@gmx.net) | ||
+ | :Besten Dank für deinen Hinweis! Du darfst unser wiki gerne jederzeit um sinnvolle Informationen selbst bereichern - ein [http://de.wikipedia.org/wiki/Wiki wiki] eben. :) | ||
+ | |||
+ | Das Zertifikat muss explizit angegeben werden, dann funktioniert es erst: CA-Pfad: ".../tu-berlin.de/tu.pem" | ||
+ | |||
+ | == Android == | ||
+ | |||
+ | Also bei mir ging die Einrichtung von eduroam auf meinem Galaxy S auch ohne die von euch beschriebenen Schritte. | ||
+ | Die Boardmittel scheinen da recht kompetent zu sein. |
Aktuelle Version vom 2. März 2017, 09:36 Uhr
DNS
Die DNS-Konfig von Tubit ist - seltsam. Eventuell kann man hier mal mit einem Zuständigen sprechen. Es sollte bei den DNS-Antworten auf jeden Fall eine TTL=0 kommen, für die Weiterleitungsseiten. Ausserdem wäre es sinnvoll, innerhalb des WLAN und des VPN identische IP's für den DNS-Server zu benutzen und dies via routing oder DNAT so umzubiegen, dass man jeweils auf anderen Servern landet. --florian 12:52, 28. Okt. 2008 (UTC)
Das mit dem DNS ist echt komisch. Unter OS X in "Tunnelblick" gibt es so eine Option "Set Nameserver", wo es aussieht als wenn er einen nimmt, der beim Aufbau des Tunnels übertragen wird. Dort funktioniert das immer direkt. Vielleicht gibts sone Option ja auch irgendwie für OpenVPN unter Linux. --Stefan 02:19, 20. Jan. 2009 (UTC)
Naja, das Problem ist mehrschichtig. Ich hatte bei Tubit auch schonmal vorgesprochen, weiss aber nicht ob da was gemacht wird. Beim Verbinden mit dem WLAN wird per DHCP unter anderem der DNS-Server gesetzt. Baut man den VPN-Tunnel auf, wird aber ein anderer DNS übertragen, der dann nicht mehr alle requests auf die Hinweisseite umlenkt. Läuft nun die DHCP-Lease des WLAN ab oder ist die Verbindung unterbrochen und ein NetworkManager stellt sie neu her, wird dort per DHCP der Nameserver wieder auf den ausserhalb des Tunnels gültigen gesetzt. Damit landet man trotz bestehendem VPN immer auf dieser Hinweisseite und meint, das VPN sei zusammengebrochen. --florian 11:01, 20. Jan. 2009 (UTC)
- Bei mir ging die DNS-Zuweisung nach VPN-Einwahl unter OpenVPN unter Linux überhaupt nicht. Es müsste sich so beheben lassen (jedoch nocht nicht genau getestet): Zwei neue Zeilen in die .conf rein: "script-security 2" und "up ./tubit.up". Dann Shellscript /etc/openvpn/tubit.up anlegen, was mittels env die foreign_options rausgreppt und parsed. Eine Variable die gesetzt wird heisst z.B. foreign_option_2 und die enthält als Value "dhcp-option DNS 130.149.2.12". Damit könnte man sich dann die resolv.conf neu schreiben. Down-Scripte sind wohl auch möglich, damit könnte man eine gebackuppte resolv.conf wieder zurückkopieren.--Stefan 02:54, 24. Feb. 2010 (CET)
- Das sollte funktionieren, problem ist nur, wenn der DHCP-Client (via Networkmanager oder so) die DHCP-Lease erneuert, überschreibt der die resolv.conf wieder mir der des WLANS und nicht der des VPN. Man könnte natürlich sehr fies per iptables ein SNAT/DNAT machen um die DNS-Requests...ehhhm...oder tubit treten, views in den bind einzubauen und innerhalb und ausserhalb dieselben IPs für den DNS zu nehmen... --Florian 12:15, 24. Feb. 2010 (CET)
Linux
Ein Verwies auf http://www.tubit.tu-berlin.de/wlan/zugang_und_anleitungen/eduroam_mit_linux_gnome/ wäre eventuell hilfreich, nachdem ich diese Seite gefunden und die Anleitung befolgt habe hat es dann sofort funktioniert. Die im Wiki vorgeschlagenen Lösungen haben mir leider nicht wirklich weiter geholfen. (Nutze ein Netbook mit Ubuntu 12.04.) (leafar1@gmx.net)
- Besten Dank für deinen Hinweis! Du darfst unser wiki gerne jederzeit um sinnvolle Informationen selbst bereichern - ein wiki eben. :)
Das Zertifikat muss explizit angegeben werden, dann funktioniert es erst: CA-Pfad: ".../tu-berlin.de/tu.pem"
Android
Also bei mir ging die Einrichtung von eduroam auf meinem Galaxy S auch ohne die von euch beschriebenen Schritte. Die Boardmittel scheinen da recht kompetent zu sein.