LAN 2 LAN VPN met gelijke LAN's

[renevanh]

Een kennis kwam met een vraag op me af waar ik zelf niet direct een goed antwoord op had.

Het betreft een school die gebruik maakt van een leerlingvolgsysteem (Magister van SchoolMaster). Binnenkort wordt dit geheel webbased en komt de dataserver bij SchoolMaster te staan. Deze staat nu namelijk gewoon intern.
Om gebruikers en wachtwoorden te synchroniseren met er dan een verbinding bestaan tussen onze AD en de dataserver bij SchoolMaster. Een LAN 2 LAN VPN is een prima oplossing.

Wat blijkt echter: zowel de school als SchoolMaster gebruiken 192.168.1.0/24 voor de lokale adressen. Een hele maffe keus als je een systeem implementeert waarbij je voor al je klanten constante LAN 2 LAN VPN's gaat opzetten, maar blijkbaar is er niet heel lang over nagedacht.
SchoolMaster ziet hier problemen met betrekking tot de DHCP van de school op hun netwerk bij het bestaan van de VPN verbinding en toegang tot elkaars netwerken. Hun oplossing: de school moet even de boel aanpassen naar 192.168.5.0/24 of zo. Grapjassen...
"Even" aanpassen is er natuurlijk niet bij wanneer je mailservers, firewalls, VoIP, DNS, webservers, virtualisatiehosts, switches, enz hebt draaien, dat gaat je zo een halve dag kosten, inclusief onacceptabele downtime van het netwerk.
Ik zeg: laat SchoolMaster de boel lekker zelf aanpassen... maar dat leek geen levensvatbare optie...

Nou lijkt het mij dat hier ongetwijfeld in een grijs verleden al een oplossing voor bedacht is. Ik ben echter helemaal niet goed thuis in VPN's. Ik weet wat het is en wat het doet, hoe ik ermee moet verbinden... maar daar houd het wel een beetje op.
Volgens mij is een VPN verbinding een virtuele netwerkadapter en kan een apart IP in een aparte range krijgen, moet het toch mogelijk zijn een VPN te isoleren van de rest van je netwerk en dmv tunneling of iets in die richting en moet dit dus op te lossen zijn zonder ingrijpende operaties als veranderen van IP range.

Wie o wie kan mij een zetje in de goede richting geven?

Overigens is dit geen klus die ik aangenomen heb of iets dergelijks, het gaat puur om het meedenken met een kennis en gezien het hoge leergehalte wil ik dat absoluut doen.

[nielsl]

inderdaad niet handig geregeld, overigens niet van beide partijen, maar dat terzijde. Kun je in het netwerk geen route met subnet van /32 aanmaken als je weet op welke IP adres je bij de tegenpartij moet zijn. Als je dan vervolgens dit adres van de tegenpartij niet gebruikt in je interne netwerk, kun je in ieder geval vertellen dat je voor bijvoorbeeld 192.168.1.x/255.255.255.255 in een ander segment van het netwerk moet zijn?

[jant]

Nou lijkt het mij dat hier ongetwijfeld in een grijs verleden al een oplossing voor bedacht is.

De leverancier geeft je de juiste oplossing: omnummeren.

Denk eens over dit na: "Als je dezelfde subnetten zou kunnen routeren, zou er dan een ip (v4) tekort zijn?"

[Verwijderd]

Misschien is het een optie om een op een NAT te gebruiken.

Bekijk dit eens

[Bloodshot]

Er zijn meerdere mogelijkheden, waaronder NAT, maar de allerbeste blijft toch omnummeren...
En ook scholen kunnen volgens mij op zondag (met aankondiging) wel een halve dag down. Het grote nadeel dan zal liggen in het uurloon van degene die dat moet gaan doen.

[Verwijderd]

Bloodshot schreef op maandag 22 november 2010 @ 21:26:
Er zijn meerdere mogelijkheden, waaronder NAT, maar de allerbeste blijft toch omnummeren...
En ook scholen kunnen volgens mij op zondag (met aankondiging) wel een halve dag down. Het grote nadeel dan zal liggen in het uurloon van degene die dat moet gaan doen.

Omnummeren is natuurlijk altijd het beste en als het om 1 subnetje gaat denk ik ook sneller dan een geavanceerde NAT constructie.

[itarix]

Inderdaad omnummeren, Je kan ook een tweede netwerk kaart in de database server zetten, die dan vervolgens in een appart vpn subnet zetten (hmm kan ook virtueel) en dat dan over sturen...

