Shit, jeg er helt skeløjet efter at have brugt det meste af dagen på at prøve at få en VPN-gateway til at opføre sig ordentligt, og jeg mangler stadig at få den til at route trafik korrekt fra ydersiden til hosts på indersiden 😵💫
-
Shit, jeg er helt skeløjet efter at have brugt det meste af dagen på at prøve at få en VPN-gateway til at opføre sig ordentligt, og jeg mangler stadig at få den til at route trafik korrekt fra ydersiden til hosts på indersiden
Hvis jeg kender en Strongswan-troldkarl (M/K), kunne jeg godt bruge lidt hjælp.
Klienter (udenfor) får en virtuel IP fra et 10.10.10.0/24 subnet, og subnettet på indersiden er 10.135.0.0/16. Lige nu kan klienterne ikke få hul igennem til hosts på indersiden.
Skal jeg lave trylletricks med iptables for at klienter kan snakke med hosts?
-
Hvis jeg kender en Strongswan-troldkarl (M/K), kunne jeg godt bruge lidt hjælp.
Klienter (udenfor) får en virtuel IP fra et 10.10.10.0/24 subnet, og subnettet på indersiden er 10.135.0.0/16. Lige nu kan klienterne ikke få hul igennem til hosts på indersiden.
Skal jeg lave trylletricks med iptables for at klienter kan snakke med hosts?
-
@nerdd uff, lyder ikke godt
@klgn Det handler sikkert om et eller andet, der mangler i iptables. Som jeg har ca. nul forstand på
(tak for boost! 
) -
@klgn Det handler sikkert om et eller andet, der mangler i iptables. Som jeg har ca. nul forstand på
(tak for boost! )@nerdd kan sagtens være, mine networking skills kommer også til kort her.
Velbekomme, glad for, det var ok -
T tofticles@helvede.net shared this topic
-
@nerdd kan sagtens være, mine networking skills kommer også til kort her.
Velbekomme, glad for, det var ok@klgn Hvis mine toots kan boostes, er det alti’ alti' ok at booste
-
F folfdk@helvede.net shared this topic
-
Hvis jeg kender en Strongswan-troldkarl (M/K), kunne jeg godt bruge lidt hjælp.
Klienter (udenfor) får en virtuel IP fra et 10.10.10.0/24 subnet, og subnettet på indersiden er 10.135.0.0/16. Lige nu kan klienterne ikke få hul igennem til hosts på indersiden.
Skal jeg lave trylletricks med iptables for at klienter kan snakke med hosts?
@nerdd ikke en strongswan troldkarl, men sidste gang jeg lavede noget lignende (med wireguard) så skulle jeg slå ip forwarding til på debian serveren (net.ipv4.ip_forward) og så skal der være noget “iptables forward accept” i updown scriptet. Håber det hjælper og at en rigtig troldkarl kommer snart
-
Hvis jeg kender en Strongswan-troldkarl (M/K), kunne jeg godt bruge lidt hjælp.
Klienter (udenfor) får en virtuel IP fra et 10.10.10.0/24 subnet, og subnettet på indersiden er 10.135.0.0/16. Lige nu kan klienterne ikke få hul igennem til hosts på indersiden.
Skal jeg lave trylletricks med iptables for at klienter kan snakke med hosts?
@nerdd Du har husket at slå forwarding til på serveren?
https://docs.strongswan.org/docs/latest/howtos/forwarding.html#_forwarding_client_traffic
Kender ikke til Strongswan, men det er absolut den fejl jeg ville lave.
-
@nerdd Du har husket at slå forwarding til på serveren?
https://docs.strongswan.org/docs/latest/howtos/forwarding.html#_forwarding_client_traffic
Kender ikke til Strongswan, men det er absolut den fejl jeg ville lave.
@nerdd I øvrigt ville jeg først som sidst køre en tcpdump på klient, vpn gateway og host bag vpn for at se hvor langt pakker kommer.
-
@nerdd ikke en strongswan troldkarl, men sidste gang jeg lavede noget lignende (med wireguard) så skulle jeg slå ip forwarding til på debian serveren (net.ipv4.ip_forward) og så skal der være noget “iptables forward accept” i updown scriptet. Håber det hjælper og at en rigtig troldkarl kommer snart
@gunnar Er et updown script noget, der bliver eksekveret, når en klient opretter forbindelse og afbryder? `net.ipv4.ip_forward` har jeg husket
-
Det er jo noget der kan bringes til at virke, men ofte vil jeg starte med at anbefale Wireguard istedet
Men fortæl gerne hvad vejledning du har fulgt.
-
@nerdd I øvrigt ville jeg først som sidst køre en tcpdump på klient, vpn gateway og host bag vpn for at se hvor langt pakker kommer.
@pmakholm `net.ipv4.ip_forward = 1` har jeg husket. tcpdump må jeg give et skud. Det interessante er, at jeg kan pinge gatewayens interne ip, men jeg kan ikke ssh’e til den, selv om sshd lytter på både den eksterne og interne ip. Andre hosts på netværket kan jeg ikke nå med pings.
-
@gunnar Er et updown script noget, der bliver eksekveret, når en klient opretter forbindelse og afbryder? `net.ipv4.ip_forward` har jeg husket
-
@pmakholm `net.ipv4.ip_forward = 1` har jeg husket. tcpdump må jeg give et skud. Det interessante er, at jeg kan pinge gatewayens interne ip, men jeg kan ikke ssh’e til den, selv om sshd lytter på både den eksterne og interne ip. Andre hosts på netværket kan jeg ikke nå med pings.
@nerdd Hvis du kan pinge men ikke ssh'e gatewayen, så tænker jeg umiddelbart firewall.
Der er jeg nok for rusten af bare at have brugt noget simpelt ufw. Så hvordan du debugger det, er jeg ikke helt sikker på.
Alternativet, som jeg ville se efter med tcpdump, er noget routing. For eksempel hvis jeg kunne se at der kom en ssh pakke frem til en host på indersiden og sshd sendte en svar-pakke, men den ikke kom frem til gatewayen.
-
-
@kramse Jeg er i gang med at flytte et gammelt setup fra Digital Ocean til Hetzner, så jeg har egentlig bare oversat en eksisterende /etc/ipsec.conf til /etc/swanctl/swanctl.conf. I sin tid brugte jeg https://www.digitalocean.com/community/tutorials/how-to-set-up-an-ikev2-vpn-server-with-strongswan-on-ubuntu-18-04-2, men skippede punkt 6, fordi vi brugte den eksterne firewall hos Digital Ocean.
-
@nerdd Hvis du kan pinge men ikke ssh'e gatewayen, så tænker jeg umiddelbart firewall.
Der er jeg nok for rusten af bare at have brugt noget simpelt ufw. Så hvordan du debugger det, er jeg ikke helt sikker på.
Alternativet, som jeg ville se efter med tcpdump, er noget routing. For eksempel hvis jeg kunne se at der kom en ssh pakke frem til en host på indersiden og sshd sendte en svar-pakke, men den ikke kom frem til gatewayen.
@pmakholm Det eneste, jeg har af firewall kørende på gatewayen er iptables, hvor der bliver tilføjet et par “forward accept” regler mellem de virtuelle ip'er og subnettet på indersiden, når klienter opretter en forbindelse: En regel hvor virtuel ip er source og subnet destination og en regel, hvor det er omvendt.
-
-
@pmakholm Det eneste, jeg har af firewall kørende på gatewayen er iptables, hvor der bliver tilføjet et par “forward accept” regler mellem de virtuelle ip'er og subnettet på indersiden, når klienter opretter en forbindelse: En regel hvor virtuel ip er source og subnet destination og en regel, hvor det er omvendt.
@pmakholm Hm, når jeg prøver at ssh'e til 10.135.0.3, som er gatewayens interne ip, og jeg lytter på det interface med tcpdump, ser jeg pakker med “10.10.10.1.58571 > 10.135.87.234.ssh”. 10.135.87.234 virker sært, synes jeg.
-
Hvis jeg kender en Strongswan-troldkarl (M/K), kunne jeg godt bruge lidt hjælp.
Klienter (udenfor) får en virtuel IP fra et 10.10.10.0/24 subnet, og subnettet på indersiden er 10.135.0.0/16. Lige nu kan klienterne ikke få hul igennem til hosts på indersiden.
Skal jeg lave trylletricks med iptables for at klienter kan snakke med hosts?
Hm, jeg har gravet mere i det.
Jeg opretter en VPN-forbindelse til gatewayen og får ip 10.10.10.1, og så kan jeg pinge gatewayens interne IP (10.135.0.3), og når jeg bruger tcpdump på det eksterne interface, ser jeg pakkerne. Når jeg pinger en anden host, ser jeg dem også, men det kan jeg i tcpdump på den anden host.
Når jeg så prøver at ssh’e til gatewayens interne ip, ser jeg dette:
"IP 10.10.10.1.58785 > 10.135.87.234.ssh”
Hvad pokker går 10.135.87.234 ud på?
-
Hm, jeg har gravet mere i det.
Jeg opretter en VPN-forbindelse til gatewayen og får ip 10.10.10.1, og så kan jeg pinge gatewayens interne IP (10.135.0.3), og når jeg bruger tcpdump på det eksterne interface, ser jeg pakkerne. Når jeg pinger en anden host, ser jeg dem også, men det kan jeg i tcpdump på den anden host.
Når jeg så prøver at ssh’e til gatewayens interne ip, ser jeg dette:
"IP 10.10.10.1.58785 > 10.135.87.234.ssh”
Hvad pokker går 10.135.87.234 ud på?
Ooooog nu gik der en prås op for Rasmus!
10.135.87.234 er den interne ip på VPN'en ved den udbyder, jeg er ved at flytte væk fra, og jeg havde i min lokale ~/.ssh/config flg. stående:
Host 10.135.* !10.135.87.234
ProxyJump 10.135.87.234Når jeg opdaterer det til:
Host 10.135.* !10.135.0.3
ProxyJump 10.135.0.3Så virker det hele!
