IP redirect in Windows

[ZaZ]

Ik heb hier te maken met een interface die via een SSH tunnel loopt.
Een workstation connect naar de SSH client (onze kant) en die tunnelt naar een server aan de remote kant.
De server antwoordt met een ip waar het volgende 'bericht' naartoe moet.
Dit is een bekend ip en staat ook ingesteld in de tunnel, maar het probleem is dat de workstation natuurlijk niet rechtstreeks dat ip kan bereiken, want die zit aan de remote kant.

Kan ik het ip op een of andere manier 'vertalen' naar een ander ip, in mijn geval de SSH client?
Heb zo'n situatie wel eens eerder meegemaakt alleen werd toen de hostname teruggestuurd vanaf de server.
Toen was het makkelijk; Hosts file aanpassen en gassen.

Kan dit ook met een ip op Windows?

[barry457]

Gaat dit via een VPN tunnel? Dan moet je dit in de firewall instellen

[ZaZ]

Nee dit gaat niet via een VPN tunnel.

[mbaltus]

Het enige wat me mogelijk lijkt is dat je een route opgeeft naar dat IP adres (of de reeks) met als gateway je SSH client.
route ADD (dest.IP) MASK (netmask) (gateway ip) METRIC (metric waarde) IF (interface)

[ZaZ]

Ik zit even te stoeien met route add, maar het wil niet echt lukken
Bij wijze van test dacht ik even een redirect te doen van een RDP computer in ons netwerk

code:

route add 192.168.4.249 mask 255.255.255.255 192.168.4.1

Geeft OK
249 bestaat niet in ons netwerk en de .1 is een computer met RDP
Als ik nu naar .249 probeer te RDP'en dan gebeurt er helemaal niets

[real-doc]

Een SSH "tunnel" is niet veel meer dan een port forward, terwijl jij een complete routed L3 verbinding wil hebben naar het netwerk achter de remote server. Dat gaat natuurlijk niet werken.

Kan je niet je eigen proxy servertje in elkaar kloppen, desnoods in een scripting taal als Perl?

[DutchKel]

Dien je van dat ip een bepaalde poort te gebruiken dan kun je deze als lokale SSH tunnel instellen

lokaal poort: poort
remote adres: ip:poort

ip en poort is dus afhankelijk van jou situatie.

[ZaZ]

real-doc schreef op dinsdag 04 september 2012 @ 12:20:
Een SSH "tunnel" is niet veel meer dan een port forward, terwijl jij een complete routed L3 verbinding wil hebben naar het netwerk achter de remote server. Dat gaat natuurlijk niet werken.

Kan je niet je eigen proxy servertje in elkaar kloppen, desnoods in een scripting taal als Perl?

De ip's zijn fixed dus ik dacht hier wel mee weg te komen.
Probleem is dus ik krijg een IP ( is al een bekend IP voor ons) en dat IP staat al met SSH ingesteld naar de juiste computer in het remote netwerk.
Als ik daarop connect gaat het ook allemaal prima. Probleem is dat het geautomatiseerd gebeurt en ik dus eigenlijk wil dat bijv IP 10.10.10.10 naar 192.168.4.10 gaat (in dit voorbeeld is dat de SSH client) en die is al op de hoogte van dat IP.
Als ik dat ene adres kan 'mappen' dan ben ik uit de problemen.

Zijn er geen bestaande tools voor dit? Als ik zoek naar proxy software krijg ik een hele zooi met dingen die volgens mij niet doen wat ik wil.

[ZaZ]

kfaessen schreef op dinsdag 04 september 2012 @ 12:21:
Dien je van dat ip een bepaalde poort te gebruiken dan kun je deze als lokale SSH tunnel instellen

lokaal poort: poort
remote adres: ip:poort

ip en poort is dus afhankelijk van jou situatie.

De workstation in dit verhaal heeft zelf geen SSH tunnel. Anders zat ik er nog aan te denken om met een loopback adapter te gaan stoeien, hoewel dat dan wel heel erg ranzig wordt.

[LnC]

Ben nog een beetje lerend met betrekking tot netwerken, dus hoppelijk knal ik er geen onzin uit.

Na een beetje zoeken kwam ik dit voorbeeld nog tegen. Hij is dan vrijwel gelijk aan die je gepost had, maar met een kleine toevoeging:

code:

If you want the route to persist after a reboot, use the -p switch:

route -p add 69.94.73.28 mask 255.255.255.255 127.0.0.1

[Nether]

Je zou eens kunnen kijken naar tunnelier van bitvise.
Deze gebruik ik zelf in een vergelijkbare situatie.

[Compizfox]

Ik snap niet wat je bedoelt. Kun het nog even wat beter uitleggen?

Ik heb hier te maken met een interface die via een SSH tunnel loopt.

Een interface getunneld over SSH?

Een workstation connect naar de SSH client (onze kant) en die tunnelt naar een server aan de remote kant.

Wat is nou de client en wat de server? Je zegt de workstation connect naar een SSH client. Dan lijkt me de workstation juist de client, en die "SSH client" toch juist de server?