Maar uiteindelijk zijn dit allemaal lelijke oplossingen voor een mooi op te lossen probleem

[Rolfie]

Voor beide is het niet echt slim om in die IP range te zitten. Zelf voor me prive kies ik andere subnets. Zelfs al ik bij iemand prive een thuis netwerk moet aan leggen. Meteen aanpassen naar ene niet 192.168.1.0/24 range.
Maar dat lost je probleem nu niet echt op.

Ik zou toch aan om je eigen om nummeren. Aangezien het gaat om de 192.168.1.0/24 iprange, dus het zijn niet heel veel apparaten. Vanuit gaande dat alles op naam resolutie gaan en niet op IP basis, moet het toch wel vrij gemakkelijk te doen zijn. En zoals je aangeeft gaat dit niet even 123 overdag, dus een avond, of een weekend? In de IT is het heel normaal dat we dit soort dingen in het weekend doen.

NAT zou ik niet snel gaan gebruiken in dit soort acties. Kost je veel meer werk, maakt het onnodig complex.

Dus een weekendje plannen en omnummeren.

[DJSmiley]

Omnummeren idd... wat als je in de toekomst usertjes ook wil laten vpn-nen? Dan mag je bij 80% van de gebruikers ook even hun thuisnetwerk omnummeren?

Nu niet omnummeren is uitstel van het probleem, en geen oplossing imho.

[renevanh]

Dat wordt een pittige omnummerdag dus als ik het zo lees.
Dat wordt absoluut spannend met bepaalde stukjes software die gedraaid worden en die niet zo houden van andere admin wachtwoorden of andere IP's...

Het meeste aangaande de clients gaat inderdaad DNS based, dat zal het probleem niet zijn.

Stiekem had ik natuurlijk gehoopt op een geniale oplossing...

[jvanhambelgium]

Zet de 2 segmenten in "bridging" over de LAN2LAN VPN en hoop dat op beide sites nu net niet dezelfde IP's in gebruik zijn ;-)

...effe serieus...mijn keuze zou zijn -> omnummeren.NAT kan je eventueel als overgangsmaatregel gebruiken...

[Isdatzo]

Is dat niet een heel mooie reden om uit te kijken naar een ander pakket dan "schoolmaster"? Lekker handig gedaan, ik zou 't wel weten :W .

[jvanhambelgium]

DJSmiley schreef op dinsdag 23 november 2010 @ 00:00:
Omnummeren idd... wat als je in de toekomst usertjes ook wil laten vpn-nen? Dan mag je bij 80% van de gebruikers ook even hun thuisnetwerk omnummeren?

Voor "client" VPN's moet JIJ altijd de IP's bepalen die je aan de peer geeft. Je voorziet dus een ip-pool (vb een /24) en elke binnenkomende VPN users krijgt hier 1 adresje van. Als er aan de andere kant een heel LAN hangt moeten ze dat maar "aan hun kant" oplossen.

Met een echte LAN2LAN tunnel is het inderdaad lastiger en is de kans groter op "botsingen" als iedereen RFC1918 ip-space gebruikt (RFC1918 beschrijft de verschillende ranges die vastgesteld zijn om privaat te gebruiken en dat rfc 1918 niet over het publieke internet geroute is etc)

[CherandarGuard]

Isdatzo schreef op dinsdag 23 november 2010 @ 08:33:
Is dat niet een heel mooie reden om uit te kijken naar een ander pakket dan "schoolmaster"? Lekker handig gedaan, ik zou 't wel weten :W .

Schoolmaster is de uitgever, het pakket heet Magister.
Het probleem is overigens dat er niet echt concurrentie is. Er zijn een aantal andere pakketten, maar geen een komt ook maar in de buurt van de functionaliteit en vooral gebruikersvriendelijkheid van Magister.

Helaas betekent dat niet automatisch dat Magister ook beheerdersvriendelijk is. Wij gebruiken het ook en zijn al een tijd geleden overgegaan naar de verplichte externe hosting. Aangezien wij geen LDAP-authenticatie gebruiken vanuit Magister hebben wij dit VPN probleem niet (hoewel we dat überhaupt niet zouden hebben, wij gebruiken een aantal subnets in de 10.x.x.x range).

Ik vrees toch inderdaad dat als je dit op wilt lossen, je óf Schoolmaster tot actie aan zult moeten zetten, óf zelf aan de slag zal moeten. Je kennis zal allicht ook wel kunnen gokken welke van de twee opties het meest waarschijnlijk is.

[Robinski]

Komt er zo straks niet een soort van extreem groot LAN tussen alle scholen welke aangesloten zijn via de LAN2LAN VPNs.

