[iprouting] Proxy ARP of andere oplossing ?

Pagina: 1
Acties:

  • twiekert
  • Registratie: Februari 2001
  • Laatst online: 28-04 13:56
ik zit hier met een routing probleem en ik heb het idee dat ik veel te moeilijk doe.

de situatie is als volgt, we hebben hier een straalverbinding met een internet provider en daaraan zit een /24 range geknoopt.

nu hebben we een aantal adressen daarvan ingebruik, maar niet allemaal want de range is niet volledig van ons, er zitten n.l. nog meer mensen op deze multipoint straalpaal.

de volgende adressen hebben wij tot onze beschikking, 213.x.x.8, .9, .12,.14 en .16 t/m .31 :)

we hebben vervolgens deze verbinding op onze cisco switch zitten waarop 2 VLAN's geconfigureerd zijn, een voor de internetadressen en een voor het lokale netwerk.

Nu zijn we echter van plan om de .16 t/m .31 range te gebruiken voor onze werkstations en enkele adressen door te sturen via een accesspoint die beiden op VLAN2 zitten.

we willen hiertussen wel een firewall plaatsen en de mogelijkheid hebben om met iproute+tc o.a. de bandbreedte te beheersen. :)

Na wat gezocht te hebben op internet leek mij dat een proxy-arp / pseudo bridge de oplossing hiervoor is.

dus slackware doos in elkaar gegooid, 2.4.18 kernel erop en proxy_arp aanzetten.

situatieschets:
code:
1
2
3
4
5
6
7
8
9
10
11
  cisco switch
----------------------------------
| [vlan1 ]  [    vlan2     ] |
| [ ]   [         ] |
----------------------------------
  |  |  |              |
  |  |  |     |---------|     |
  |  |  |eth0-|proxy-arp|-eth1|
  |  |    |_________| 
  |  |
  2 servers (adressen .8, .9 en .14)

op vlan1 komen deze adressen binnen. vervolgens willen we de range 213.x.x.17 t/m 213.x.x.30 met netwerkadres 213.x.x.16 en netmask 255.255.255.240 (/28 dus) op vlan2 krijgen.

tot zover gaat het goed. aan eth1 kunnen we mooi de 213.x.x.16/28 hangen. vervolgens moeten we wel tegen eth0 vertellen welke adressen er allemaal aan vlan 1 zitten. en hoe de resterende gerouteerd moeten worden.

nu kunnen we wel de 213.x.x.0/24 range aan eth0 zetten maar dat is volgens mij niet zo'n goed plan want deze zijn namelijk niet allemaal van ons. het is dus mogelijk om adressen te nemen die niet voor ons bedoeld zijn.

nou vraag ik me af of wat ik nu op papier heb staan wel helemaal goed is. het is namelijk niet de bedoeling dat we adressen in gaan nemen die voor andere klanten bedoeld zijn.

ik ben ook maar linux newbie :)

proxy arp is trouwens maar een van de mogelijkheden die ik tegengekomen ben. zijn er ook nog andere oplossingen voor het routeren van deze adressen?

/edit
fout subnet

  • RedRose
  • Registratie: Juni 2001
  • Niet online

RedRose

Icebear

Even een vraagje tussendoor: moet je al die IP-adressen gebruiken? Want ik zou denk ik zelf 1 extern IP-adres kiezen op eth1 van een firewall (bijvoorbeeld: 213.x.x.8 / 255.255.255.255) en dan een RFC-private network (e.g. 192.168.x.x/24 of 172.16.x.x/24) (via eth0 op je firewall) creeren voor de servers en clients.

Dan kan je op een Linux firewall de interne adressen mooi masqueraden naar de externe en heb je een hele zooi /24 adressen die je kan gebruiken voor je LAN. En dan hoef je je servers ook niet aan een publiek subnet te hangen, om maar iets te noemen.

/edit: ff wat verduidelijkt hoop ik :)

Sundown Circus


  • mavink
  • Registratie: April 2000
  • Laatst online: 24-11-2025
Ik zit even te denken, maar ik denk dat het het handigste is om de linux-machine als bridge te gebruiken tussen de twee VLAN's. De bridge zorgt dat je de PC's in het tweede VLAN gewoon kunt blijven gebruiken alsof ze direct in het eerste VLAN zaten (dat is de hele functie van een bridge); maar met linux kan je daarbovenop nog een firewall zetten die controleert wat tussen de twee netwerksegmenten doorgestuurd mag worden. Een soort "transparante firewall" dus, waarvan niemand merkt dat hij er tussen zit.

Meer info: http://www.tldp.org/HOWTO/mini/Bridge+Firewall+DSL.html

  • twiekert
  • Registratie: Februari 2001
  • Laatst online: 28-04 13:56
ik heb het nu voor elkaar. ik heb voor elk ip adres wat we hebben een aparte route toegevoegd. dit werkt OK, maar is nog niet perfect. :)

we hebben dit systeem juist gemaakt om van dat masquerading af te zijn, dit is namelijk niet zo flexibel.