Wie lautet meine IP Service: ifconfig.ffhh

Moin,
[ifconfig.ffhh][1] war geraume Zeit offline und ist nun wieder verfügbar.

Feature list:
$curl http://ifconfig.ffhh
1.1.1.1

$curl http://ifconfig.ffhh/ip
1.1.1.1

$curl http://ifconfig.ffhh/ip.host
1.1.1.1 r.d.ns.look.up

$curl http://ifconfig.ffhh/host
r.dns.look.up

now ipv6 ready!
to force ipv6 use http://6.ifconfig.ffhh
to force ipv4 use http://4.ifconfig.ffhh

now Wget ready!
$wget -qO- http://ifconfig.ffhh/
1.1.1.1

Den Quelltext gibt es unter GitHub - kantorkel/ifconfig.pro: code for ifconfig.pro

Gruß
kantorkel
[1]: http://ifconfig.ffhh

2 Likes

Wir sind seit kurzen auch am IC-VPN beteiligt. Aber Verbindung nach Hamburg haben wir nicht. Woran könnte das liegen?

Unter http://bgp.freifunk-bielefeld.de/ulg/ulg.py finde ich keine Infos zu Uelzen. Unter http://freifunk.draic.info/icvpn.txt taucht ihr auf…
Kannst du *.ffhh auflösen? Siehe ggf. DNS – wiki.freifunk.net

Nein, ich kann weder eure DNS Server erreichen, noch kommt ein Tracert zu euch an.

marc-andre@uegw1:~$ sudo birdc show route 10.112.0.0/16
BIRD 1.5.0 ready.
10.112.0.0/16      via 10.207.0.63 on icvpn [hamburg03 06:04:00] * (100) [AS49009i]
                   via 10.207.0.63 on icvpn [gueterslohbgp2 09:50:44 from 10.207.0.133] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [darmstadt1 09:35:53 from 10.207.0.218] (100) [AS49009i]
                   via 10.207.0.64 on icvpn [hamburg02 09:35:50] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [mainz1 06:04:29 from 10.207.0.37] (100) [AS49009i]
                   via 10.207.0.61 on icvpn [hamburg01 16:35:50] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [luebeck2 06:02:28 from 10.207.0.131] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [mueritz_bgp1 06:02:18 from 10.207.0.138] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [waldheim1 06:02:16 from 10.207.0.45] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [wiesbaden2 06:02:11 from 10.207.1.56] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [luebeck1 06:02:11 from 10.207.0.130] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [westkueste1 06:02:09 from 10.207.0.12] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [mainz2 06:02:09 from 10.207.1.37] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [bremen1 06:02:09 from 10.207.1.196] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [dreilaendereck2 06:02:09 from 10.207.0.74] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [frankfurt1 06:02:09 from 10.207.0.35] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [bremen3 06:02:09 from 10.207.3.196] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [troisdorf1 06:02:09 from 10.207.0.185] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [wiesbaden1 06:02:09 from 10.207.0.56] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [bremen2 06:02:09 from 10.207.2.196] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [trier1 06:02:09 from 10.207.0.220] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [darmstadt2 06:02:09 from 10.207.0.219] (100) [AS49009i]
                   via 10.207.0.63 on icvpn [gueterslohbgp1 06:02:09 from 10.207.0.136] (100) [AS49009i]
                   via 10.207.0.61 on icvpn [erfurt2 16:35:11 from 10.207.0.10] (100) [AS49009i]

Sieht auch gut aus, oder?

marc-andre@uegw1:~$ sudo birdc show protocols | grep hamburg
hamburg01 BGP      ebgp     up     16:35:50    Established   
hamburg02 BGP      ebgp     up     09:35:50    Established   
hamburg03 BGP      ebgp     up     06:04:00    Established   

Trotzdem kommt nix zu euch durch.

Edit: Die Bielefelder kennen uns doch:

Aus deiner Twitter Anfrage:

traceroute to 10.112.0.9 (10.112.0.9), 30 hops max, 60 byte packets
1 ffuegw3.ffue (10.134.30.1) 35.925 ms 36.272 ms 36.273 ms
2 uegw1.ffue (10.134.10.1) 84.715 ms 85.165 ms 85.649 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 *^C