Dan moet dus elke school in Nederland (welke dit gebruikt) een ander subnet.
Erg onpraktisch als je het mij vraagt.

[CherandarGuard]

Robinski schreef op dinsdag 23 november 2010 @ 13:26:
Komt er zo straks niet een soort van extreem groot LAN tussen alle scholen welke aangesloten zijn via de LAN2LAN VPNs.

Dan moet dus elke school in Nederland (welke dit gebruikt) een ander subnet.
Erg onpraktisch als je het mij vraagt.

Goed punt, routeren zal bij Schoolmaster best lastig worden met al die L2L VPNs. Host-to-LAN per server zou dan logischer zijn, maar dan hoef je als school niet meer om te nummeren. Aangezien Schoolmaster aangeeft dat dat nu wel nodig is, zal dit dus wel niet hun oplossing zijn..
Ben benieuwd hoe ze dit dan wel willen laten werken ja.

[Verwijderd]

Ik weet niet welke firewall je hebt staan maar is een loopback interface met MIPS geen oplossing? Niet echt elegant maar pak eenvoudiger dan je volledig subnet omgooien.

[PerfectPC]

Omnummeren??? waar heeft iedereen die dit voorstelt gezeten de afgelopen 15 jaar? in een grot?

1-to-1 NAT is meer dan een tijdelijke oplossing en wordt in bijna elke multinational gebruikt waar ooit een acquisitie heeft plaatsgevonden.
Gewoon je site-to-site VPN opzetten en aan beide kanten NAT-en naar een door jou ongebruikt segment dat even groot is als de andere kant. Klaar op 5 minuten

Omnummeren... goed zot ja...

[Razwer]

PerfectPC schreef op dinsdag 23 november 2010 @ 17:36:
Omnummeren??? waar heeft iedereen die dit voorstelt gezeten de afgelopen 15 jaar? in een grot?

1-to-1 NAT is meer dan een tijdelijke oplossing en wordt in bijna elke multinational gebruikt waar ooit een acquisitie heeft plaatsgevonden.
Gewoon je site-to-site VPN opzetten en aan beide kanten NAT-en naar een door jou ongebruikt segment dat even groot is als de andere kant. Klaar op 5 minuten

Omnummeren... goed zot ja...

juist. niets aan toe te voegen...

[jvanhambelgium]

Razwer schreef op dinsdag 23 november 2010 @ 18:31:
[...]

juist. niets aan toe te voegen...

Als de resources er niet zijn om hernummering te doen EN de applicatie laat zich in alle aspecten goed NAT'ten (in dit geval is het MS Silverlight, ports 943, 4502-4534 udp/tcp dus doenbaar) zou ik het wel overwegen.
Het bedrijf heet Microsoft, afgekort met MS. Zeikerige afkortingen met een $ teken laat je maar achterwege

[ Voor 13% gewijzigd door Equator op 25-11-2010 10:20 ]

[SteeringWheel]

Sowieso is het hier de vraag of je persé de netwerken hoeft te koppelen. Aangezien het gaat om
- een extern gehoste website
- synchronisatie van gebruikers en wachtwoorden
Maar hier is de OP niet erg duidelijk over.
Als het besluit om beide netwerken te koppelen al genomen is, dan lekker NAT gebruiken.

[ Voor 5% gewijzigd door SteeringWheel op 23-11-2010 19:46 ]

[Bloodshot]

PerfectPC schreef op dinsdag 23 november 2010 @ 17:36:
Omnummeren??? waar heeft iedereen die dit voorstelt gezeten de afgelopen 15 jaar? in een grot?

1-to-1 NAT is meer dan een tijdelijke oplossing en wordt in bijna elke multinational gebruikt waar ooit een acquisitie heeft plaatsgevonden.
Gewoon je site-to-site VPN opzetten en aan beide kanten NAT-en naar een door jou ongebruikt segment dat even groot is als de andere kant. Klaar op 5 minuten

Je bedoelt: Waarom willens en wetens een eenmalige aktie uitvoeren waardoor het beheer eenvoudig blijft als je ook een complexere oplossing uit kunt voeren die moeilijker beheerbaar is?

En bij grote multinationals wordt 1-op-1 NAT slechts gebruik op die gebieden waar het *echt* niet anders kan en als het enigszins mogelijk is, wordt het IP-plan alsnog aangepast en segmenten omgenummerd.

Denk eens niet aan een leuke technische oplossing, denk ook eens aan beheersinspanning en alle gevolgen van dien.

[Dronium]

