2 Gateways - HA Konfiguration

Started by Nambis, May 28, 2023, 09:19:34 AM

Previous topic - Next topic
May 28, 2023, 09:19:34 AM Last Edit: May 28, 2023, 10:46:44 AM by Nambis
Hallo,

ich habe versucht, in einer Testumgebung 2 Gateways zu nutzen. Per Default soll der Traffic nur über einen GW laufen und wenn dieser wegfällt, dann soll eben der zweite genutzt werden.

Was ich versucht habe war, die Gateways mit 1 und 2 zu priorisieren und anschließend in einer Gruppe zusammen zufassen.

Unter NAT habe ich beide eingetragen, mit den entsprechenden Interfaces, siehe Bild.

Komischerweise, erhalte ich dann, wenn ich das GW 2 deaktiviere eine seltsame Routenverfolgung:

VirtualBox:~$ traceroute google.de
traceroute to google.de (142.251.36.163), 30 hops max, 60 byte packets
1  opnsense-testing(192.168.0.202)  0.605 ms  0.747 ms  0.767 ms
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * muc12s11-in-f3.1e100.net (142.251.36.163)  26.142 ms
VirtualBox:~$ traceroute google.de
traceroute to google.de (142.251.36.163), 30 hops max, 60 byte packets
1  opnsense-testing(192.168.0.202)  0.763 ms  0.906 ms  0.921 ms
2  10.10.10.1 (10.10.10.1)  15.049 ms  15.105 ms  15.129 ms
3  10.255.255.2 (10.255.255.2)  15.182 ms  15.214 ms  15.253 ms
4  93.90.196.12 (93.90.196.12)  15.452 ms 93.90.196.13 (93.90.196.13)  15.278 ms 93.90.196.12 (93.90.196.12)  15.488 ms
5  ae-0-0.bb-a.bap.rhr.de.net.ionos.com (212.227.121.4)  15.690 ms ae-16.bb-b.bs.kae.de.net.ionos.com (212.227.121.32)  16.843 ms ae-1-0.bb-a.bap.rhr.de.net.ionos.com (212.227.122.4)  15.484 ms
6  ae-10-0.bb-a.fra3.fra.de.net.ionos.com (212.227.120.146)  21.147 ms ae-9.bb-b.fr7.fra.de.net.ionos.com (212.227.120.169)  17.954 ms ae-10-0.bb-a.fra3.fra.de.net.ionos.com (212.227.120.146)  20.147 ms
7  212.227.112.63 (212.227.112.63)  18.700 ms  18.271 ms 212.227.112.83 (212.227.112.83)  19.919 ms
8  * * *
9  142.250.226.148 (142.250.226.148)  17.983 ms 142.250.46.248 (142.250.46.248)  18.033 ms 142.250.226.148 (142.250.226.148)  16.823 ms
10  108.170.251.208 (108.170.251.208)  24.187 ms 108.170.252.82 (108.170.252.82)  20.433 ms 108.170.252.83 (108.170.252.83)  18.706 ms
11  209.85.241.71 (209.85.241.71)  24.574 ms 209.85.241.231 (209.85.241.231)  24.329 ms 108.170.228.9 (108.170.228.9)  19.535 ms
12  142.250.46.171 (142.250.46.171)  26.597 ms 142.250.46.105 (142.250.46.105)  23.139 ms 209.85.241.43 (209.85.241.43)  26.321 ms
13  172.253.72.248 (172.253.72.248)  24.569 ms 108.170.233.58 (108.170.233.58)  23.545 ms 216.239.62.242 (216.239.62.242)  23.123 ms
14  74.125.244.81 (74.125.244.81)  21.668 ms 74.125.244.97 (74.125.244.97)  25.734 ms 74.125.244.81 (74.125.244.81)  21.681 ms
15  142.251.68.125 (142.251.68.125)  25.501 ms 142.251.68.123 (142.251.68.123)  21.359 ms  24.545 ms
16  muc12s11-in-f3.1e100.net (142.251.36.163)  24.321 ms  25.566 ms  26.022 ms



Für die Testumgebung habe ich einfach auf einer virtualisierten Opensense, ein VPN zu einer VPS aufgebaut und diese Verbindung als GW eingetragen.

Auf der VPS scheint der Trace normal zu funtkionieren:

Quoteroot@localhost:~# traceroute google.de
traceroute to google.de (172.217.18.3), 30 hops max, 60 byte packets
1  10.255.255.2 (10.255.255.2)  0.126 ms  0.093 ms  0.095 ms
2  93.90.196.12 (93.90.196.12)  0.762 ms 93.90.196.13 (93.90.196.13)  0.782 ms  0.765 ms
ae-17.bb-b.bs.kae.de.net.ionos.com (212.227.122.31)  1.951 ms ae-16.bb-b.bs.kae.de.net.ionos.com (212.227.121.32)  1.825 ms ae-17.bb-b.bs.kae.de.net.ionos.com (212.227.122.31)  1.951 ms
ae-9.bb-b.fr7.fra.de.net.ionos.com (212.227.120.169)  3.716 ms ae-10-0.bb-a.fra3.fra.de.net.ionos.com (212.227.120.146)  6.381 ms  6.375 ms
5  212.227.112.83 (212.227.112.83)  5.811 ms  4.679 ms 212.227.112.63 (212.227.112.63)  5.000 ms
6  * * *
7  142.250.62.150 (142.250.62.150)  3.356 ms 108.170.252.65 (108.170.252.65)  5.846 ms 142.250.62.150 (142.250.62.150)  3.329 ms
8  172.253.66.137 (172.253.66.137)  5.018 ms  6.584 ms 108.170.251.208 (108.170.251.208)  3.729 ms
9  * 108.170.229.168 (108.170.229.168)  7.068 ms fra15s28-in-f3.1e100.net (172.217.18.3)  3.175 ms
root@localhost:~# ping 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=11.9 ms
64 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=13.0 ms
^C
--- 10.10.10.12 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 11.930/12.481/13.032/0.551 ms



