staging.inyokaproject.org

Wireguard - Kommunikationsaufbau aus beiden Tunnelrichtungen

Status: Ungelöst | Ubuntu-Version: Ubuntu Budgie 22.04 (Jammy Jellyfish)
Antworten |

bigchris

Anmeldungsdatum:
1. November 2008

Beiträge: 180

Hallo, ich bin in der Lage einen Wireguard Tunnel aufzubauen. Von Client A zu einem Endpunkt B. Der Aufbau des Tunnels ist nur in dieser Richtung möglich. Der Datenverkehr funktioniert. Nun müsste ich eine Verbindung von B zu A aufbauen. Konkret, ein Rechner aus dem Netz B soll ein Backup auf einen Rechner in A schieben. Wie kann es es anstellen, dass bei bestehendem VPN-Tunnel ein Programm (z.B. FTP) von B zu A eine Verbindung aufbaut?

DJKUhpisse Team-Icon

Supporter, Wikiteam
Avatar von DJKUhpisse

Anmeldungsdatum:
18. Oktober 2016

Beiträge: 16818

Das geht, wenn der Tunnel richtig konfiguriert ist und keine FW dazwischenfunkt. Ist diesbezüglich was konfiguriert?

bigchris

(Themenstarter)

Anmeldungsdatum:
1. November 2008

Beiträge: 180

Ich denke nicht. Wie müsste man denn den Tunnel konfigurieren? Wenn der Tunnel steht, ist dann die Firewall nicht "aussen vor"?

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7529

bigchris schrieb:

Wie kann es es anstellen, dass bei bestehendem VPN-Tunnel ein Programm (z.B. FTP) von B zu A eine Verbindung aufbaut?

Wireguard ist einfach nur ein "verschlüsseltes Netzwerkkabel", wenn du darüber irgendwelche Dienste (FTP) laufen lassen willst, dann brauchst auf einer Seite einen FTP-Server, der seine Dienste auf dem Wireguard-Interface anbietet, und auf der anderen Seite ein FTP-Client. Aber FTP ist uralt und unzuverlässig, nimm lieber SSH/rsync, oder ein Netzwerkdateisystem, oder sonst etwas.

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 13293

bigchris schrieb:

Wie kann es es anstellen, dass bei bestehendem VPN-Tunnel ein Programm (z.B. FTP) von B zu A eine Verbindung aufbaut?

Welche Betriebssysteme hast Du auf A und auf B? Poste mal die richtig anonymisierte wg-Config (und alles was dazu gehört) von A und von B (wenn Du Linux oder gleichwertig benutzt).

bigchris

(Themenstarter)

Anmeldungsdatum:
1. November 2008

Beiträge: 180

frostschutz schrieb:

Wireguard ist einfach nur ein "verschlüsseltes Netzwerkkabel", wenn du darüber irgendwelche Dienste (FTP) laufen lassen willst, dann brauchst auf einer Seite einen FTP-Server, der seine Dienste auf dem Wireguard-Interface anbietet, und auf der anderen Seite ein FTP-Client. Aber FTP ist uralt und unzuverlässig, nimm lieber SSH/rsync, oder ein Netzwerkdateisystem, oder sonst etwas.

Das mit dem FTP war lediglich um mein Beispiel zu verdeutlichen. Ich kann auch nicht von B zu A einen Ping senden.

lubux schrieb:

Welche Betriebssysteme hast Du auf A und auf B? Poste mal die richtig anonymisierte wg-Config (und alles was dazu gehört) von A und von B (wenn Du Linux oder gleichwertig benutzt).

Ich benutze auf beiden Seiten Linux.

A:

root@wireguard:~# cat chris-arbeit.conf 
[Interface]
Address = 10.7.0.4/24
DNS = 10.10.10.1
PrivateKey = hierstehteinprivatekey

[Peer]
PublicKey = hierstehteinpublickey
PresharedKey = hierstehteinpresharedkey
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = meinendpunkt.de:51820
PersistentKeepalive = 25