Je bedoelt: Waarom willens en wetens een eenmalige aktie uitvoeren waardoor het beheer eenvoudig blijft als je ook een complexere oplossing uit kunt voeren die moeilijker beheerbaar is?

Met een goede Firewall is 1-to-1 NAT echt een fluitje van een cent. Daar is niets te vinden wat complex of moeilijk beheersbaar is.
NAT is niet voor niets een acronym van NETWORK Address Translation.

[Rolfie]

PerfectPC schreef op dinsdag 23 november 2010 @ 17:36:
Omnummeren??? waar heeft iedereen die dit voorstelt gezeten de afgelopen 15 jaar? in een grot?

1-to-1 NAT is meer dan een tijdelijke oplossing en wordt in bijna elke multinational gebruikt waar ooit een acquisitie heeft plaatsgevonden.
Gewoon je site-to-site VPN opzetten en aan beide kanten NAT-en naar een door jou ongebruikt segment dat even groot is als de andere kant. Klaar op 5 minuten

Omnummeren... goed zot ja...

Alleen een beetje lullig als de applicatie niet met NAT over weg kan. bv als die gewoon een domain zoekt of zo iets. AD verkeer mag bv al niet over NAT gaat.

NAT is zeker een mogelijkheid, maar het zou een laatste mogelijkheid moeten zijn.Elke multinational zal dit ook zo zoen. NAT alleen als je het moet doen.

[DukeBox]

Het lijkt mij logisher dat de aanbieder (schoolmaster) gewoon andere ip-ranges als VPN aanbiedt en zelf (als dat nodig is) middels nat naar hun eigen ip-range routeerd. Kan me niet voorstellen dat ze hier niet vaker tegenaan (gaan) lopen.

[Bloodshot]

Dronium schreef op dinsdag 23 november 2010 @ 20:08:
Met een goede Firewall is 1-to-1 NAT echt een fluitje van een cent. Daar is niets te vinden wat complex of moeilijk beheersbaar is.
NAT is niet voor niets een acronym van NETWORK Address Translation.

Het *configureren* is ook niet moeilijk, maar zoals al eerder door anderen aangegeven zijn er applicaties die er niet tegen kunnen om geNAT te worden (denk: FTP en dan specifiek de variant met encryptie). Daardoor wordt het *beheer* moeilijker.

Denk ook aan mensen die de helpdesk bellen en (*shudder*) een IP-adres moeten pingen / opgeven. om te zien of het Lan-to-LAN VPN in orde is.

[tERRiON]

Als ik dit zo lees dan lijkt het erop dat zij volledige toegang tot je LAN willen hebben. Dan schiet mij eigenlijk maar één vraag te binnen waar ik alleen Robinski min of meer wat over hoor zeggen: Zou je überhaubt wel willen dat zij volledige toegang tot je netwerk hebben!?

Bij mij zouden ze het niet voor elkaar krijgen. Dan verbouwen ze het pakket maar of zorgen ze voor een betere oplossing.

En welke communicatie vliegt er eigenlijk exact over de lijn? Ik lees iets over LDAP? Volgens mij volsta je hier ook door de server van school een VPN-verbinding op te laten zetten en laat Magister dan maar lekker met het verkregen IP-adres kletsen. De overige poortjes gooi je dicht en je bent een aardig eindje op weg.

[Razwer]

Bloodshot schreef op dinsdag 23 november 2010 @ 19:46:
[...]
En bij grote multinationals wordt 1-op-1 NAT slechts gebruik op die gebieden waar het *echt* niet anders kan en als het enigszins mogelijk is, wordt het IP-plan alsnog aangepast en segmenten omgenummerd.

Wat een ONZIN.
De grote toko's in de wereld waar bij er (branch offices) links worden gelegd naar partners en/of klanten is de kans zo ontzettend groot dat er IP conflicten ontstaan dat er JUIST word ge-NAT. Behalve dat komt er firewalls, IPS, berg papierwerk en nog wat compliance bij kijken.

Als voorbeeld: Ik heb tot zeer recent bij 's werelds grootste financieel dienstverlener gewerkt (>30K werknemers). ING is klant van deze toko. Hier ligt een pijp tussen dat bedrijf en ING vanaf 2 kantoren naar 2 kantoren van ING.
En zijn er nog honderden klanten (banken) waarmee verbindingen liggen (VPN, B2B, MPLS). Zonder NAT ben je gewoon gigantisch de sjaak. Is gewoon SOP om NAT te doen.

Nu werk ik voor een grote nederlandse software boer. Daar zijn ook veel tunnels naar klanten. Daar NATten we ook gewoon alles.

