[debian etch] twee gateways, services op verschillend ip

Pagina: 1
Acties:

  • pinockio
  • Registratie: Juli 2001
  • Laatst online: 23-12-2025
Situatie:

Debian etch server, met twee nics, twee ISP-verbindingen.

eth0: 192.168.1.88, verbonden via router 192.168.1.2 en ADSL-lijn

eth1: 92.x.x.x, publiek adres (Siemens ADSL router, KPN Business ADSL). Default route is 92.x.x.y.

Op 92.x moet een SSL-server draaien. Verder wil ik alle poorten sluiten via iptables behalve dus 443.

Ik wil op 192.x (wat ook het interne netwerk is) ssh en nog andere services draaien, naast een OpenVPN-server. (Deze kunnen voorlopig niet op het publieke adres komen).

Er hoeft niet gerouteerd te worden tussen de verschillende nics.

Ik heb begrepen dat dit via iproute2 moet maar in de howto (http://lartc.org/howto/index.html) kom ik dit voorbeeld niet tegen.

Eigenlijk is het simpel: alle verkeer moet via de default route gaan (192.168.99.2) behalve SSL-verkeer.

Hoe kan ik ALLE verkeer voor de SSL-server via 92.x.x.y laten lopen?

Kan dit met iproute2 of met iptables?

Disclaimer: P. aanvaardt geen aansprakelijkheid op grond van dit bericht.


  • blaataaps
  • Registratie: Juli 2001
  • Niet online
Wil je dat al het SSL-verkeer via die verbinding gaat, of gewoon het verkeer dat ook op die verbinding binnenkomt? Hoewel het niet zoveel uitmaakt qua instellingen, zou ik gewoon het laatste doen, en dan zal iets als de juiste route-tabel maken, en dan
ip rule add from KPN-IP lookup kpn_table
doen. Source (of eigenlijk policy) based routing staat wel uitgelegd op http://lartc.org/ , alleen denk je volgens mij dat je situatie ingewikkelder is dan eigenlijk het geval is :)

  • pinockio
  • Registratie: Juli 2001
  • Laatst online: 23-12-2025
Ah, dat dacht ik al... het moet simpel te doen zijn.

In principe gaat er over eth1 alleen SSL-verkeer. Momenteel gaat dit nog over eth0, maar op den duur gaat alle SSL-verkeer over eth1.

[ Voor 28% gewijzigd door pinockio op 05-11-2008 10:29 ]

Disclaimer: P. aanvaardt geen aansprakelijkheid op grond van dit bericht.


  • blaataaps
  • Registratie: Juli 2001
  • Niet online
"In principe" betekent niet direct dat dat dan ook de juiste heuristiek is je routing op te baseren, want er is vast ook wel ssl-verkeer over de andere lijn, en het eigenlijke probleem is dat je verkeer met het source-adres van die verbinding over die verbinding naar buiten wil sturen, dus dan kun je ook beter dat als criterium gebruiken denk ik :)

  • pinockio
  • Registratie: Juli 2001
  • Laatst online: 23-12-2025
Hmm.... hopelijk begrijp ik wat je bedoelt. Op eth1 moet straks de Apache server draaien die nu nog via eth0 gaat. Er is dan nog wel webmin aanwezig op eth0.

Wat bedoel je met kpn_table?
blaataaps schreef op woensdag 05 november 2008 @ 10:25:
ip rule add from KPN-IP lookup kpn_table
Is dit:
ip rule add from 92.x.x.y lookup kpn_table

KPN-IP is dat de gateway op de business adsl-verbinding?
En kpn_table, waar moet ik die definieren?

Disclaimer: P. aanvaardt geen aansprakelijkheid op grond van dit bericht.


  • blaataaps
  • Registratie: Juli 2001
  • Niet online
In /etc/iproute2/rt_tables als ik me niet vergis KPN-IP is het ip van die interface, en het gateway-adres zet je in de route-tabel die je "kpn_table" noemt, of hoe je maar wil :)
http://lartc.org/howto/lartc.rpdb.html#LARTC.RPDB.SIMPLE gaat precies over jouw geval volgens mij, routering op basis van source-adres.

  • pinockio
  • Registratie: Juli 2001
  • Laatst online: 23-12-2025
blaataaps schreef op woensdag 05 november 2008 @ 10:40:
In /etc/iproute2/rt_tables als ik me niet vergis KPN-IP is het ip van die interface, en het gateway-adres zet je in de route-tabel die je "kpn_table" noemt, of hoe je maar wil :)
http://lartc.org/howto/lartc.rpdb.html#LARTC.RPDB.SIMPLE gaat precies over jouw geval volgens mij, routering op basis van source-adres.
Deels, want mijn geval is eigenlijk nog simpeler, de debian-server is geen router. Echter, aan het eind zegt de auteur:
And we are done. It is left as an exercise for the reader to implement this in ip-up.
Daar gaat het mis. Al eerder trouwens, want ik heb nu in /etc/iproute2/rt_tables o.a. staan:

1 adsl_table
2 kpn_table

Maar hoe weet de kernel wat adsl_table is? Waar definieer ik dat?

Disclaimer: P. aanvaardt geen aansprakelijkheid op grond van dit bericht.


  • blaataaps
  • Registratie: Juli 2001
  • Niet online