Warum erhalte ich diese komische Trace, wenn ich die VPN trenne?

traceroute google.de
traceroute to google.de (142.251.36.163), 30 hops max, 60 byte packets
1  opnsense-testing.niedata (192.168.0.202)  0.605 ms  0.747 ms  0.767 ms
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * muc12s11-in-f3.1e100.net (142.251.36.163)  26.142 ms



Weil wenn ich von meiner Workstation ebenfalls über diesen Gateway gehe, läuft alles ganz normal:

Routenverfolgung zu google.de [142.251.36.163]
über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  opnsense.niedata [192.168.0.12]
  2     2 ms     2 ms     2 ms  62.156.244.4
  3     4 ms     3 ms     3 ms  62.156.246.74
  4     3 ms     3 ms     3 ms  m-ef1-i.M.DE.NET.DTAG.DE [62.154.28.70]
  5     2 ms     2 ms     2 ms  80.157.129.174
  6     4 ms     4 ms     4 ms  172.253.78.199
  7     3 ms     3 ms     2 ms  142.251.68.125
  8     2 ms     2 ms     2 ms  muc12s11-in-f3.1e100.net [142.251.36.163]

Ablaufverfolgung beendet.



Netzwerkplan:

                         LAN-TELEFON -> Fritzbox -> IP-Telefone
                            |
  Internet ->  GF Sense -> LAN -> Clients + Drucker + Server
                            |
                           WAN -> Virtualisierte Opensense + Server
 
Braucht man einen bestimmten Port für die Routenverfolgung?

Vielleicht hat jemand ne Idee, würde mich freuen, Danke im Voraus!

Grüße


EDIT:

Wenn ich auf WAN über die FW Regeln, alles erlaube, dann macht der Traceroute keine Probleme, unabhängig welcher GW aktiv ist... jetzt frage ich mich, welche Ports sollte ich öffnen? ICMP ist eigentlich schon auf, für jegliche ICMP-Typen ... ???


EDIT II:

Ok, habs rausgefunden:

QuoteDie Standard-Unix-Version von traceroute verwendet UDP-Pakete, die an hohe, unbenutzte Ports gesendet werden, typischerweise beginnend mit Port 33434. Für jede zusätzliche (hop) wird der Port um 1 erhöht.

Das heißt, damit funktioniert der Traceroute:

IPv4 UDP * * * 33434 - any * *



Hi,

ich verstehe den Regelsatz im Screenshot schon nicht. Allow Traffic to Internet aber dann wird auf dem WAN 443 aufgemacht für alle? WebUI oder nen Proxy o.ä. auf WAN exposed? Absichtlich? Und warum sollte man auf dem WAN NTP oder DNS aufmachen? Das macht da wenig Sinn.

> Das heißt, damit funktioniert der Traceroute:

Oder einfach kein UDP Traceroute benutzen (was der Rest der Welt auch kaum mehr tut, da niemand freiwillig UDP Ports öffnet die nicht auf sein müssen) :)
Für sowas gibt es bspw. MTR und Co, die wesentlich sinnvoller arbeiten und wieder schlicht ICMP Echo Requests nutzen anstatt UDP HighPorts die niemand gern offen hat. Deshalb - gerade auf der Konsole - lieber mal MTR anschauen, macht einem das Leben viel einfacher (auch wegen der besseren Darstellung und dem dauerhaften Weiterpingen mit Durschnitt etc..)

Cheers :)
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.

WAN ist hier noch falsch benannt, weil später wan1 hinzu kam auf dem PPPoE läuft. WAN wurde mittlerweile in LAN1 umbenannt.

Quote from: JeGr on May 31, 2023, 12:41:29 PM

Für sowas gibt es bspw. MTR und Co, die wesentlich sinnvoller arbeiten und wieder schlicht ICMP Echo Requests nutzen anstatt UDP HighPorts die niemand gern offen hat. Deshalb - gerade auf der Konsole - lieber mal MTR anschauen, macht einem das Leben viel einfacher (auch wegen der besseren Darstellung und dem dauerhaften Weiterpingen mit Durschnitt etc..)

Cheers :)

Das mit MTR läuft, danke für den Tipp, dann lass ich mal die Ports geschlossen^^

Das wäre auch gut, wenn es das tool auf der opensense gäbe, zusätzlich zu standard routenverfolgung :-)

Grüße