Denk even na voordat je wat zegt man. kom op.

[ Voor 5% gewijzigd door Razwer op 23-11-2010 23:57 ]

[overhyped]

NAT is inderdaad de weg om te gaan. Ook bij alle klanten waar ik ooit iets vpnerigs gedaan heb nat je met externe partijen. Er is geen vertrouwensband tussen de partijen, dus maak je elkaars netwerken niet bekend, klaar

Denk nu over het volgende na: Je nummert jouw netwerk nu om, en daarna outsource je een ander deel van het netwerk. Oeps, die gebruiken ook de .5.x... Ga je dan weer omnummeren? een keer NAT goed inregelen, en klaar is kees.

Ps: als je ip space aan wilt passen, ga dan direct naar ipv6! heb je nooit meer private ip space collisions!

[ Voor 11% gewijzigd door overhyped op 24-11-2010 08:23 . Reden: ipv6 propaganda toegevoegd :) ]

[Bloodshot]

Razwer schreef op dinsdag 23 november 2010 @ 23:55:
[...]

Wat een ONZIN.
De grote toko's in de wereld waar bij er (branch offices) links worden gelegd naar partners en/of klanten is de kans zo ontzettend groot dat er IP conflicten ontstaan dat er JUIST word ge-NAT. Behalve dat komt er firewalls, IPS, berg papierwerk en nog wat compliance bij kijken.

Als voorbeeld: Ik heb tot zeer recent bij 's werelds grootste financieel dienstverlener gewerkt (>30K werknemers). ING is klant van deze toko. Hier ligt een pijp tussen dat bedrijf en ING vanaf 2 kantoren naar 2 kantoren van ING.
En zijn er nog honderden klanten (banken) waarmee verbindingen liggen (VPN, B2B, MPLS). Zonder NAT ben je gewoon gigantisch de sjaak. Is gewoon SOP om NAT te doen.

Nu werk ik voor een grote nederlandse software boer. Daar zijn ook veel tunnels naar klanten. Daar NATten we ook gewoon alles.

Denk even na voordat je wat zegt man. kom op.

Aangezien ik bij een internationaal bedrijf in de financiele sector werk, ben ik niet geheel zonder kennis op dit vlak. Ik zou het verder op prijs stellen dat je jouw taalgebruik daarom netjes houdt. NAT wordt zeker gebruikt, maar dan op koppelingen tussen RIPE-adressen en RFC1918-adressen. En bij voorkeur zo min mogelijk tussen RFC1918-netwerksegmenten onderling om precies die redenen die ik en anderen omschreven.

Voor het geval het je niet duidelijk genoeg was: Het betreft hier een SCHOOL met vermoedelijk slechts 50...100 machines (max 250), geen multinational. Wees dan zo flexibel om de oplossing aan te passen aan de gebruikersbehoefte (vermoedelijk max 2 ICT-er die het er mogelijk nog bij doen ook, want alles moet goedkoop in plaats van departments van honderden netwerkers over meerdere landen verspreid).

Zoals ik in mijn eerste post al aangaf: NAT kan, maar aanpassen van de adressen is denk ik in dit geval de beste optie.

@Overhyped: Wij doen zaken met externe partijen op basis van RIPE-adressen, zodat we intern zo veel kunnen NATten als we zelf willen, maar extern nooit IP-adres-conflicten kunnen krijgen. Een school beschikt echter bijna nooit over een /22 aan RIPE-adressen, simpelweg omdat dit duur en onnodig is.

[ Voor 7% gewijzigd door Bloodshot op 24-11-2010 10:44 ]

[axis]

NAT kan, maar is lastiger te beheren, tranparantie is wel zo fijn. Inderdaad lekker op zondag alles omnummeren naar een 10.<random>.<random>.0/24 subnetje lokaal. En ja, je zult later nog gezeik tegenkomen dat je services vergeten bent aan te passen, maar dat is dan maar zo. Bij NAT is het middel erger dan de kwaal denk ik in dit geval.

[renevanh]

Omnummeren naar een 10.0.0.0/24 variant is geen strak plan, daar draait het leerlingennetwerk op (is gescheiden van het administratienetwerk), maar ik snap het punt (het zou dan eerder 192.168.5.0/24 worden).

Schoolmaster is op het moment gruwelijk onduidelijk. De ene medewerker zegt dat het wel via NAT kan, de andere roept weer van niet... Onze firewalls zijn overigens allemaal Smoothwall op dedicated kastjes.

