Freifunk-Gateway aufsetzen/xlat464 - Versionsgeschichte

ChristianD: /* Einrichtung */

2021-01-19T14:37:18Z

Einrichtung

← Nächstältere Version		Version vom 19. Januar 2021, 16:37 Uhr
Zeile 84:		Zeile 84:
	Es können somit in den Hoods auch IPv4 Adressen verwendet werden, die nicht im Freifunk reserviert sind, z.b. aus dem 192.168.0.0/16 Netz (z.b. für jede Hood ein /23 aus diesem Netz)		Es können somit in den Hoods auch IPv4 Adressen verwendet werden, die nicht im Freifunk reserviert sind, z.b. aus dem 192.168.0.0/16 Netz (z.b. für jede Hood ein /23 aus diesem Netz)

	Wenn man kein IPv4 mehr routen möchte kann im babeld IPv4 komplett deaktivieren und auf den Gateway alle IPv4 Adressen auf allen peering Interfaces verwerfen. ~~Seiteneffekte~~ sind noch ~~ungeprüft und muss u~~.U. ~~beachtet~~ werden!		= Nacharbeiten =

			Wenn man kein IPv4 mehr routen möchte kann im babeld IPv4 komplett deaktivieren und auf den Gateway alle IPv4 Adressen auf allen peering Interfaces verwerfen. Dies sollte zum aktuellen Zeitpunkt (!!)noch nicht gemacht(!!) werden!

			== Nachteil ==
			Babelpeers die von einem Abhängig sind, können kein IPv4 mehr über einen routen und sind von der IPv4 Welt abgeschnitten

			== Lösungsmöglichkeiten ==
			Da 64:ff9b::/96 private IPv4 Adressen nicht umgesetzt werden (siehe letzte Meldung im clatd status) kann ein anderes /96 Netz verwendet werden. Damit werden auch private IPv4 Adressen umgesetzt und man könnte allen peers nur noch eine default route anbieten .

			= Ergebnis =

			Eventuell vorhandene Nebeneffekte sind noch nicht wirklich bedacht, zum aktuellen Zeitpunkt sollte daher erstmal IPv4 weiter geroutet werden. Es kann aber durchaus für eigene Hoods bereits xlat464 umgesetzt werden so das man zumindest für eigene Clients kein IPv4 Netz mehr benötigt.

ChristianD: /* Erklärung */

2021-01-19T14:32:45Z

Erklärung

← Nächstältere Version		Version vom 19. Januar 2021, 16:32 Uhr
Zeile 1:		Zeile 1:
			!!Achtung noch ungetestet!!

	= Erklärung =		= Erklärung =
	~~folgt~~...		Mit clatd können den Clients in den Hoods ganz normal Dualstack (IPv4 und IPv6) angeboten werden. In der Freifunk Backbone muss aber nur noch IPv6 geroutet werden. Dazu werden am Gateway die IPv4 Pakete mit xlat464 ins IPv6 übersetzt und auf einen NAT64 Server im Freifunkbackbone (davon gibt es mittlerweile mehrere) wieder in IPv4 übersetzt. Somit ist für die Clients eine ganz normale IPv4 Kommunikation möglich, es gibt für die Clients keinen Unterschied zu normalen Dualstack wie es bisher genutzt wird.
	~~!!Achtung noch ungetestet!!~~

	= Einrichtung =		= Einrichtung =

ChristianD: /* Einrichtung */

2021-01-19T14:17:16Z

Einrichtung

← Nächstältere Version		Version vom 19. Januar 2021, 16:17 Uhr
Zeile 34:		Zeile 34:
	</pre>		</pre>

	In der ersten Zeile wird der DNS64 Server für das 64:ff9b::/96 Subnetz angegeben. In der 2. Zeile wird der IPv4 Check deaktiviert (das Gateway hat in den meisten Fällen eine IPv4 Adresse, so das dieser Check sonst den Abbruch bedeutet) und in der 3. Zeile wird die IP Adresse angegeben die wir oben bereits entsprechend geroutet haben.		In der ersten Zeile wird der DNS64 Server für das 64:ff9b::/96 Subnetz angegeben (nur nötig wenn dieser DNS Server nicht am Gateway eingetragen werden kann, alternativ kann dieser DNS Server auch direkt am Gateway genutzt werden). In der 2. Zeile wird der IPv4 Check deaktiviert (das Gateway hat in den meisten Fällen eine IPv4 Adresse, so das dieser Check sonst den Abbruch bedeutet) und in der 3. Zeile wird die IP Adresse angegeben die wir oben bereits entsprechend geroutet haben.

	Danach kann man clatd starten:		Danach kann man clatd starten:

