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?
Wireguard - Kommunikationsaufbau aus beiden Tunnelrichtungen
Antworten |
Anmeldungsdatum: Beiträge: 180 |
|
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 16818 |
Das geht, wenn der Tunnel richtig konfiguriert ist und keine FW dazwischenfunkt. Ist diesbezüglich was konfiguriert? |
(Themenstarter)
Anmeldungsdatum: 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"? |
Anmeldungsdatum: Beiträge: 7529 |
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. |
Anmeldungsdatum: Beiträge: 13293 |
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). |
(Themenstarter)
Anmeldungsdatum: Beiträge: 180 |
Das mit dem FTP war lediglich um mein Beispiel zu verdeutlichen. Ich kann auch nicht von B zu A einen Ping senden.
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 |
Anmeldungsdatum: Beiträge: 13293 |
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 |
(Themenstarter)
Anmeldungsdatum: Beiträge: 180 |
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? |
Anmeldungsdatum: Beiträge: 13293 |
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. |
Anmeldungsdatum: 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!) |
Anmeldungsdatum: Beiträge: 13293 |
BTW: Wenn der Tunnel nicht permanent bestehen soll, macht "persistent keepalive" keinen Sinn. Es reicht dann keepalive nur beim WG-Client. |