Het probleem met NAT is inderdaad de LDAP synchronisatie... dat kan lastig worden en moet wat mij betreft nog even uitgezocht worden. Het gaat dus inderdaad om LDAP synchronisatie van users en wachtwoorden, met namen voor medewerkers (cijfers invoeren etc).

De vragen met Schoolmaster die toegang krijgt tot ons netwerk zit ik ook mee, dat moet wat mij betreft ook nog even bekeken worden.

De school is op dit moment al begonnen aan voorbereidingen om om te nummeren naar 192.168.5.0/24 (staat al voor donderdagavond op de planning), maar als NAT toch mogelijk blijkt zou dat uiteindelijk toch mijn persoonlijke voorkeur hebben. Tenslotte: Schoolmaster levert een product (Magister), dat moet opeens allemaal externe en webbased... dan zorgen zij maar dat het werkt! Er wordt zat voor betaald...
Maarja, dat is mijn mening...

[overhyped]

Bloodshot schreef op woensdag 24 november 2010 @ 10:42:
[...]


@Overhyped: Wij doen zaken met externe partijen op basis van RIPE-adressen, zodat we intern zo veel kunnen NATten als we zelf willen, maar extern nooit IP-adres-conflicten kunnen krijgen. Een school beschikt echter bijna nooit over een /22 aan RIPE-adressen, simpelweg omdat dit duur en onnodig is.

Ik (ook werkzaam in de financiele sector momenteel) probeer extern ook zo veel mogelijk te communiceren op basis van publieke adressen. (en dan nog meestal via bastion hosts etc.) dit is inderdaad overkill voor een school als dit. Zelf de kennis opbouwen ook, maar het interne netwerk helemaal omgooien voor een leverancier? Nee, dat kan ik toch geen goede oplossing vinden.

huur een half dagje een cisco specialist in, en het draait. Nog een paar uurtjes voor een stuk goede documentatie en klaar. Je hoeft zo iets niet zelf 100% te snappen als kleine club, daar heb je ingehuurde specialisten voor.

[axis]

renevanh schreef op woensdag 24 november 2010 @ 12:54:
Omnummeren naar een 10.0.0.0/24 variant is geen strak plan, daar draait het leerlingennetwerk op (is gescheiden van het administratienetwerk), maar ik snap het punt (het zou dan eerder 192.168.5.0/24 worden).

Als je omnummert naar 192.168.x.0/24 heb je 1/256e kans op conflicten mocht je in de toekomst aan een andere 192.168.x.0/24 wilt knopen. Als je omnummert naar een 10.x.y.0/24 heb je 1/65536e kans op conflicten.

Het leerlingennetwerk op 10.0.0.0/24 draaien is ook niet echt slim. Van alle 65536 mogelijkheden voor 10.x.y.0/24 netwerken is de meestgebruikte gekozen.. Is ook wachten op een conflict.

[Bloodshot]

@Overhyped: Volledig mee eens. Een perfecte oplossing bestaat in dit geval niet, een redelijke oplossing wel, en dat is 1 van beide (NAT / omnummeren) met allebei hun voordelen en nadelen. Of de school cisco heeft draaien, weet ik niet.

@Axis: Als je een 192.168.1/2/3/4/5/123/254 hebt draaien, heb je denk ik de helft van alle netwerken te pakken. 192.168.65.0/24 is denk ik percentueel gezien zeer zelden in gebruik. Voor 10-reeksen zijn de polulaire netwerken 10.0.0.0/24, 10.10.10.0/24 en 10.1.1.0/24 goed voor een behoorlijk aandeel. 10.243.132.0/24 dan weer een stuk minder.

[overhyped]

Bloodshot schreef op woensdag 24 november 2010 @ 14:27:
@Overhyped: Volledig mee eens. Een perfecte oplossing bestaat in dit geval niet, een redelijke oplossing wel, en dat is 1 van beide (NAT / omnummeren) met allebei hun voordelen en nadelen. Of de school cisco heeft draaien, weet ik niet.

Vervang cisco door een willekeurige andere specialist inderdaad Beroeps deformatie denk ik!

[Razwer]

Bloodshot schreef op woensdag 24 november 2010 @ 10:42:
Aangezien ik bij een internationaal bedrijf in de financiele sector werk, ben ik niet geheel zonder kennis op dit vlak. Ik zou het verder op prijs stellen dat je jouw taalgebruik daarom netjes houdt.

Aanstellen is ook een vak waar je blijkbaar ook zeer bedreven in bent. Mijn taalgebruik is prima in orde. Het is vast niet fijn als iemand je ongelijk probeert te bewijzen maar daarom hoef je niet te jokken en te suggereren dat iemand onheus taalgebruik voert.

