Server aan VPN: verkeer selectief toch "buitenom" routen

[Verwijderd]

Beste iedereen,

Ik heb mijn server (192.168.0.1, met ook publiek IP) aan een VPN hangen, waarbij er een bepaald public netblock (het universiteitsnetwerk, zeg 131.211.8*.*) over het VPN gerouterd wordt. Echter, mijn server serveert ook wat webpagina's, maar die zijn vanaf het universiteitsnetwerk dus niet bereikbaar omdat de routing van de request response in de soep loopt.

Routing request:

Univ. ==> internet ==> server

Routing van de response:

server ==> VPN ==> Univ.

Natuurlijk kan ik de routing tables op het universiteitsnetwerk niet wijzigen, dus moet ik ervoor zien te zorgen dat mijn server requests "van buitenaf" ook "buitenom" beantwoordt. Heeft iemand enig idee hoe ik dat met iptables (het liefst in shorewall ) voor elkaar krijg?

[gertvdijk]

Verwijderd schreef op dinsdag 21 oktober 2008 @ 22:29:
Echter, mijn server serveert ook wat webpagina's, maar die zijn vanaf het universiteitsnetwerk dus niet bereikbaar omdat de routing van de request response in de soep loopt.

Weet je zeker dat je het gaat oplossen met routing tables? Luistert je webserver wel op de tun0 interface?

[Verwijderd]

Het gaat erom dat de request niet binnenkomt op m'n tunnel interfaces, maar buitenom komt. Vervolgens wordt die request echter beantwoordt via de tunnel interface en loopt de verbinding in de soep.

[_JGC_]

Je moet ook niet je standaard gateway aanpassen, maar alleen routeren wat er over het universiteitsnetwerk moet.
Zelf gebruik ik ipsec voor VPNs met isakmpd (ja, ik weet het: outdated BSD zooi uit 2005, maar het werkt ). Ik stel bij dat programma in dat ik 2 netwerken met elkaar wil verbinden, en vervolgens wordt alleen het verkeer tussen die 2 netwerken over de versleutelde verbinding gedaan.

[Verwijderd]

Klopt, ik heb ook niet mijn standaardgateway aangepast. Maar stel je voor dat ik zit te werken achter een machine met IP 131.211.81.15 en ik doe een TCP connection request naar mijn server. Geen enkele machine in het universiteitsnetwerk is zich bewust van mijn VPN verbinding, dus die request gaat gewoon buitenom, direct naar het externe IP van mijn server.

Vervolgens stuurt mijn server een TCP response, maar zal dit packet automatisch over het VPN routeren, aangezien mijn server wel op de hoogte is van het VPN. De machine waarachter ik zat te werken (131.211.81.15) krijgt vervolgens een TCP response terug van een onbekend IP (het VPN IP van mijn server) en negeert dat packet. Immers: de TCP request ging naar het externe IP van mijn server.

Mijn doel is om het externe (dus niet VPN) inkomende verkeer op mijn server te markeren en het bijbehorende uitgaande verkeer dus ook over de externe interface van mijn server te routeren.

[gertvdijk]

Verwijderd schreef op woensdag 22 oktober 2008 @ 01:12:
Klopt, ik heb ook niet mijn standaardgateway aangepast. Maar stel je voor dat ik zit te werken achter een machine met IP 131.211.81.15 en ik doe een TCP connection request naar mijn server.

Naar welk ip connect je dan? die van je "externe" interface of je VPN interface?

Verwijderd schreef op woensdag 22 oktober 2008 @ 01:12:
dus die request gaat gewoon buitenom, direct naar het externe IP van mijn server.

Vervolgens stuurt mijn server een TCP response, maar zal dit packet automatisch over het VPN routeren, aangezien mijn server wel op de hoogte is van het VPN. De machine waarachter ik zat te werken (131.211.81.15) krijgt vervolgens een TCP response terug van een onbekend IP (het VPN IP van mijn server) en negeert dat packet. Immers: de TCP request ging naar het externe IP van mijn server.

Ja dat zou wel gek zijn als dat binnen het protocol zou vallen. Dit is gewoon ip spoofing wat je probeert.

Verwijderd schreef op woensdag 22 oktober 2008 @ 01:12:
Mijn doel is om het externe (dus niet VPN) inkomende verkeer op mijn server te markeren en het bijbehorende uitgaande verkeer dus ook over de externe interface van mijn server te routeren.

Ah dus je wil connecties die op je "externe" interface gestart worden ook extern houden? Dat is toch hoe het out-of-the-box gaat?

[Verwijderd]

gertvdijk schreef op woensdag 22 oktober 2008 @ 01:24:
[...]

Ah dus je wil connecties die op je "externe" interface gestart worden ook extern houden? Dat is toch hoe het out-of-the-box gaat?

Nee, zo gaat het volgens mij dus niet out of the box. Als de routing table een regel bevat dat packets naar 131.211.81.15 over tun0 gestuurd moeten worden, dan gaan alle packets die tunnel over. Ook als een eerder packet van 131.211.81.15 via de "externe" interface eth0 is binnen gekomen!

Natuurlijk, correct me if I'm wrong...

[Verwijderd]

Het is me gelukt d.m.v. connection tracking (CONNMARK in iptables), dit alles in Shorewall. Het is heel eenvoudig: gewoon meerdere "providers" configureren en je kunt aangeven dat verkeer dat van een provider afkomstig is ook via diezelfde provider beantwoord moet worden.

Als er dus verkeer (ook vanaf het universiteitsnetwerk) op eth0 binnenkomt, dan wordt dat ook via eth0 beantwoord. Als er verkeer via tun1 (de VPN-verbinding) binnenkomt, dan wordt dat via tun1 beantwoord.

[Tim]

Je kan ook je routing tabel aanpassen:

ip rule from 131.uni.0.0 lookup table 1
ip route add default via 131.0.niet-vpn-gateway table 1

[lammert]

Wat Tes ^ zegt. Routing is hiervoor de aangewezen (en meest simpele) methode. Je kan voor elk subnet een route aangeven

VPN subnet --> gateway 1
default --> gateway 2

edit:

ik vermoed overigens dat shorewall dit achter de schermen ook zo regelt

[ Voor 20% gewijzigd door lammert op 22-10-2008 18:13 ]