B:

root@wireguard:/etc/wireguard# cat wg0.conf 
# Do not alter the commented lines
# They are used by wireguard-install
# ENDPOINT csja.de

[Interface]
Address = 10.7.0.1/24
PrivateKey = hierstehteinprivatekey
ListenPort = 51820

# BEGIN_PEER chris-arbeit
[Peer]
PublicKey = hierstehteinpublickey
PresharedKey = hierstehteinpresharedkey
AllowedIPs = 10.7.0.4/32
# END_PEER chris-arbeit

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 13293

bigchris schrieb:

Ich benutze auf beiden Seiten Linux.

A:

root@wireguard:~# cat chris-arbeit.conf 
[Interface]
Address = 10.7.0.4/24
DNS = 10.10.10.1
PrivateKey = hierstehteinprivatekey

[Peer]
PublicKey = hierstehteinpublickey
PresharedKey = hierstehteinpresharedkey
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = meinendpunkt.de:51820
PersistentKeepalive = 25

Versuch mal (temporär) auf A-Seite mit:

# DNS = 10.10.10.1
DNS = 1.1.1.1
# AllowedIPs = 0.0.0.0/0, ::/0
AllowedIPs = 10.7.0.1/32

Poste nach wirksam werden der Änderungen, von A- und B-Seite, die Ausgaben von: A-Seite:

sudo iptables -nvx -t nat -L POSTROUTING
sudo iptables-legacy -nvx -t nat -L POSTROUTING
ip r
ip r g 10.7.0.1
ping -c 3 10.7.0.1

und von B-Seite:

sudo iptables -nvx -t nat -L POSTROUTING
sudo iptables-legacy -nvx -t nat -L POSTROUTING
ip r
ip r g 10.7.0.4
ping -c 3 10.7.0.4

bigchris

(Themenstarter)

Anmeldungsdatum:
1. November 2008

Beiträge: 180

lubux schrieb:

Versuch mal (temporär) auf A-Seite mit:

# DNS = 10.10.10.1
DNS = 1.1.1.1
# AllowedIPs = 0.0.0.0/0, ::/0
AllowedIPs = 10.7.0.1/32

Poste nach wirksam werden der Änderungen, von A- und B-Seite, die Ausgaben von: A-Seite:

sudo iptables -nvx -t nat -L POSTROUTING
sudo iptables-legacy -nvx -t nat -L POSTROUTING
ip r
ip r g 10.7.0.1
ping -c 3 10.7.0.1

und von B-Seite:

sudo iptables -nvx -t nat -L POSTROUTING
sudo iptables-legacy -nvx -t nat -L POSTROUTING
ip r
ip r g 10.7.0.4
ping -c 3 10.7.0.4

Ausgaben A:

christian@christian-thinkstation:~$ sudo iptables -nvx -t nat -L POSTROUTING
# Warning: iptables-legacy tables present, use iptables-legacy to see them
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
christian@christian-thinkstation:~$ sudo iptables-legacy -nvx -t nat -L POSTROUTING
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
christian@christian-thinkstation:~$ ip r
default via 172.30.0.2 dev ens18 proto dhcp metric 100 
10.7.0.0/24 dev wg0 proto kernel scope link src 10.7.0.4 
169.254.0.0/16 dev ens18 scope link metric 1000 
172.30.0.0/24 dev ens18 proto kernel scope link src 172.30.0.127 metric 100 
christian@christian-thinkstation:~$ ip r g 10.7.0.1
10.7.0.1 dev wg0 src 10.7.0.4 uid 1000 
    cache 
christian@christian-thinkstation:~$ ping -c 3 10.7.0.1
PING 10.7.0.1 (10.7.0.1) 56(84) bytes of data.
64 bytes from 10.7.0.1: icmp_seq=1 ttl=64 time=13.3 ms
64 bytes from 10.7.0.1: icmp_seq=2 ttl=64 time=12.1 ms
64 bytes from 10.7.0.1: icmp_seq=3 ttl=64 time=13.0 ms