ChristianD: /* Erklärung */

2021-01-19T14:16:01Z

Erklärung

← Nächstältere Version		Version vom 19. Januar 2021, 16:16 Uhr
Zeile 1:		Zeile 1:
	= Erklärung =		= Erklärung =
			folgt...
			!!Achtung noch ungetestet!!

	= Einrichtung =		= Einrichtung =

ChristianD: /* Einrichtung */

2021-01-19T14:15:44Z

Einrichtung

← Nächstältere Version		Version vom 19. Januar 2021, 16:15 Uhr
Zeile 82:		Zeile 82:

	Wenn man kein IPv4 mehr routen möchte kann im babeld IPv4 komplett deaktivieren und auf den Gateway alle IPv4 Adressen auf allen peering Interfaces verwerfen. Seiteneffekte sind noch ungeprüft und muss u.U. beachtet werden!		Wenn man kein IPv4 mehr routen möchte kann im babeld IPv4 komplett deaktivieren und auf den Gateway alle IPv4 Adressen auf allen peering Interfaces verwerfen. Seiteneffekte sind noch ungeprüft und muss u.U. beachtet werden!

	~~= Einrichtung =~~

ChristianD: /* Vorraussetzung */

2021-01-19T14:15:38Z

Vorraussetzung

← Nächstältere Version		Version vom 19. Januar 2021, 16:15 Uhr
Zeile 1:		Zeile 1:
	= Erklärung =		= Erklärung =

	= ~~Vorraussetzung~~ =		= Einrichtung =
	Zuerst benötigen wir eine weitere ULA IPv6 Adresse. Diese Adresse darf an kein Interface gebunden sein, muss aber ins Babel announced werden. Dies können wir mit einer route in der fff table erledigen:		Zuerst benötigen wir eine weitere ULA IPv6 Adresse. Diese Adresse darf an kein Interface gebunden sein, muss aber ins Babel announced werden. Dies können wir mit einer route in der fff table erledigen:

ChristianD: /* Vorraussetzung */

2021-01-19T14:15:24Z

Vorraussetzung

@@ Zeile 46: / Zeile 46: @@
 </pre>
-angucken.
+angucken, es sollte etwa so aussehen:
 Danach müssen noch die Freifunk Netze auf das clat Interface geroutet und genNATet werden:

ChristianD: /* Vorraussetzung */

2021-01-19T14:14:38Z

Vorraussetzung

← Nächstältere Version		Version vom 19. Januar 2021, 16:14 Uhr
Zeile 4:		Zeile 4:
	Zuerst benötigen wir eine weitere ULA IPv6 Adresse. Diese Adresse darf an kein Interface gebunden sein, muss aber ins Babel announced werden. Dies können wir mit einer route in der fff table erledigen:		Zuerst benötigen wir eine weitere ULA IPv6 Adresse. Diese Adresse darf an kein Interface gebunden sein, muss aber ins Babel announced werden. Dies können wir mit einer route in der fff table erledigen:

	<~~code~~>		<pre>
	ip -6 ro replace fd43:5602:29bd:ffff::deine_res_ip/128 dev lo proto static table fff		ip -6 ro replace fd43:5602:29bd:ffff::deine_res_ip/128 dev lo proto static table fff
	</~~code~~>		</pre>

	Für diese IP müssen wir zwingend in die main table gucken da dort später clatd eine route ablegt (priority kann angepasst werden, die rule sollte aber sehr bald greifen!):		Für diese IP müssen wir zwingend in die main table gucken da dort später clatd eine route ablegt (priority kann angepasst werden, die rule sollte aber sehr bald greifen!):

	<~~code~~>		<pre>
	ip -6 ru add from all to fd43:5602:29bd:ffff::deine_res_ip/128 lookup main priority 10		ip -6 ru add from all to fd43:5602:29bd:ffff::deine_res_ip/128 lookup main priority 10
	</~~code~~>		</pre>

	Danach installieren wir clatd nach Anleitung https://github.com/toreanderson/clatd:		Danach installieren wir clatd nach Anleitung https://github.com/toreanderson/clatd:

	<~~code~~>		<pre>
	cd ~		cd ~
	git clone https://github.com/toreanderson/clatd		git clone https://github.com/toreanderson/clatd
	sudo make -C clatd install installdeps		sudo make -C clatd install installdeps
	</~~code~~>		</pre>

	Wir müssen die config ein klein wenig erweitern:		Wir müssen die config ein klein wenig erweitern:
