Ich bin frustriert und sehr wahrscheinlich wird dieses Projekt nie klappen. So lange Kapitalismus bedeutet, dass Wissende ihr Wissen nicht weiter geben, kann nur darum gebettelt werden. Ich hatte mir vom links progressiven Chaos Umfeld mehr erhofft.
Dies ist die Fortsetzung, Provider zu werden. Nach der Deklaration bei der Bundesnetzagentur mit Sicherheitskonzept
https://www.kilo-byte.de/bundesnetzagentur-sicherheitskonzept-fuer-freies-wlan-und-tor-exit-node/
nun der Weg zu einer eigenen ASN (Autonomes System Nummer) und die Anbindung mit BGP (Border Gateway Protokol).
Mein Dank geht an Securebit in der Schweiz, an Freifunk und an Freunde und Bekannte, ohne deren Unterstüzung ich mit diesem Projekt nicht weiter gekommen wäre.
Im Sinne der Inklusion teste ich die Realität, wie weit Inklusion gehen kann. Dieses Thema ist schon etwas speziell, Leute zu finden, die davon was wissen, ist überschaubar. Zeitmangel ist ebenfalls ein Problem.
Es gibt sicherlich ganz andere Umsetzungen, hier folgt mein Versuch:
Die RIPE
Eine volle RIPE Mitgliedschaft ist für ein Test Mini Provider etwas teuer. Sollten jedoch Abitionen zu einem richtigen Anbieter entstehen, ist der Mitgliedsbeitrag ok. Die RIPE vergibt im europäschen Raum die öffentlichen IP Adressen als Blöcke. IPV4 Adressen sind verbraucht, ein /24, also 256 IPV4 Adressen werden zum Preis eines Teslas von Mitgliedern getauscht. Heute gibt es frisch nur IPV6 Adressen, dass ist auch gut so, das Internet soll zu IPV6.
Vollmitglieder können kleinere Blöcke als LIR spenden. Ich habe so ein Spender gefunden. Für ein deutlich günstigeren Betrag bin ich so an ein /48 Block gekommen, damit sind ca. 65.000 Netzwerke addressierbar. Der gebende Provider meldet das gespendete Netzwerk an die RIPE. Mit den Eintragungen konnte ich mit meiner angegebenen E-Mail Adresse ein Login bei der RIPE erstellen.
Vor einigen Wochen hatte ich versucht, auf dem Server eine BGP Session einzurichten. Dazu später mehr. Die erhofften Verbindung kam nicht zustande. Die Suche nach dem Fehler in der Konfiguration. Es musste erst etwas anderes geschehen.
Auf der Verwaltungsobefläche der RIPE sollte ich mich als Maintainer anlegen. Diesen Maintainer konnte der Spenderprovider dann hinzufügen.
Dieser Schritt ist notwendig, um dann ein “route6 object” zu erstellen.
Dann klappen auch die BGP Sessions.
Aus Unwissenheit zunächst der Widerstand. Ich hatte ein Debian Linux mit Bird2 aufgesetzt und ein MikroTik OS Router. Später bin ich bei MikroTik auf der VM geblieben.
Die Konfiguration
Im Rechenzentrum vor Ort, wo ich die ersten beiden Peering machen kann, habe ich eine VM mit MikroTik OS gemietet. Mit einem GRE Tunnel hole ich das /48 zu meinem Server mit pfSense. Später können dort z.B. VPN Netzwerke verwaltet werden.
Mein zugeteiltes /48 nenne ich abc:123:123:: (AS123)
Die VM hat zur Verwaltung eine IPV4 und eine IPV6 Adresse, nenne ich mal 1.2.3.4 und 1111:2222:3333:4::1
Die beiden Peers nenne ich 11:11:11:11::1 (AS1) und 22:22:22:22::2 (AS2)
Der GRE Tunnel geht zur pfSense, diese nenne ich 99.99.99.99
BGP auf MikroTik Router
tcp-md5-key=”” noch ausgeklammert
[ich@MikroTik] >
[ich@MikroTik] > /system package enable ipv6
[ich@MikroTik] > /routing bgp instance
[ich@MikroTik] /routing bgp instance> set default as=123
[ich@MikroTik] /routing bgp instance> /routing bgp network
[ich@MikroTik] /routing bgp network> add network=abc:123:123::/48 synchronize=no
[ich@MikroTik] /routing bgp network> /routing bgp peer
[ich@MikroTik] /routing bgp peer> add name=AS1 remote-address=11:11:11:11::1 remote-as=1 address-families=ipv6
[ich@MikroTik] /routing bgp peer> add name=AS2 remote-address=22:22:22:22::2 remote-as=2 address-families=ipv6
BGP überprüfen
[ich@MikroTik] > /routing bgp peer print
Flags: X - disabled, E - established
# INSTANCE REMOTE-ADDRESS REMOTE-AS
0 E default 11:11:11:11::1 1
1 E default 22:22:22:22::2 2
[ich@MikroTik] > /routing bgp peer print status
Flags: X - disabled, E - established
0 E name="AS1" instance=default remote-address=11:11:11:11::1 remote-as=1 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255
in-filter="" out-filter="" address-families=ipv6 default-originate=never remove-private-as=no as-override=no passive=no use-bfd=no remote-id=1.1.1.1
local-address=1111:2222:3333:4::1 uptime=3d18h18m25s prefix-count=140914 updates-sent=112877 updates-received=668221 withdrawn-sent=101842 withdrawn-received=71112
remote-hold-time=4m used-hold-time=3m used-keepalive-time=1m refresh-capability=yes as4-capability=yes state=established
1 E name="AS2" instance=default remote-address=22:22:22:22::2 remote-as=2 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m
ttl=255 in-filter="" out-filter="" address-families=ipv6 default-originate=never remove-private-as=no as-override=no passive=no use-bfd=no remote-id=2.2.2.2
local-address=1111:2222:3333:4::1 uptime=3d18h14m14s prefix-count=141026 updates-sent=562603 updates-received=613306 withdrawn-sent=101735 withdrawn-received=59775
remote-hold-time=3m used-hold-time=3m used-keepalive-time=1m refresh-capability=yes as4-capability=yes state=established
GRE Tunnel auf MikroTik Seite
[ich@MikroTik] > /interface gre
[ich@MikroTik] /interface gre> add name=Gre remote-address=99.99.99.99 local-address=1.2.3.4 mtu=1400 keepalive=10s,10 dscp=inherit clamp-tcp-mss=yes dont-fragment=no allow-fast-path=no
[ich@MikroTik] /interface gre> /ipv6 address
[ich@MikroTik] /ipv6 address> add address=abc:123:123:1::1/64 advertise=no interface=Gre
IPV6 an NetzwerkportH
[ich@MikroTik] /ipv6 address> add address=abc:123:123::1/64 advertise=no interface=ether1
GRE Tunnel auf pfSense Seite
GRE Tunnel mit Remote Addresse 1.2.3.4, Lacal IPv6 tunnel address abc:123:123:1::2 und Remote IPv6 address abc:123:123:1::1 im Subnet 64 erstellt.
Die Schnittstelle wurde zugewiesen und aktiviert; MTU auf 1400 vorerst gesetzt.
Die Firewall zunächst sehr offen gemacht.
Unter System / Routing / Gateway ist
Name: AS123_TUNNELV6 Standard: Default (IPv6) Schnittstelle: AS123 Gateway: 123:123:1::1 Monitor IP: 123:123:1::1
eingetragen.
Bei der LAN Schnittstelle wurde die IPv6 Addresse abc:123:123:2222::1 /64 eingetragen.
Unter DiensteDHCPv6 Server & RALANDHCPv6-Server wurde im Subnetz abc:123:123:2222:: der Bereich abc:123:123:2222:: bis abc:123:123:2222:ffff:ffff:ffff:ffff aktiviert.
Router Werbung im Modus Unterstützt – RA Flags [managed, other stateful], Prefix Flags [onlink, auto, router]
Wahrscheinlich falsch! – Router Werbung im Modus Unterstützt – RA Flags [managed, other stateful], Prefix Flags [onlink, auto, router] – Wahrscheinlich falsch!
Was funktioniert, was nicht funktioniert
PING6(56=40+8+8 bytes) abc:123:123:1::2 --> abc:123:123:1::1 16 bytes from abc:123:123:1::1, icmp_seq=0 hlim=64 time=20.525 ms 16 bytes from abc:123:123:1::1, icmp_seq=1 hlim=64 time=19.964 ms 16 bytes from abc:123:123:1::1, icmp_seq=2 hlim=64 time=20.327 ms --- abc:123:123:1::1 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 19.964/20.272/20.525/0.232 ms
PING6(56=40+8+8 bytes) abc:123:123:1::2 --> 2a00:1450:400a:802::2003 16 bytes from 2a00:1450:400a:802::2003, icmp_seq=0 hlim=120 time=24.761 ms 16 bytes from 2a00:1450:400a:802::2003, icmp_seq=1 hlim=120 time=127.721 ms 16 bytes from 2a00:1450:400a:802::2003, icmp_seq=2 hlim=120 time=22.418 ms --- google.de ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 22.418/58.300/127.721/49.098 ms
Ping innerhalb des Gre Tunnels funktioniert. Ping von Gre zur Welt funktioniert ebenfalls.
PING6(56=40+8+8 bytes) abc:123:123:2222::1 --> abc:123:123:1::2 16 bytes from abc:123:123:1::2, icmp_seq=0 hlim=64 time=0.071 ms 16 bytes from abc:123:123:1::2, icmp_seq=1 hlim=64 time=0.025 ms 16 bytes from abc:123:123:1::2, icmp_seq=2 hlim=64 time=0.026 ms --- abc:123:123:1::2 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.025/0.040/0.071/0.022 ms
Mit der LAN IP Addresse auf der der pf Sense geht Ping auf die GRE Addresse der pfSense.
PING6(56=40+8+8 bytes) abc:123:123:2222::1 --> abc:123:123:1::1 --- abc:123:123:1::1 ping6 statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss
Mit der LAN Addresse wird die Gegenstelle im GRE Tunnel auf dem MikroTik Router nicht erreicht.
ich@debian4k-laptop:~$ ping abc:123:123:1::2
PING abc:123:123:1::2(abc:123:123:1::2) 56 data bytes
64 bytes from abc:123:123:1::2: icmp_seq=1 ttl=64 time=0.558 ms
64 bytes from abc:123:123:1::2: icmp_seq=2 ttl=64 time=0.312 ms
64 bytes from abc:123:123:1::2: icmp_seq=3 ttl=64 time=0.246 ms
64 bytes from abc:123:123:1::2: icmp_seq=4 ttl=64 time=0.312 ms
^C
--- abc:123:123:1::2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3070ms
rtt min/avg/max/mdev = 0.246/0.357/0.558/0.119 ms
Ein Client im LAN kann GRE auf der pfSense erreichen.
LAN kommt nicht auf die Gegenstelle der VM im Rechenzentrum und somit auch nicht zur Welt.
Die Welt kann den MikroTik Router und durch den Tunnel die pfSense anpingen. Zum LAN bzw. DMZ leider nicht.
Hier benötige ich noch Hilfe, die ich dankbar annehmen werde.
Ich biete 1000€ für die Lösung dieses Problems an. Kontakt, siehe Seitenanfang > Freiberufliche Tätigkeit.