traceroute to 2a03:2267::f44b:f1ff:fedc:90f8 (2a03:2267::f44b:f1ff:fedc:90f8) from 2001:6f8:900:8ba1:5cb9:555f:715e:a2f1, 30 hops max, 24 byte packets
1 2001:6f8:900:8ba1::1 (2001:6f8:900:8ba1::1) 48.896 ms 33.419 ms 34.106 ms
2 gw-2978.ham-01.de.sixxs.net (2001:6f8:900:ba1::1) 46.427 ms 44.761 ms 44.123 ms
3 2001:6f8:862:1::c2e9:c729 (2001:6f8:862:1::c2e9:c729) 45.407 ms 44.01 ms 43.289 ms
4 2001:6f8:862:1::c2e9:c72c (2001:6f8:862:1::c2e9:c72c) 45.346 ms 45.715 ms 47.613 ms
5 ge0-0-3-br2.frankfurt1.iphh.net (2001:7f8::31bb:0:1) 53.663 ms 54.596 ms 53.341 ms
6 ae1-11-br3.hamburg2.iphh.net (2001:868:0:4::1:1) 65.968 ms 69.49 ms 69.085 ms
7 te4-3-cr1.hamburg2.iphh.net (2001:868:0:4::17:2) 68.52 ms 66.029 ms 66.972 ms
8 wende0.hamburg.freifunk.net (2001:868:100:d00::10) 66.994 ms 65.289 ms 68.386 ms
9 gw03.hamburg.freifunk.net (2001:868:100:d00::20) 66.097 ms 66.368 ms 64.806 ms
10 ipv6-f44bf1fffedc90f8.clients.hamburg.freifunk.net (2a03:2267::f44b:f1ff:fedc:90f8) 101.312 ms 102.45 ms 100.683 ms
marc-andre@amd-x4:~$

Euer DNS ist nicht erreichbar:

traceroute to 2a03:2267::101 (2a03:2267::101) from 2001:6f8:900:8ba1:5cb9:555f:715e:a2f1, 30 hops max, 24 byte packets
1 2001:6f8:900:8ba1::1 (2001:6f8:900:8ba1::1) 33.92 ms 30.743 ms 31.402 ms
2 gw-2978.ham-01.de.sixxs.net (2001:6f8:900:ba1::1) 43.956 ms 44.753 ms 44.167 ms
3 2001:6f8:862:1::c2e9:c729 (2001:6f8:862:1::c2e9:c729) 43.607 ms 55.647 ms 47.015 ms
4 2001:6f8:862:1::c2e9:c72c (2001:6f8:862:1::c2e9:c72c) 62.731 ms 43.997 ms 45.396 ms
5 ge0-0-3-br2.frankfurt1.iphh.net (2001:7f8::31bb:0:1) 54.41 ms 56.874 ms 54.984 ms
6 ae1-11-br3.hamburg2.iphh.net (2001:868:0:4::1:1) 64.848 ms 67.429 ms 70.119 ms
7 te4-3-cr1.hamburg2.iphh.net (2001:868:0:4::17:2) 65.99 ms 65.896 ms 69.64 ms
8 wende0.hamburg.freifunk.net (2001:868:100:d00::10) 115.054 ms 74.348 ms 67.972 ms
9 gw03.hamburg.freifunk.net (2001:868:100:d00::20) 74.006 ms 66.465 ms 65.701 ms
10 * * *
^C

Das Problem der Nichterreichbarkeit der Hamburger NS habe ich auch, allerdings scheint das daran zu liegen, daß mein BIND mit der ICVPN-Adresse fragt, und Hamburg da keine Rückroute zu zu haben scheint:

root@mueritzbgp1:~# traceroute -s 10.169.1.1 10.112.1.1
traceroute to 10.112.1.1 (10.112.1.1), 30 hops max, 60 byte packets
 1  hamburg03.icvpn (10.207.0.63)  16.172 ms  16.709 ms  16.732 ms
 2  10.112.1.1 (10.112.1.1)  18.685 ms  18.773 ms  18.818 ms
root@mueritzbgp1:~# traceroute -s 10.207.0.138 10.112.1.1
traceroute to 10.112.1.1 (10.112.1.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * ^C

Ich sehe die Pakete via icvpn rausgehen (IP 10.207.0.138.53235 > 10.112.1.1.33465: UDP, length 32), es kommt nur nix zurück; von 10.255.255.1 oder 10.169.1.1 (s. o.) aus tut’s … Dürfte bei Uelzen aber nicht das Problem sein, da von innerhalb des Uelzener /16 initiiert.

Bei Uelzen versacken bei mir die Traces mit FF-Adressen hinter Eurem ICVPN-GW:

root@mueritzbgp1:~# traceroute -m 5 -s 10.169.1.1 10.134.30.1
traceroute to 10.134.30.1 (10.134.30.1), 5 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
root@mueritzbgp1:~# traceroute -m 5 -s 10.207.0.138 10.134.30.1
traceroute to 10.134.30.1 (10.134.30.1), 5 hops max, 60 byte packets
 1  uegw1.icvpn (10.207.0.18)  16.265 ms  17.646 ms  17.660 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *

Ich würde daher erwarten, daß entweder ip route show table 42 | grep 10.169 bei Euch leer ist oder aber eine Regel dafür sorgt, daß Tabelle 42 (oder welche Ihr verwendet) nicht gezogen wird (bzw. keine, daß ;)); dafür spricht imho auch, daß der Trace bei Dir hinter uegw1.ffue versackt. ip route add iif icvpn lookup 42 könnte helfen (was über ICVPN reinkommt, über die Freifunk-Routingtabelle routen).

