Intern IP nummer naar de cloud zetten via VPN.

[grimlock]

We zijn voornemens om een server naar "de cloud" te brengen. Hierbij zou het ideaal zijn en vooral veel werk schelen als we het IP nummer van de machine zouden kunnen behouden. DNS naam e.d. is geen oplossing om te voorkomen dat ons veel werk bespaart zou blijven. Het IP nummer is onderdeel van het gangbare subnet dat lokaal gehanteerd wordt. Zijn er technische oplossingen hiervoor?

[Equator]

Ja, dat heet een Layer2 VPN, of een bridge.

Welke cloud ga je naar toe? Want zij moeten je dit kunnen vertellen of ze dergelijke functionaliteit kunnen bieden.

En anders kan je spelen met Veeam Powered Networks. Daarmee kan je een Layer2 VPN maken tussen twee netwerken. Kost je wel een VM op elke locatie.

[ Voor 9% gewijzigd door Equator op 08-01-2019 15:41 ]

[cyberbetica]

Ongeacht of er een (goede/werkbare) oplossing is om jouw server onder een lokaal ip bereikbaar te maken in "de cloud"; bijt even door die zure appel.

Mijn ervaring met 10 jaar migratieprojecten is dat zo'n klusobject met een vast IP adres gedurende het jaar voor meer ellende en incidenten zorgt dan je denkt. Dit is een goed moment om het ding een beetje op te poetsen. Als er problemen mee zijn, kun je altijd "de cloud" de schuld geven

[grimlock]

Ik weet het, de machine biedt veel verschillende noodoplossingen die we niet even wegpoetsen, de hosting loopt en kost bakken vol met geld, als we dan eerst dat IP nummer op alle werkstations moeten elimineren (wat wel wenselijk zou zijn), dan is het meteen een stuk minder leuk om te doen. We gaan het wel regelen dat het zo opgelost wordt, en alles met een keurige DNS naam "server.domain.local".

@Equator Layer2 VPN klinkt interessant, ook die VEEAM oplossing kan ik eens bekijken. Dank je!

Mochten er meer soorten oplossingen mogelijk zijn dan zal God u belonen voor een reply .

[Verwijderd]

Je had al lang kunnen beginnen met zorgen voor DNS en dan stapsgewijs in alle werkstationnetjes dat IPadres voor een DNS-naam te verwisselen. Of je doet zoiets met een centraal beheerswerktuig, of wat dan ook. En dan tegen de tijd dat er een nieuwe server te benaderen is, zet je de DNS timeout terug, wissel je IPadressen, en daarna kun je de timeout weer opkrikken. Qua verdere opties, je kan natuurlijk ook dat IPadres aan een ander apparaat toekennen, waarop je port forward(s) of ("omgekeerde") NAT toepast.

Leg trouwens ook nog even uit hoe zo'n dure-want-gehoste server, dus die kennelijk elders staat, nu al een kennelijk RFC1918-adres heeft? Als het een beetje wil staat er dus al een "oplossing" en kun je die naar een andere dienst laten wijzen.

[Vorkie]

Moet de server zijn IP behouden of moeten de clients naar dat IP adres connecteren?

In het geval van 2, NAT:
Client vraagt IP 192.168.70.6 op, gaat naar de firewall, deze zet IP adres om in 172.16.16.70 en stuurt deze naar de server over VPN.

[grimlock]

Op de werkstations staan b.v. ODBC koppelingen op basis van IP nummer, macro's van eigen fabrikaat, driveletters die aangemaakt zijn op basis van IP nummer. Het is een iSeries van IBM waar mee verbonden wordt. Er is ook clientsoftware dat de schermemulatie doet, maar deze is makkelijker via een policy naar server.domain.local te laten wijzen.

[Will_M]

Hide NAT?

[grimlock]

Verwijderd schreef op dinsdag 8 januari 2019 @ 19:00:
Je had al lang kunnen beginnen met zorgen voor DNS en dan stapsgewijs in alle werkstationnetjes dat IPadres voor een DNS-naam te verwisselen. Of je doet zoiets met een centraal beheerswerktuig, of wat dan ook. En dan tegen de tijd dat er een nieuwe server te benaderen is, zet je de DNS timeout terug, wissel je IPadressen, en daarna kun je de timeout weer opkrikken. Qua verdere opties, je kan natuurlijk ook dat IPadres aan een ander apparaat toekennen, waarop je port forward(s) of ("omgekeerde") NAT toepast.

Leg trouwens ook nog even uit hoe zo'n dure-want-gehoste server, dus die kennelijk elders staat, nu al een kennelijk RFC1918-adres heeft? Als het een beetje wil staat er dus al een "oplossing" en kun je die naar een andere dienst laten wijzen.

Tja, mijn leverancier kwam er op het laatste moment mee dat we het IP nummer niet naar de cloud konden meenemen. Dan krijg je een dergelijk scenario. Ik snap dat ook wel. De server is opgebouwd, VPN gemaakt met onze infrastructuur, en het IP nummer wat gebruikt was, was niet wat we verwacht hadden. Toen kwam de discussie los. Maar die optie van IP nummer op een andere bak zetten en dan forwarden etc klinkt ook heel interessant.

[grimlock]

wimmel_1 schreef op dinsdag 8 januari 2019 @ 21:30:
Hide NAT?

Ook interessant. Ik ga eens kijken of dit op een of andere manier makkelijk toe te passen is. Dank je.

[Verwijderd]

