Caching DHCP

[Paul]

Ik heb (op het werk) een SDSL-lijn waarop wat servers gehost gaan worden van klanten.

Daarbij hebben we geen vaste IP-adressen maar adressen die door een DHCP-server van de provider worden uitgegeven. Deze zijn vast te zetten door het mac-adres door te geven.

Probleem is echter dat we tegen de klant willen zeggen: zet de server maar op DHCP, $dit wordt je IP. Wij weten dus echter helemaal niets van die server, geen mac of niks. En daar zit ik nu dus mijn hoofd over te breken

Zelf kwam ik al op een bridge die aan de ene kant een DHCP-server heeft draaien en aan de andere kant een dhcp-client. Je schijft de dhcp-client-identifier mee te kunnen geven, maar ik ben er niet helemaal uit of dit dus het "mac"-adres is dat je aan de provider door moet geven, maar als dat werkt kunnen we iig op voorhand al meer dan een adres krijgen.

Dit adres stop je dan aan de andere kant in je DHCP-server zodat deze dat adres weer uit kan geven.
Dan heb je echter wel op je bridge een interface die hetzelfde ip heeft als een ander device op die bridge?

Denk ik te moeilijk en kan het veel simpeler?
Zit ik ongeveer goed en kom ik zo al een heel eind?
Denk ik niet moeilijk genoeg maar is het praktisch wel haalbaar?
Of is de wens van mijn werkgever gewoon bijna niet te realiseren?

Ik heb hier vrijdag maar snel het een en ander over gehoord en weet dus niet hoe hard die eis is (voornaamste item voor mijn werkgever leek het bijhouden van het dataverkeer te zijn maar dat is het simpelste van het verhaal, gewoon met SNMP de switch uitlezen, en is de DHCP + vooraf bekend IP meer een wens. Als het IP niet vooraf bekend hoeft te zijn hoeven we slechts na het inprikken het MAC van de server aan de provider door te geven), dus daar ga ik het morgen (maandag) nog even over hebben, maar ik vond het ook als theoretisch probleem wel leuk om op te pakken

[Paul]

Ik heb het er met mijn werkgever over gehad, en het gaat er niet zozeer om dat we van te voren het IP aan de klant door kunnen geven, maar dat we niet afhankelijk zijn van het MAC-adres van de klant.

Ik ben er nog niet helemaal uit hoe die het verhaal simpeler maakt (DHCP relay/forwarding agent die de client-identifier aanpast of zo?), maar voor het geval er al mensen waren die erover aan het denken waren

[Pim.]

Op verzoek een move

[Verwijderd]

Kan je niet met een service als DynDns werken ?
(of is het verhaal gecompliceerder dan ik denk/lees ?)

[TrailBlazer]

Ik neem aan dat al die toegewezen ip adressen binnen 1 subnet zitten. Dan zal ik me er niet zo heel veel zorgen over maken en gewoon hard een ip adres toekennen uit die reeks. Dat subnet zal wel naar jouw router worden verwezen en dat is het.
Sowieso is het een idiote oplossing die die provider heeft. De klant moet zijn server vervangen en dan of zijn mac adres wijzigen of de provider moet zijn database aanpassen.

[Paul]

Dyndns is geen optie, je gaat geen bedrijfswebsite op macdonalds.no-ip.org of op hema.dyndns.bla zetten. De DNS is het probleem ook niet, geef de provider een MAC (dhcp-client-identifier?) en je blijft tot in de lengte der dagen dat IP houden.

Het is helaas geen subnet, we krijgen echt adressen van DHCP. Op onze andere lijn hebben we wel een subnet gelukkig. Ik heb geen idee wat de beweegredenen van de provider zijn maar inderdaad, als er iets veranderd dan moet een van beide partijen iets aanpassen inderdaad.

Daar willen we dus ook van af. Hoe fabriceer je iets dat je van de provider een "vast" ip krijgt op basis van dat MAC-adres, maar zonder dat je iets veranderd op de dhcp-client, maar dat het MAC-adres dat je aan de DHCP-server stuurt wel (man-in-the-middle) is aan te passen/in te stellen?

Dat mag best in een los kastje, een firewalling-dhcp-mutating-proxy-bridge zijn, want er moet toch nog zoiets komen voor de accounting en traffic (of met name, total bandwidth) shaping.

[Verwijderd]

Gooi een Cisco Pix / Cisco ASA of iets neer. Bouw hiermee op de WAN side meerdere virtuel inferfaces. Laat deze de IP adressen verkrijgen van de provider. Deel hierna static IP's uit aan klant (interne reeks), en forward het verkeer vanaf de router naar het interne IP adres.

Dan kan jij gewoon een vrij extern IP adres opzoeken in je eigen databaseje, en deze doorverwijzen aan de klant. Dus je weet al welke je gaat krijgen, vooraf.

[Paul]

Om dat in huis/tuin/keuken-router-taal te zeggen: NAT met default server?

Tenminste, ik neem dan aan dat ik het adres moet vertalen anders ziet de server allemaal pakketjes met een doeladres waar hij niets mee kan?

[Verwijderd]

een typisch dillemma want een vast IP betekent geen noodzaak meer voor dhcp en zonder vast IP is de enige manier van identificatie het MAC address.

er is nog 1 andere manier van identificatie: netwerk poort. wat je zou kunnen doen is een soort site-to-site VPN interface kunnen maken en die dan weer bridgen/routen. je zou je dhcp server dan binden op deze interface en zodat het eigenlijk net zo werkt als zonder mac-binding maar omdat je een range van bijvoorbeeld 1 IP address per interface opgeeft zal elk DHCP request via die interface een willekeurig IP address krijgen ongeacht MAC address uit de pool van 1 IP address(en). het grote nadeel is dat je dus 1 interface moet hebben per klant en dat je DHCP server op diezelfde bak moet draaien.

ik zou geen andere manier weten om een computer telkens het zelfde IP address te geven zonder het mac-address te gebruiken want hoe wil je DHCP server anders ontdekken wie er om een lease vraagt?

[Brahiewahiewa]

Je kunt natuurlijk een "veilige" MAC range nemen en daar alvast IP-adressen op reserveren bij de provider. En voor je klanten dan een instructie schrijven of een aantal scriptjes bakken die het MAC adres op de interface veranderen; de meeste OS-en ondersteunen dat

[Paul]

Na wederom een verhelderend gesprek met mijn werkgever wil hij dus juist dat de klanten zelf een vast ip instellen Hoefde niet eens een extern (provider-)ip te zijn. Met andere woorden: 1:1 NAt of multi-nat.

Nu nog testen of dat ook echt werkt En dan met name meerdere adressen krijgen via DHCP op dezelfde fysieke netwerkkaart (wat dus wel neer zal komen op het aanmaken van enkele virtuele kaarten)