Zeile 26:		Zeile 26:
	/etc/clatd.conf		/etc/clatd.conf

	<~~code~~>		<pre>
	dns64-servers=fd43:5602:29bd:ffff:1:1:1:64		dns64-servers=fd43:5602:29bd:ffff:1:1:1:64
	v4-conncheck-enable=no		v4-conncheck-enable=no
	clat-v6-addr=fd43:5602:29bd:ffff::deine_res_ip		clat-v6-addr=fd43:5602:29bd:ffff::deine_res_ip
	</~~code~~>		</pre>

	In der ersten Zeile wird der DNS64 Server für das 64:ff9b::/96 Subnetz angegeben. In der 2. Zeile wird der IPv4 Check deaktiviert (das Gateway hat in den meisten Fällen eine IPv4 Adresse, so das dieser Check sonst den Abbruch bedeutet) und in der 3. Zeile wird die IP Adresse angegeben die wir oben bereits entsprechend geroutet haben.		In der ersten Zeile wird der DNS64 Server für das 64:ff9b::/96 Subnetz angegeben. In der 2. Zeile wird der IPv4 Check deaktiviert (das Gateway hat in den meisten Fällen eine IPv4 Adresse, so das dieser Check sonst den Abbruch bedeutet) und in der 3. Zeile wird die IP Adresse angegeben die wir oben bereits entsprechend geroutet haben.
Zeile 36:		Zeile 36:
	Danach kann man clatd starten:		Danach kann man clatd starten:

	<~~code~~>		<pre>
	systemctl restart clatd		systemctl restart clatd
	</~~code~~>		</pre>

	Den Status ob alles geklappt hat mit		Den Status ob alles geklappt hat mit

	<~~code~~>		<pre>
	systemctl status clatd		systemctl status clatd
	</~~code~~>		</pre>

	angucken.		angucken.
Zeile 50:		Zeile 50:
	Danach müssen noch die Freifunk Netze auf das clat Interface geroutet und genNATet werden:		Danach müssen noch die Freifunk Netze auf das clat Interface geroutet und genNATet werden:

	<~~code~~>		<pre>
	ip ro replace default dev clat table fff		ip ro replace default dev clat table fff
	iptables -t nat -A POSTROUTING -o clat -j SNAT --to-source 192.0.0.1		iptables -t nat -A POSTROUTING -o clat -j SNAT --to-source 192.0.0.1
	</~~code~~>		</pre>

	Es können somit in den Hoods auch IPv4 Adressen verwendet werden, die nicht im Freifunk reserviert sind, z.b. aus dem 192.168.0.0/16 Netz (z.b. für jede Hood ein /23 aus diesem Netz)		Es können somit in den Hoods auch IPv4 Adressen verwendet werden, die nicht im Freifunk reserviert sind, z.b. aus dem 192.168.0.0/16 Netz (z.b. für jede Hood ein /23 aus diesem Netz)

ChristianD: /* Vorraussetzung */

2021-01-19T14:14:09Z

Vorraussetzung

@@ Zeile 46: / Zeile 46: @@
 </code>
-angucken, dies sollte etwa so aussehen:
+angucken.
 Danach müssen noch die Freifunk Netze auf das clat Interface geroutet und genNATet werden:

ChristianD: /* Vorraussetzung */

2021-01-19T14:13:40Z

Vorraussetzung