Dat definieren heb je gedaan door het in dat bestand te zetten :)
Net zoals je bijvoorbeeld niks meer hoeft te doen als je een hostname+ip in je hosts-file zet, is dit genoeg en kun je nu die namen gebruiken.

  • pinockio
  • Registratie: Juli 2001
  • Laatst online: 23-12-2025
Ik doel eigenlijk op:
blaataaps schreef op woensdag 05 november 2008 @ 10:25:
dan zal iets als de juiste route-tabel maken, (...)
Je verwijst naar die route-tabel met kpn_table? Maar.... Waar heb je die "gemaakt"? Natuurlijk staat er een "verwijzing" naar die route-tabel in rt_tables. Maar de kernel kan daar toch niets mee als niet elders staat wat kpn_table betekent?

Er is nog een probleem. Momenteel krijgt eth1 een ip-adres op basis van dhcp (belachelijk lange leasetijd dus dat is geen probleem). Maar daarmee wordt ook een default route toegevoegd. En deze krijgt blijkbaar automatisch de voorkeur boven eth0, want als eth1 up is, is er geen verkeer mogelijk met o.a. de ssh-server die op eth0 draait van buitenaf. (Wel vanaf het interne netwerk.)

Handmatig het ip-adres toevoegen en de gateway weglaten uit /etc/network/interfaces helpt ook niet, want dan is alsnog mijn ssl-server onbereikbaar. Blijkbaar is dit nodig om verkeer mogelijk te maken. Echter, ik wil niet dat alle verkeer over deze interface gaat!

Ik moet de dingen nog eens op een rijtje zetten. Het lijkt allemaal zo simpel, maar dat is het absoluut niet. Ik ben hier al uren mee bezig.

Het is blijkbaar nog te vroeg, gisteravond te laat, want ik snap er steeds minder van.

Edit:
Er begint me iets te dagen, want over wat je in twee woorden "route-tabel maken" noemt zeggen ze:
Now all that is left is to generate John's table, and flush the route cache:

# ip route add default via 195.96.98.253 dev ppp2 table John
# ip route flush cache
Dus dan zou ik moeten doen:
# ip route add default via 92.x.x.x dev eth1 table kpn_table
#ip route flush cache

Dit kan trouwens alleen als eth1 "up" is, anders krijg ik een link down. En ik denk niet dat dat default moet zijn, want dan zou alle verkeer via eth1 gaan.

Waar zou ik dit moeten invoeren om e.a.a. tijdens het starten meteen te activeren?

Overigens: ik heb dit allemaal gedaan, en dan nog is het niet mogelijk poort 443 van buitenaf te benaderen via eth1. Er klopt iets dus niet.

Ik geloof dat ik hier iets beters heb:
http://www.linuxhorizon.ro/iproute2.html

[ Voor 54% gewijzigd door pinockio op 05-11-2008 11:36 ]

Disclaimer: P. aanvaardt geen aansprakelijkheid op grond van dit bericht.


  • pinockio
  • Registratie: Juli 2001
  • Laatst online: 23-12-2025
Ook die tweede howto werkt gewoon niet (in dit geval kende iptables de gebruikte commando's niet).

De howto's gaan allemaal over routers, en deze server is GEEN router.

Heeft iemand een idee hoe ik dit simpel kan regelen (moet te doen zijn):


1. eth0 voor internet (default gateway zit in dit netwerk)

2. eth1 ALLEEN voor SSL-verkeer. Alle verkeer dat daar binnenkomt (alleen op poort 443 dus) moet ook weer daar uit.

Wat dus heel belangrijk is, dat is dat eth0 altijd vanaf internet bereikbaar moet zijn. Omdat dit via een router gaat moet de default gateway het ip-adres van die router hebben. Als ik dat namelijk niet instel is de server niet meer bereikbaar vanaf internet via eth0.


eth0 - router - internet

eth0 - internet

[ Voor 27% gewijzigd door pinockio op 07-11-2008 13:19 ]

Disclaimer: P. aanvaardt geen aansprakelijkheid op grond van dit bericht.


Verwijderd

Volgens mij wil je een relatief complexe setup maken, maar wil je je vooral niet te druk maken om de manier waarop. Als het maar werkt.

Als ik jou was zou ik eens kijken naar Shorewall (daar is gewoon een Debian package voor beschikbaar). Dit stukje software stelt je in staat om te definieren /wat/ je wil, dan zoekt de software wel uit met welke commando's dat moet gebeuren. Je gaat dus als het ware op een hoger abstractieniveau configureren.

Je zult misschien even moeten wennen aan de manier waarop Shorewall de zaken geconfigureerd wil zien, maar de documentatie is bijzonder compleet, zie www.shorewall.net

Ik gebruik het op dit moment op een server met 2 ISP-verbindingen, een LAN en meerdere VPN-verbindingen. Werkt als een zonnetje!

  • pinockio
  • Registratie: Juli 2001
  • Laatst online: 23-12-2025
Interessant, misschien een goede tip. Zal het geen conflicten vertonen met de OpenVPN server die ik draai op eth0? Daar zit nl. een virtuele ethernetpoort (tun0) bij.

Aan de andere kant... echt ingewikkeld is het niet wat ik wil. Dat moet toch te doen zijn!

Disclaimer: P. aanvaardt geen aansprakelijkheid op grond van dit bericht.

Pagina: 1