Bzgl. ULG-Screenshot: Derzeit listet es mit Hamburg03 als Next-Hop, was funktionieren kann, aber imho kaum wird; ich finde auch kein direktes Announcment von Uelzen, nur indirekte.

Mueritz BGP1 & Guetersloh BGP1 haben einen direkten Eintrag, gw04.guetersloh (handgeklöppelte BIRD-Config) wieder den via Hamburg03:

root@mueritzbgp1:~# birdc show route 10.134.0.0/16 primary | grep ^10
10.134.0.0/16      via 10.207.0.18 on icvpn [uegw1 14:37:54] * (100) [AS64525i]
root@bgp1:~# birdc show route 10.134.0.0/16 primary | grep ^10
10.134.0.0/16      via 10.207.0.18 on icvpn [uegw1 12:38:02] * (100) [AS64525i]
root@gw04:~# birdc show route 10.134.0.0/16 primary | grep ^10
10.134.0.0/16      via 10.207.0.63 on icvpn [pipe_icvpn 14:37:05] * (70)

Aber irgendwie scheint da generell noch was im Argen zu liegen bei Euch, uegw1.icvpn sollte nicht auf dem ICVPN nach internen Adresse per ARP fragen:

root@mueritzbgp1:~# tcpdump -n -i icvpn net 10.134.0.0/16
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on icvpn, link-type EN10MB (Ethernet), capture size 65535 bytes
16:30:41.336840 ARP, Request who-has 10.134.20.1 tell 10.207.0.18, length 28
16:30:42.337211 ARP, Request who-has 10.134.20.1 tell 10.207.0.18, length 28
16:30:43.330115 ARP, Request who-has 10.134.20.1 tell 10.207.0.18, length 28

Aber im Grunde ist das ziemlich off-topic :wink:

Zum eigentlichen Thema: @kantorkel: sehe ich das richtig, daß ifconfig.ffhh ein „what is my IP“-Service ist? Ganz doof gefragt, welchen Nutzen hat es, die (v4) IP zeigt zumindest Android doch in den WLAN-Einstellungen an? Oder nutzt Ihr das für Problemeingrenzungen?

wir haben derzeit bekannte probleme mit der erreichbarkeit von srv01.ffhh per ipv6. diese bestehen schon länger, stehen aber auf todo.

per v4 sollte es gehen, allerdings hast du recht, dass wir für das ipv4 transfer netz des icvpn im hamburger netz (und damit auch von den icvpn gateways zu srv01 nicht) keine route propagieren. bitte nutze für anfragen an unseren nameserver eine v4 adresse aus eurem 10.x.x.x netz.

achso hier noch die antwort zu: ja gleiches problem bei uns. anscheinend hat uelzen keine richtige rückroute zu uns. @kantorkel wird sich nochmal bei @Freifunker melden, um das Problem zu beheben.

Ja das ist alles nicht so einfach bei uns glaube ich. Zum einen weil wir noch Schweden VPN benutzen. Das bedeutet alle Pakete die über das Mesh VPN von den Knoten rein kommen bekommen den Tag 0x1. Damit der Traffic auf den Gateways via Table 42 raus geht, sowohl ins Internet als auch neuerdings ins IC-VPN. Raus geht anscheinend. So aber jetzt scheint wohl doch bei uns der Rückweg versperrt zu sein. Ich müsste jetzt Bird irgendwie sagen, bitte eingehende Pakete auf das ffue-mesh-vpn Interface schmeißen.

[quote=„ohrensessel, post:7, topic:6861“]
bitte nutze für anfragen an unseren nameserver eine v4 adresse aus eurem 10.x.x.x netz[/quote]

Wie kodiert man das in der named.conf.options?

Bis zum nächsten Reboot kaschiert nun ein lokales /sbin/iptables -t nat -I POSTROUTING -s 10.207.0.138 -d 10.112.1.1 -o icvpn -j SNAT --to 10.169.1.1 Euer Routingproblem, aber das skaliert nicht :frowning:

