[iptables] SNAT: unknown option "--to-source ???

[ajvdvegt]

Op mijn Synology Diskstation draai ik een OpenVPN server. Daar legt zet client (raspberry pi) een vpn verbinding mee op.

Nu wil ik wil het verkeer dat op een bepaalde poort op mijn Synology binnenkomt, doorsturen naar de RaspberryPi. Ik volg de aanwijzingen die onze gebruiker DSK hier zette: http://jensd.be/343/linux...t-using-nat-with-iptables.

Ik voer deze commando's uit:

code:

$ sudo iptables -t nat -A PREROUTING -p tcp --dport <myport> -j DNAT --to-destination 10.8.0.6:80
$ sudo iptables -t nat -A POSTROUTING -p tcp -d 10.8.0.6 --dport 80 -j SNAT --to-source 10.8.0.1
iptables v1.6.0: unknown option "--to-source"

De eerste opdracht gaat dus goed, maar die tweede: hoe zo 'unknown option'??? Ook de man page en andere sites geven deze optie. Ik doe vast iets anders fout, maar ik zie niet wat...

[ Voor 3% gewijzigd door ajvdvegt op 12-11-2017 22:06 . Reden: verheldering ]

[blaataaps]

Hier staat in de man-page bij SNAT:

code:

       --to ipaddr[-ipaddr]
              Addresses to map source to. May be specified more than once for multiple ranges.

Wat blijkbaar afhangt van de leeftijd, en werkt zo te zien beide niet op synology, volstaat -j MASQUERADE misschien?

edit:
update

[ Voor 29% gewijzigd door blaataaps op 13-11-2017 19:20 ]

[ajvdvegt]

--to werkt inderdaad niet:

code:

$ sudo iptables -t nat -A POSTROUTING -p tcp -d 10.8.0.6  -j SNAT --to 10.8.0.2
iptables v1.6.0: unknown option "--to"

Omdat ik op de synology geen man-pages heb (blijkbaar heeft versie 1.6.0 niet overal de zelfde commandline switches ??), probeerde ik nog wat andere opties. Deze gaf een interessant resultaat:

code:

$ sudo iptables -t nat -A POSTROUTING -p tcp -d 10.8.0.6  -j SNAT --source 10.8.0.2
iptables v1.6.0: Couldn't load target `SNAT':No such file or directory

Iemand die dit snapt?

Update: het target dat na '-j' staat wordt gezocht in /lib/iptables/, en daar mist idd SNAT . MASQUERADE staat er wel!

Ik ga me eens in MASQUERADE verdiepen, tnx.

[ Voor 9% gewijzigd door ajvdvegt op 13-11-2017 21:15 ]

[ajvdvegt]

Ok, zolang ik op m'n eigen LAN zit werkt dit (ik wil uiteindelijk 2 pi's aansluiten, elk op een eigen poort bereikbaar):

code:

# Setup rpi 1:
/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 8126 -j DNAT --to-destination 10.8.0.6:80
/sbin/iptables -t nat -p tcp -A POSTROUTING -o tun0 -d 10.8.0.6 -j MASQUERADE --to-ports 80

# Setup rpi 2:
/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 8127 -j DNAT --to-destination 10.8.0.7:80
/sbin/iptables -t nat -p tcp -A POSTROUTING -o tun0 -d 10.8.0.7 -j MASQUERADE --to-ports 80

# Make sure existng connections are forwarded:
/sbin/iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT

Ik heb op m'n router (die tussen het internet en m'n Diskstation) zit poorten geforward naar 8126 en 8127. Als ik vanaf m'n laptop mijn externe adres gebruik, lijkt de hele keten te werken. Probeer ik het echter op m'n telefoon, dan krijg ik een timeout (vreemd genoeg zowel via Wifi als via 4G).

Het moet ongeveer zo gaan werken:


Heeft iemand enig idee wat er mis is? Ik heb het gevoel dat de routing terug misschien nog niet goed is?

[ Voor 3% gewijzigd door ajvdvegt op 17-11-2017 22:04 . Reden: Plaatje toegevoegd ]

[Hero of Time]

Waarom heb je de VPN er tussen gezet? Is het niet eenvoudiger om gewoon poorten te forwarden van je diskstation direct naar de Pi op hetzelfde netwerk? En waarom doe je dit niet direct via je router?

Als je wilt weten wat er mogelijk nog gebeurt met het verkeer, of het aankomt of niet, draai dan tcpdump op verschillende plekken (op de diskstation en je pi) om te zien of er wel verkeer binnen komt om te verwerken en of er een antwoord uit gaat.

[Thralas]

ajvdvegt schreef op vrijdag 17 november 2017 @ 21:47:

code:

/sbin/iptables -t nat -p tcp -A POSTROUTING -o tun0 -d 10.8.0.6 -j MASQUERADE --to-ports 80

Naast wat hierboven staat (repeat after me: tcpdump is de sleutel tot succes) is deze rule bogus:
--to-ports slaat hier nergens op; waarschijnlijk bedoelde je --dport?

Afhankelijk van je doel van de VPN vraag ik me ook af of die SNAT (MASQUERADE) de meest correcte oplossing is..

[ajvdvegt]

Hero of Time schreef op vrijdag 17 november 2017 @ 23:04:
Waarom heb je de VPN er tussen gezet?

Goed punt! De Pi's hangen aan het internet via een 3G verbinding (een t-mobile sim in een Huawei B683 router). Die krijgt steeds een ander IP-adres, en dns wil niet werken. Maar het belangrijkste probleem: inkomende verbindingen lijken niet door te komen (ligt volgens mij aan aan T-mobile).

Thuis heb ik al jaren hetzelfde IP-adres, dus ik dacht met de VPN-verbinding al die problemen in 1x op te lossen.

Thralas schreef op zaterdag 18 november 2017 @ 10:29:
... is deze rule bogus:
--to-ports slaat hier nergens op; waarschijnlijk bedoelde je --dport?

Ja, het lijkt er op dat ik --dport bedoelde.

Afhankelijk van je doel van de VPN vraag ik me ook af of die SNAT (MASQUERADE) de meest correcte oplossing is..

Ik sta open voor andere suggesties! Wat ik zal als alternatief bedacht had: gewoon een SSH verbinding opzetten van de Pi's naar m'n huis en met SSH de poorten forwarden.


Hmm, dat is misschien nog niet eens een slecht idee!

[ Voor 33% gewijzigd door ajvdvegt op 21-11-2017 21:38 . Reden: 2de reactie toegevoegd. ]