← Nächstältere Version		Version vom 19. Januar 2021, 16:13 Uhr
Zeile 2:		Zeile 2:

	= Vorraussetzung =		= Vorraussetzung =
			Zuerst benötigen wir eine weitere ULA IPv6 Adresse. Diese Adresse darf an kein Interface gebunden sein, muss aber ins Babel announced werden. Dies können wir mit einer route in der fff table erledigen:

			<code>
			ip -6 ro replace fd43:5602:29bd:ffff::deine_res_ip/128 dev lo proto static table fff
			</code>

			Für diese IP müssen wir zwingend in die main table gucken da dort später clatd eine route ablegt (priority kann angepasst werden, die rule sollte aber sehr bald greifen!):

			<code>
			ip -6 ru add from all to fd43:5602:29bd:ffff::deine_res_ip/128 lookup main priority 10
			</code>

			Danach installieren wir clatd nach Anleitung https://github.com/toreanderson/clatd:

			<code>
			cd ~
			git clone https://github.com/toreanderson/clatd
			sudo make -C clatd install installdeps
			</code>

			Wir müssen die config ein klein wenig erweitern:

			/etc/clatd.conf

			<code>
			dns64-servers=fd43:5602:29bd:ffff:1:1:1:64
			v4-conncheck-enable=no
			clat-v6-addr=fd43:5602:29bd:ffff::deine_res_ip
			</code>

			In der ersten Zeile wird der DNS64 Server für das 64:ff9b::/96 Subnetz angegeben. In der 2. Zeile wird der IPv4 Check deaktiviert (das Gateway hat in den meisten Fällen eine IPv4 Adresse, so das dieser Check sonst den Abbruch bedeutet) und in der 3. Zeile wird die IP Adresse angegeben die wir oben bereits entsprechend geroutet haben.

			Danach kann man clatd starten:

			<code>
			systemctl restart clatd
			</code>

			Den Status ob alles geklappt hat mit

			<code>
			systemctl status clatd
			</code>

			angucken, dies sollte etwa so aussehen:

			<code>
			● clatd.service - 464XLAT CLAT daemon
			Loaded: loaded (/etc/systemd/system/clatd.service; enabled; vendor preset: enabled)
			Active: active (running) since Tue 2021-01-19 14:56:27 CET; 13min ago
			Docs: man:clatd(8)
			Main PID: 11764 (clatd)
			Tasks: 2 (limit: 2359)
			Memory: 18.5M
			CGroup: /system.slice/clatd.service
			├─11764 /usr/bin/perl -w /usr/sbin/clatd
			└─11780 tayga --config /tmp/Tm3kPlgTzD --nodetach

			Jan 19 14:56:27 uranus clatd[11764]: Creating and configuring up CLAT device 'clat'
			Jan 19 14:56:27 uranus clatd[11764]: Created persistent tun device clat
			Jan 19 14:56:27 uranus clatd[11764]: Adding IPv4 default route via the CLAT
			Jan 19 14:56:27 uranus clatd[11764]: Starting up TAYGA, using config file '/tmp/Tm3kPlgTzD'
			Jan 19 14:56:27 uranus tayga[11780]: starting TAYGA 0.9.2
			Jan 19 14:56:27 uranus tayga[11780]: Using tun device clat with MTU 1500
			Jan 19 14:56:27 uranus tayga[11780]: TAYGA's IPv4 address: 192.0.0.2
			Jan 19 14:56:27 uranus tayga[11780]: TAYGA's IPv6 address: 64:ff9b::c000:2
			Jan 19 14:56:27 uranus tayga[11780]: NAT64 prefix: 64:ff9b::/96
			Jan 19 14:56:27 uranus tayga[11780]: Note: traffic between IPv6 hosts and private IPv4 addresses (i.e. to/from 64:ff9b::10.0.0.0/104, 64:ff9b::192.168.0.0/112, etc) will be dropped. Use a translation prefix within your organization's IPv6
			</code>

			Danach müssen noch die Freifunk Netze auf das clat Interface geroutet und genNATet werden:

			<code>
			ip ro replace default dev clat table fff
			iptables -t nat -A POSTROUTING -o clat -j SNAT --to-source 192.0.0.1
			</code>

			Es können somit in den Hoods auch IPv4 Adressen verwendet werden, die nicht im Freifunk reserviert sind, z.b. aus dem 192.168.0.0/16 Netz (z.b. für jede Hood ein /23 aus diesem Netz)

			Wenn man kein IPv4 mehr routen möchte kann im babeld IPv4 komplett deaktivieren und auf den Gateway alle IPv4 Adressen auf allen peering Interfaces verwerfen. Seiteneffekte sind noch ungeprüft und muss u.U. beachtet werden!

	= Einrichtung =		= Einrichtung =