Diskussion:WLAN - Versionsgeschichte

141.23.138.93: /* Linux */

2017-03-02T09:36:57Z

‎Linux

Mradke: /* Linux */ wikileser dürfen gerne Informationen selbst einstellen.

2012-10-23T14:46:30Z

‎Linux: wikileser dürfen gerne Informationen selbst einstellen.

130.149.245.249 am 23. Oktober 2012 um 13:40 Uhr

2012-10-23T13:40:14Z

130.149.17.62 am 25. Oktober 2010 um 09:28 Uhr

2010-10-25T09:28:16Z

130.149.17.62: Neuer Abschnitt /* Android */

2010-10-25T09:27:54Z

Neuer Abschnitt ‎Android

Mutax: /* DNS */

2010-02-24T11:15:14Z

‎DNS

Stefan: /* DNS */

2010-02-24T01:54:30Z

‎DNS

Mutax: erklärung DHCP

2009-01-20T11:01:07Z

erklärung DHCP

Stefan am 20. Januar 2009 um 02:19 Uhr

2009-01-20T02:19:23Z

Mutax: DNS

2008-10-28T12:52:29Z

DNS

@@ Zeile 17: / Zeile 17: @@
 (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. :)
 == Android ==

@@ Zeile 16: / Zeile 16: @@
 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)
 == Android ==

← Nächstältere Version		Version vom 23. Oktober 2012, 13:40 Uhr
Zeile 12:		Zeile 12:

	:: 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)		:: 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)

	== Android ==		== Android ==

@@ Zeile 15: / Zeile 15: @@
 == Android ==
-Also be mir ging die Einrichtung von eduroam auf meinem Galaxy S auch ohne die von euch beschriebenen Schritte.
+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.

← Nächstältere Version		Version vom 25. Oktober 2010, 09:27 Uhr
Zeile 12:		Zeile 12:

	:: 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)		:: 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)
		+
		+	== Android ==
		+
		+	Also be 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.

← Nächstältere Version		Version vom 24. Februar 2010, 11:15 Uhr
Zeile 10:		Zeile 10:

	: 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)		: 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)

← Nächstältere Version		Version vom 24. Februar 2010, 01:54 Uhr
Zeile 8:		Zeile 8:

	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)		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)

@@ Zeile 3: / Zeile 3: @@
 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, fpr 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)
+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)

← Nächstältere Version		Version vom 20. Januar 2009, 02:19 Uhr
Zeile 4:		Zeile 4:
	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, fpr 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)		Es sollte bei den DNS-Antworten auf jeden Fall eine TTL=0 kommen, fpr 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)

← Nächstältere Version		Version vom 28. Oktober 2008, 12:52 Uhr
Zeile 1:		Zeile 1:
−	~~Abschnitt~~ kann ~~gelöscht werden~~.	+	== 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, fpr 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)