De server antwoordt met een ip waar het volgende 'bericht' naartoe moet.
Dit is een bekend ip en staat ook ingesteld in de tunnel, maar het probleem is dat de workstation natuurlijk niet rechtstreeks dat ip kan bereiken, want die zit aan de remote kant.

Hoe bedoel je dat precies?

Kan ik het ip op een of andere manier 'vertalen' naar een ander ip, in mijn geval de SSH client?
Heb zo'n situatie wel eens eerder meegemaakt alleen werd toen de hostname teruggestuurd vanaf de server.
Toen was het makkelijk; Hosts file aanpassen en gassen.

Kan dit ook met een ip op Windows?

Je hebt op je workstation een bepaalde poort getunneld naar een PC in het netwerk van de SSH server?
Dan kun je die remote PC bereiken op de localhost van de workstation.

Als je dus dit hebt:

Workstation | --------- internet --------- | Server - PC
Dan kun je dus poort x van de PC tunnelen naar (op de workstation) localhost:x.
Dus als je dan op je workstation localhost:x aanroept komt dat terecht op PC:x (omdat dat door de SSH tunnel gaat)

Je kunt trouwens ook SSH als SOCKS proxy laten fungeren. Je tunnelt dan localhost:x naar een dynamische bestemming aan de kant van de SSH server.
In een webbrowser geef je dan aan dat localhost:x de proxy is.

[ Voor 97% gewijzigd door Compizfox op 04-09-2012 12:52 ]

[ZaZ]

Compizfox schreef op dinsdag 04 september 2012 @ 12:45:
Ik snap niet wat je bedoelt.

Je hebt op je workstation een bepaalde poort getunneld naar een PC in het netwerk van de SSH server?
Dan kun je die remote PC bereiken op de localhost van de workstation.

Netwerk A (mijn netwerk)
Netwerk B (remote netwerk)

In netwerk A is een workstation en een andere computer die een tunnel heeft opgezet met verschillende portforwards naar verschillende computers in netwerk B

workstation (A) connect naar een bepaalde poort op SSH Client (A) die forward naar een service ( B )
die service zegt : "doe eens connecten op ip x" maar die is niet in ons netwerk.
In de SSH client (A) staat dat al wel ingesteld dat ie een bepaalde poort moet forwarden naar dat ip, maar de software die probeert te connecten is niet op de hoogte van het 'virtuele' netwerk en probeert dus keihard naar het ip te connecten.
Ik wil dus een keihard een ip dat niet bestaat redirecten naar de SSH client (A) en dan gaat alles goed.
Als dat ip een hostname zou zijn was ik met de hosts file uit de brand

edit:

Workstation en SSH client in netwerk A zijn dus verschillende computers

[ Voor 3% gewijzigd door ZaZ op 04-09-2012 13:00 ]

[Compizfox]

Aha, zo. Het gaat dus om een bepaalde applicatie die automatisch wil connecten op een bepaald IP.

Tja...

Je verhaal komt een beetje op me over alsof je Netwerk A en Netwerk B gewoon aan elkaar wilt knopen. Dan kun je denk ik toch het beste van een VPN-verbinding gebruik maken, dan heb je gewoon 1 virtueel netwerk (Netwerk A en Netwerk B samen) en heb je dit probleem niet.

SSH tunnels zijn handig als je 1 poort(range) naar 1 PC wilt forwarden, of als je een SOCKS proxy wilt opzetten. Als je meerdere port forwards naar meerdere IP's e.d. wilt hebben is een VPN toch handiger denk ik.

[Mijzelf]

ZaZ schreef op dinsdag 04 september 2012 @ 12:14:
Ik zit even te stoeien met route add, maar het wil niet echt lukken
Bij wijze van test dacht ik even een redirect te doen van een RDP computer in ons netwerk

code:

route add 192.168.4.249 mask 255.255.255.255 192.168.4.1

Geeft OK
249 bestaat niet in ons netwerk en de .1 is een computer met RDP
Als ik nu naar .249 probeer te RDP'en dan gebeurt er helemaal niets

Nee, dat gaat niet werken. Zo maak je een ethernet pakketje met als destination MAC adres die van 192.168.4.1. Maar het destination IP adres is 192.168.4.249. Het pakketje wordt gedropt, want 192.168.4.1 heeft dat adres niet, en is geen router.

Het *kan* zo wel, maar dan moet je 192.168.4.1 alle adressen geven die ook in dat andere netwerk bereikbaar moeten zijn.

[ZaZ]

Ok, bedankt, met route is dus niet echt een optie.
VPN behoort niet tot de mogelijkheden, dus ik moet opzoek naar een proxy tool ofzo?

[Compizfox]

Waarom behoort VPN niet tot de mogelijkheden? Het is gewoonweg het simpelst.

[ZaZ]

Omdat ik geen invloed heb op netwerk B. Daar draait toevallig een SSH server die ik mag gebruiken en daar moet ik het maar mee doen.

[Compizfox]

Tja, dan zou je die SSH-server als SOCKS proxy kunnen gebruiken: http://embraceubuntu.com/...rwarding-secure-browsing/
http://www.debian-adminis...ort_forwarding_with_SOCKS

Maar dan moet die applicatie die je op de workstation gebruikt het wel ondersteunen om een proxy te gebruiken.