anyways back on topic

Voor het geval het je niet duidelijk genoeg was: Het betreft hier een SCHOOL met vermoedelijk slechts 50...100 machines (max 250), geen multinational. Wees dan zo flexibel om de oplossing aan te passen aan de gebruikersbehoefte (vermoedelijk max 2 ICT-er die het er mogelijk nog bij doen ook, want alles moet goedkoop in plaats van departments van honderden netwerkers over meerdere landen verspreid).

Zoals ik in mijn eerste post al aangaf: NAT kan, maar aanpassen van de adressen is denk ik in dit geval de beste optie.

Wel knap dat je met suggeren al kan besluiten wat de beste optie is. Omnummeren is feitelijk gewoon altijd een lastig en vervelend project wat altijd downtime veroorzaakt en voor onvoorziene problemen zorgt, bij beheer, danwel bij gebruikers. Of het slim is dat de TS uberhaupt ooit die range gekozen heeft (of zijn voorgangers) is een andere vraag.
Je hele toko omnummeren omdat een leverancier iets aanlevert wat niet past is en blijft in mijn ogen gewoon not done en is in veel gevallen ook gewoon niet nodig. Standaard policy hoort in mijn ogen te zijn NAT tenzij het niet kan.

Overhyped weet tenminste waar hij het over heeft. Je suggereerd ontzettend veel en hebt teveel aannames (lees je eigen posts eens zorgvuldig na). Zo komt het over alsof je een god complex hebt en dat wekt iritaties op.

[ Voor 5% gewijzigd door Razwer op 24-11-2010 18:48 ]

[Equator]

Modbreak:

Heren,
Een discussie over dit onderwerp is prima, maar laten we elkaar wel normaal aan blijven spreken

---

Mijn toevoeging:

Waar je naar moet kijken is gewenste situatie. Een VPN naar een klant, welke alleen gebruikt wordt om remote support aan te kunnen bieden, is een situatie waarbij ik altijd voor een NAT oplossing zou kiezen.

Voor een permanente situatie zou ik kiezen voor een transparante oplossing. Dus omnummeren.
ALs een bedrijf goed heeft nagedacht over de toekomst, sizing en verwachtingen, dan hebben ze ook niet een al te grote IP space genomen. Dat maakt het gemakkelijker om later te wijzigen.

[Paul]

Bloodshot schreef op dinsdag 23 november 2010 @ 20:40:
Het *configureren* is ook niet moeilijk, maar zoals al eerder door anderen aangegeven zijn er applicaties die er niet tegen kunnen om geNAT te worden (denk: FTP en dan specifiek de variant met encryptie). Daardoor wordt het *beheer* moeilijker.

Heb je het niet over NAPT ipv DNAT/SNAT waar we het hier over hebben?

[Bloodshot]

@Paul Nieuwkamp: Bij bepaalde FTP-oplossingen komt de data-socket langs in de cmd-sessie. Slimme nattende devices (meestal firewalls), die zien dit, en natten die socket gewoon mee. Dit kan echter niet als de cmd-sessie end-to-end ge-encrypt wordt. Er zijn ook andere applicaties die niet tegen NAT kunnen, meestal vanwege encryptie.

[DukeBox]

@Bloodshot, jij gaat er dan vanuit dat je devices over 1 ip NAT.. je kan natuurlijk ook een hele range 1op1 natten. Dat wordt al snel gedaan in dit soort situaties, je hebt dan geen last van poorten en encryptie.
Daarnaast heeft het ook als voordeel dat je dingen als DNS rewrite kan doen zodat partijen niet van elkaar afhankelijk zijn qua achterliggende infra.

Ik heb diverse malen een trukendoos moeten opentrekken om dit soort dingen op te lossen.. als je eenmaal een goede (standaard !!!) oplossing hebt kan je deze altijd inzetten bij mogelijke toekomstige problemen.

Als je gaat omnummeren, neem een subnet van de 172.16.0.0/12 range, deze is flink minder in gebruik dan de 10.0.0.0/8 en 192.168.0.0/16.

[ Voor 32% gewijzigd door DukeBox op 25-11-2010 13:23 ]

[Bloodshot]

DukeBox schreef op donderdag 25 november 2010 @ 13:15:
@Bloodshot, jij gaat er dan vanuit dat je devices over 1 ip NAT..

Nee hoor, dit is niet alleen bij NAPT of NAT-overload, maar ook bij 1-op-1 NAT.