grimlock schreef op dinsdag 8 januari 2019 @ 21:33:
Tja, mijn leverancier kwam er op het laatste moment mee dat we het IP nummer niet naar de cloud konden meenemen.

Als je weet hoe IP subnetting werkt dan weet je dat al vantevoren: Andere locatie, ander IPadres.

Daar is dus DNS voor uitgevonden.* En als netwerker weet je dat, dus geef je diensten DNS-namen en die namen gebruik je in je configuratie. Die indirectie geeft je een centrale plaats om je configuratie aan te passen als er een dienst van IPadres verhuist.

Dan krijg je een dergelijk scenario. Ik snap dat ook wel. De server is opgebouwd, VPN gemaakt met onze infrastructuur, en het IP nummer wat gebruikt was, was niet wat we verwacht hadden. Toen kwam de discussie los.

Dat is eerder een symptoom van niet voldoende organisatie in je netwerk. En dus niet voldoende kennis aanwezig om een voldoende-georganiseerd netwerk bij te houden. Nou weet ik niet wat "de machine biedt veel verschillende noodoplossingen die we niet even wegpoetsen" precies betekent, maar "achterstallig onderhoud" is wellicht een aardige eerste benadering.

Maargoed, je hebt nu dus drie manieren om deze ellende onder het tapijt te vegen: Net doen of je "cloud" onderdeel is van je lokale netwerkje ("layer 2 VPN"), of het verkeer doorsturen met port forwards, of met network address translation. Je doel is nog steeds om DNS te gebruiken om dit soort truuks niet nodig te hebben.

Die drive letters en de ODBC-mappings zijn wellicht met een batchfile danwel een registry key bestandje te importeren. Dus na opzetten en testen, een paar klikken vanaf een shared drive. Hoeveel werkstations gaat het over?

* Niet helemaal: De centrale hosts file bijhouden werd te bewerkelijk. Maar dat is hetzelfde idee.

[laurens0619]

Vpn lijkt mij de beste oplossing. Die ligt er al zo te lezen, dan een static route voor het ip naar je firewall/gateway pushen en daar een nat doen naar het nieuwe adres.

Toch nog een alternatief:

Wat ik in het verleden heb gebruikt als tijdelijke oplossing (bv mail server dns migratie) is rinetd.

Je pakt een server in je lokale netwerk, geeft hem het oude adres van de iSeries en start rinetd op met destination het nieuwe ip en gebruikte poorten. Al het tcp verkeer op iedere portforward dan geforward. Zelfde principe als firewall maar dan moeten de werkstations wel de firewall raken in de route plus het is een simpele executable die je op linux start.

https://www.boutell.com/rinetd/

Als je logging erbij aanzet zie je ook nog welke machines het oude ip gebruiken

[ Voor 16% gewijzigd door laurens0619 op 09-01-2019 19:21 ]

[vso]

@grimlock je vergeet te vertellen hoe je IP omnummering of huidige lan (nieuwe en oude locatie) bestaat.
Ik leg de manager de kosten van alles voor en risico's en hij mag (per mail) kiezen voor de optie .. in elk geval is het antwoord mijn mandaat en verwijs ik iedereen die bezwaar erna heeft naar de manager. ik ben uitvoerend niet verantwoordelijk.


Als je een layer2 link aanlegt kan je gedonder met broadcasts krijgen of diensten die niet echt routeerbaar zijn (oud maar kan)
als

als je op beide locaties het zelfde subnet hebt, ontkom je bijna niet naar een "hack" oplossing of extended vlan. Met hack bedoel ik opties zoals poortforwarding van A naar B

Als je alles intern (lees eigen hand) hebt dan kan je beter een nieuwe server opzetten en per machine/service de boel migreren van de oude naar een nieuwe server en tussentijds de server even uitzetten (zodat je hem weer aan kan zetten) dat er niks stuk gaat (piep systeem)

tegelijkertijd kan je bv kijken hoe je dit netjes oplost(bv op basis van DNS) / documenteert zodat je weet welke afhankelijkheden er zijn..

Geld / slechte planning is een organisatie probleem en of je nu x.y.z als oplossing inzet (tussen oplossing) uiteindelijk als het plat gaat is het meer uitzoek werk om het weer in de lucht te brengen.. oftewel op je vakantie / trouwdag gebeld worden .. dingen die je niet wilt.

ik zou gewoon de server verplaatsen nieuw IP en wat omvalt .. tja gewoon fixen op basis van DNS dat dingen stuk gaan dat is blijkbaar een gecalculeerd risico .. je hebt het toch aangegeven bij de manager als hij het risico accepteert is dat toch geen probleem ?

[ Voor 8% gewijzigd door vso op 09-01-2019 19:31 ]

[grimlock]

Allemaal bedankt. Ik weet redelijkerwijs wat ik kan doen. Er zijn geen issues met deadlines en geld of verantwoording hier of daar. Het is gewoon iets waar we met vooruitschrijdend inzicht tegenaan gelopen zijn en we samen op willen lossen. Daarom steken we de koppen samen om te kijken hoe we dit het efficienste op kunnen lossen.

[Equator]

@grimlock
De Layer2 VPN oplossing kan je prima gebruiken voor een transitie periode. Ik zou later altijd proberen om van een L2 verbinding af te stappen en gewoon op L3 te gaan werken. Maar dat vereist dat je het subnet/VLAN wat je eerst gaat stretchen uiteindelijk opheft.

Wil je blijven werken in een half half, dan raadt ik je aan (net als anderen) om toch een keer door de zure appel te bijten, en de server een ander IP adres te geven.