--- 10.7.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 12.061/12.771/13.279/0.517 ms

Ausgaben B:

root@wireguard:~# iptables -nvx -t nat -L POSTROUTING 
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
    5929   554244 SNAT       all  --  *      *       10.7.0.0/24         !10.7.0.0/24          to:10.10.10.249
root@wireguard:~# iptables-legacy -nvx -t nat -L POSTROUTING
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
root@wireguard:~# ip r
default via 10.10.10.1 dev eth0 proto static 
10.7.0.0/24 dev wg0 proto kernel scope link src 10.7.0.1 
10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.249 
root@wireguard:~# ip r g 10.7.0.4
10.7.0.4 dev wg0 src 10.7.0.1 uid 0 
    cache 
root@wireguard:~# ping -c 3 10.7.0.4
PING 10.7.0.4 (10.7.0.4) 56(84) bytes of data.
64 bytes from 10.7.0.4: icmp_seq=1 ttl=64 time=10.9 ms
64 bytes from 10.7.0.4: icmp_seq=2 ttl=64 time=11.4 ms
64 bytes from 10.7.0.4: icmp_seq=3 ttl=64 time=11.4 ms

--- 10.7.0.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 10.929/11.226/11.383/0.210 ms

So pingt er in beide Richtungen. Kannst du mir ein bisschen erklären was du gemacht hast? Aktuell erreiche ich dann nur den einen Endpunkt und nicht mehr wie vorher die anderen Rechner im Netzwerk. Das geht bestimmt auch anders?

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 13293

bigchris schrieb:

Ausgaben A:

      
christian@christian-thinkstation:~$ ip r
default via 172.30.0.2 dev ens18 proto dhcp metric 100 
10.7.0.0/24 dev wg0 proto kernel scope link src 10.7.0.4 

Ausgaben B:

root@wireguard:~# iptables -nvx -t nat -L POSTROUTING 
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
    5929   554244 SNAT       all  --  *      *       10.7.0.0/24         !10.7.0.0/24          to:10.10.10.249       
root@wireguard:~# ip r
default via 10.10.10.1 dev eth0 proto static 
10.7.0.0/24 dev wg0 proto kernel scope link src 10.7.0.1 

So pingt er in beide Richtungen. Kannst du mir ein bisschen erklären was du gemacht hast?

Ich habe gar nichts gemacht. Evtl. hängt es damit zusammen in welcher Reihenfolge Du die Pings gemacht hast. Was man sieht ist, dass auf beiden Seiten kein sauberes source-NAT (MASQUEARDE) konfiguriert ist. Versuch mal mit:

Seite A:

sudo iptables -t nat -I POSTROUTING 1 -o wg0 -j MASQUERADE
sudo iptables -t nat -I POSTROUTING 2 -o ens18 -j MASQUERADE

und auf Seite B mit:

sudo iptables -t nat -I POSTROUTING 1 -o wg0 -j MASQUERADE
sudo iptables -t nat -I POSTROUTING 2 -o eth0 -j MASQUERADE

Danach testen und wenn das zuverlässig funktioniert, kannst Du diese iptables-Regeln persistent machen.

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7529

Setze auf beiden Seiten ein persistent keepalive. Wenn da irgendwo ein Router zwischen sitzt, vergisst der nach einer Weile sonst gerne, daß da noch eine Verbindung war. Und dann funktioniert der Tunnel erst wieder, wenn die Seite hinter dem Router ein neues Paket schickt.

(Edit: Hast du scheinbar schon. Übersehen, sorry!)

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 13293

frostschutz schrieb:

Setze auf beiden Seiten ein persistent keepalive.

BTW: Wenn der Tunnel nicht permanent bestehen soll, macht "persistent keepalive" keinen Sinn. Es reicht dann keepalive nur beim WG-Client.

Antworten |