Ik pak als voorbeeld wederom FTP. Dit staat ook bekend als het dubbele firewall-dillema. Voor wat achtergrond-informatie, zie: http://www.isaserver.org/...es_Firewall_Security.html

@Razwer: Leer lezen en probeer volwassen te reageren/discussieren. Als dat niet lukt, reageer dan gewoon niet.

[ Voor 3% gewijzigd door Bloodshot op 25-11-2010 14:48 ]

[DukeBox]

Met 1op1 nat werkt active ftp zonder problemen.

[Bloodshot]

DukeBox schreef op donderdag 25 november 2010 @ 14:58:
Met 1op1 nat werkt active ftp zonder problemen.

Precies! Er zijn echter nog meer soorten FTP.
Secure FTP loopt echter nog wel eens tegen problemen aan.

[DukeBox]

Want ? SFTP is juist nog makkelijker mits je op basis van dns werkt (ip is hoe dan ook nooit verstandig want daar kan je te makkelijk met public keys rommelen), daar worden geen poorten dynamisch toegekent middels terugmelding. Het voordeel van 1op1 is dat de NAT/PAT router alleen maar send en recieve ip hoeft aan te passen.

[Razwer]

DukeBox schreef op donderdag 25 november 2010 @ 16:47:
Want ? SFTP is juist nog makkelijker mits je op basis van dns werkt (ip is hoe dan ook nooit verstandig want daar kan je te makkelijk met public keys rommelen), daar worden geen poorten dynamisch toegekent middels terugmelding. Het voordeel van 1op1 is dat de NAT/PAT router alleen maar send en recieve ip hoeft aan te passen.

SFTP =/= FTPS
SFTP == SSH
FTPS == FTP over SSL (/TLS)

FTPS is sneller dan SFTP al is over het algemeen SFTP wel meer secure en kun je er meer truukendozen mee.

SFTP is geen probleem over NAT
FTPS daarintegen is vaker hoofdpijn over NAT.

Ik heb voor mijn vorige werkgever een secure FTP site moeten opzetten waarbij de keuze viel op SFTP vanwege de problemen die we hadden met NAT en als bonus de extra opties die SSH met zich mee brengen.

Gezien FTP achterhaald is (tenzij je anonymous FTP wilt draaien) moet je een van de opties kiezen waarbij je dus de afweging moet maken tussen "snel(ler)" en NAT hoofdpijn (FTPS) of meer secure maar traag/hogere CPU load (SFTP)

Blijkbaar kan Bloodshot ook geen modbreaks lezen

[Verwijderd]

Is het niet mogeljik een aparte range achter een aparte firewall te plaatsen?

- Dus 1 extra extern IP-adres (is dat mogelijk bij de school?)
- VPN-router dat IP-adres op laten pakken, VPN-router nieuw subnet aanleggen
- Netwerk achter die router opbouwen met machines die dubbel uitgevoerd zijn met netwerkkaarten

Voordeel: Bestaand netwerk hoeft niet omgenummer te worden

[UnicronNL]

Je kan de vpn verbinding (virtuele adapter) idd een ander ipnummer (ander subnet) geven als je aangaf in je post,
daarna kan je bij je netwerkadapter er gewoon een ip-address bij zetten (zelfde subnet als je bij je vpn verbinding gaat gebruiken (1 adapter meerdere ip-addressen))

ik weet niet wat voor vpn het is, maar als het om een tcp/ip only vpn gaat hoeft de andere partij zich geen zorgen te maken over dhcp ed. broadcasts.

[ Voor 4% gewijzigd door UnicronNL op 26-11-2010 19:39 ]

[Guru Evi]

1-op-1 nat van het kleinste netwerk naar een andere (publieke) range. Aangezien het 1-op-1 is heb je geen problemen met protocollen zoals je bij thuisnetwerken gewoon bent. Alternatief omnummeren naar een public range.

[ViperXL]

Ik denk dat het nu wel duidelijk is.

Heb je <50 IP's? Omnummeren
Heb je er meer, met uitkijk op uitbreiding en beheer, zou ik gewoon gaan voor NAT.
Tegenwoordig zijn er genoeg firewalls die doormiddel van application filtering e.d. het prima doen met NAT en eventuel maak je een andere DMZ met backlink naar je netwerk voor services die het niet goed zouden doen op je netwerk.

Ik vraag me af hoe groot het schoolnetwerk is qua devices/IP's en subnets (dacht maar 1).
Zou wel helpen als we wisten hoe de WAN en LAN kant eruit zag ongeveer.