Es wäre imho sinnvoll, wenn, wer am ICVPN teilnimmt, auch das Transfernetz routet, zumal es als /16 realisiert ist. Anyway, Auflösung der DNS-Zonen, sofern sie a) in icvpn-meta hinterlegt und b) die dort genannten Nameserver (von ICVPN-Adressen aus) auch erreichbar sind (da fehlen hier leider viele :(), tut nun auch für Hamburg.

root@gw01:~# traceroute -s 10.255.255.1 -m 5 ifconfig.ffhh
traceroute to ifconfig.ffhh (10.112.0.9), 5 hops max, 60 byte packets
 1  100.64.2.0 (100.64.2.0)  16.319 ms  16.506 ms  16.484 ms
 2  hamburg03.icvpn (10.207.0.63)  34.571 ms  34.574 ms  34.566 ms
 3  * * *
 4  * * *
 5  ifconfig.ffhh (10.112.0.9)  359.349 ms  359.348 ms  359.349 ms
root@gw01:~# grep nameserver /etc/resolv.conf | head -1
nameserver 10.207.0.138

[Und wenn ich rausgefunden habe, wie man Beiträge verschiebt, würde ich diese hier tendentiell nach howto-ic-vpn-setup/6672 verschieben wollen, mit ipconfig.ffhh hat’s ja nix zu tun. Wollte ich eigentlich mit Nr. 6 grade, aber @ohrensessel war schneller mit dem Antworten ;)]

F’up in HowTo IC-VPN Setup - #15 von Freifunker

schau dir mal DNS BIND9 Query Statements an

Danke, aber Du mißverstehst das Problem :frowning:

Die Frage war nach Umsetzung Deiner gewünschten, zielabhängigen Absendeadresse, nicht, wie man die auf eine IP festnagelt.

Der Server hat icvpn-, mesh- und öffentliche Adressen (v4, v6). Er lauscht in jedem dieser Netze, und löst die internen und öffentlichen Namen für Cients aus dem Mesh (und dem ICVPN) auf. query-source auf die öffentliche Adresse sperrt ihn aus mindestens dem ICVPN aus. query-source auf die Mesh-IP verhindert Auflösung öffentlicher Namen. Und ohne query-source setzt Linux die IP-Adresse des ausgehenden Interfaces, das ist nun einmal die des icvpn-Interfaces, da (Teile aus) 10/8 darüber geroutet.

ah tut mir leid, stand auf dem schlauch. dies kannst du realisieren durch setzen des src parameters einer route. in bird geht das z.b. durch krt_prefsrc

protocol kernel {
  [...]
  export filter {
        if is_freifunk() || is_chaos() || is_dn42() then {
                krt_prefsrc=10.112.1.11;
        }
        accept;
  };
};

wenn das jetzt konsens sein sollte, dass man auch ne route fürs icvpn transfernetz haben sollte, würde ich die sonst anlegen. sah das aber wirklich bisher nur als TRANSFERnetz.

1 Like

[quote=„ohrensessel, post:14, topic:6861“]
in bird geht das z.b. durch krt_prefsrc[/quote]

Awesome! Hinzugefügt, iptables-Regel gelöscht, tut:

18:36:35.787505 IP 10.207.0.138.62522 > 10.112.1.1.53: 3387 [1au] ANY? foo.ffhh. (37)
18:37:45.123299 IP 10.169.1.1.60212 > 10.112.1.1.53: 35982 [1au] ANY? foo.ffhh. (37)
18:37:45.141435 IP 10.112.1.1.53 > 10.169.1.1.60212: 35982 NXDomain*- 0/1/1 (110)

Danke!

[quote]
wenn das jetzt konsens sein sollte, dass man auch ne route fürs icvpn transfernetz haben sollte, würde ich die sonst anlegen. sah das aber wirklich bisher nur als TRANSFERnetz.[/quote]

Sagen wir mal so: wer anfängt, hat ggf. alle Services auf einer VM. Da wäre es dann schon hilfreich, wenn man in diese Falle nicht reintappte, weil man von auf dem Host mit der icvpn-IP unterwegs ist und manches nicht tut. Ich hab’s bei uns so gelöst (ICVPN-Route erzeugen sowie ein Blackhole für nicht erreichbare 10er Adressen):

protocol static icvpn_static {
  import all;
  table mesh;
  route 10.207.0.0/16 via "icvpn";
  route 10.0.0.0/8 reject;
}

Wg. more specific funktionieren erlernte Routen ja, aber nicht Erreichbares wird lokal gedroppt und nicht erst irgendwo Upstream. Und da 10.207er Adressen im Trace auftauchen, sollten die auch geroutet werden, IMHO.

Ich persönlich bisher nicht.