Op zoek naar NAT-device

[automation]

Beste Allen,

Graag breng ik communicatie tot stand tussen een apparaat met adres 172.30.2.5 en 192.168.10.5. Omdat beide apparaten onderdeel zijn van een groter netwerk, kan en mag ik de adressen niet aanpassen. Daarom wil ik dit oplossen door te NATTEN zoals weergeven in dit overzicht: https://www.uploadarchief.net/files/download/nat.png

Ik weet echter niet of er apparaten zijn die dit kunnen. Kan iemand voorbeelden geven van apparaten die kunnen dienen als het NAT-device in bovengenoemde afbeelding?

[ Voor 6% gewijzigd door automation op 04-12-2017 08:34 ]

[.Maarten]

Zo ongeveer elke router kan dat.

[MAX3400]

Multi-NIC pfSense?

[johnkeates]

Je kan ook gewoon een route maken om dat te doen. Geen NAT, wel verkeer. Dat is zo'n beetje hoe het hele internet werkt.

[automation]

Beste MAX3400, pfSense, dat ga ik eens onderzoeken!

Beste johnkeates, het probleem is daarbij dat ik in beide apparaten dan wel het router (default gateway) adres in moet stellen. Helaas kan/mag ik dit bij een van de apparaten niet doen.

[downtime]

automation schreef op maandag 4 december 2017 @ 08:43:

Beste johnkeates, het probleem is daarbij dat ik in beide apparaten dan wel het router (default gateway) adres in moet stellen. Helaas kan/mag ik dit bij een van de apparaten niet doen.

Ik zie eigenlijk niet waarom je uberhaupt zou moeten NAT’en in deze situatie.

[automation]

downtime schreef op maandag 4 december 2017 @ 08:48:
Ik zie eigenlijk niet waarom je uberhaupt zou moeten NAT’en in deze situatie.

Welk alternatief zou u voorstellen?

[Quas]

Kan je niet een firewall rule aanmaken of laten maken dat beide apparaten bij elkaar mogen komen.
Lijkt me dat dit de enige oplossing is

[downtime]

automation schreef op maandag 4 december 2017 @ 09:37:
[...]

Welk alternatief zou u voorstellen?

Volgens jouw tekening worden beide netwerken direct (via een router) aan elkaar gekoppeld en niet via internet. Ze gebruiken ook verschillende private IP-ranges. Ergo: Waar heb je dan NAT voor nodig? Gewoon een standaard router neerzetten en laten routen.

[ralpje]

automation schreef op maandag 4 december 2017 @ 08:43:

Beste johnkeates, het probleem is daarbij dat ik in beide apparaten dan wel het router (default gateway) adres in moet stellen. Helaas kan/mag ik dit bij een van de apparaten niet doen.

Als je vanuit subnet A wilt communiceren met subnet B zul je altijd een default gateway in moeten stellen.

[automation]

ralpje schreef op maandag 4 december 2017 @ 10:00:
Als je vanuit subnet A wilt communiceren met subnet B zul je altijd een default gateway in moeten stellen.

En dat is dus waarom ik het met NAT wil oplossen. Als ik het source en destination adres in 'beide richtingen' kan vertalen, dan denkt 192.168.10.5 dat hij met 192.168.10.10 communiceert. En 172.30.2.5 denkt dat hij met 172.30.2.10 communiceert. Zie https://www.uploadarchief.net/files/download/nat.png

In beide richtingen staat tussen haakjes, omdat er geen fysieke scheiding is. Beide apparaten zitten gewoon op dezelfde switch.

[downtime]

automation schreef op maandag 4 december 2017 @ 10:05:
[...]


En dat is dus waarom ik het met NAT wil oplossen. Als ik het source en destination adres in 'beide richtingen' kan vertalen, dan denkt 192.168.10.5 dat hij met 192.168.10.10 communiceert. En 172.30.2.5 denkt dat hij met 172.30.2.10 communiceert. Zie https://www.uploadarchief.net/files/download/nat.png

In beide richtingen staat tussen haakjes, omdat er geen fysieke scheiding is. Beide apparaten zitten gewoon op dezelfde switch.

Het klinkt nogal geimproviseerd. Dit lijkt mij typisch zo’n bedacht probleem wat ontstaat omdat iemand de normale oplossing weigert te gebruiken.

[automation]

Deze oplossing is inderdaad geïmproviseerd, en niet netjes of chique. En inderdaad, nog niet alle partijen willen meewerken aan een normale oplossing. Hopelijk is het een tijdelijke workaround en kunnen we later toewerken naar een normale oplossing.

[downtime]

automation schreef op maandag 4 december 2017 @ 10:25:
Deze oplossing is inderdaad geïmproviseerd, en niet netjes of chique. En inderdaad, nog niet alle partijen willen meewerken aan een normale oplossing. Hopelijk is het een tijdelijke workaround en kunnen we later toewerken naar een normale oplossing.

Als het simpel moet: In beide machines een tweede netwerkkaart met een IP-adres wat in de range van de andere machine zit. Multi-homed heet dat geloof ik. Dan hoef je verder niks meer te configureren.

En anders moet je eens uitleggen welke beperkingen er nu precies allemaal zijn. Wat kun en mag je allemaal niet?

[automation]

Beste,

ik zal het verhaal wat context geven.

Het betreft een netwerk van PLC's en andere industriële hardware. PLC 192.168.10.5 moet gegevens uit PLC 172.30.2.5 halen. Beide PLC's communiceren met tientallen andere industriële apparaten van diverse leveranciers. Ik kan de adressen niet zomaar wijzigen omdat:

• Daarvoor productiestilstand nodig is.
• IP adressen zijn geconfigureerd in applicatiesoftware. Ik kan- en mag geen applicaties van derden wijzigen in verband met garanties.

Op termijn moet alle hardware in één en hetzelfde subnet komen. Het kost nogal wat tijd om dit af te stemmen tussen de beheerders, automatiseringsleveranciers en productieverantwoordelijken. Tot die tijd heb ik een workaround nodig.

[unezra]

Een beetje potente multi-layer-switch moet dat prima kunnen, anders een eenvoudige firewall.

Wat je precies nodig hebt hangt ook een beetje af van het budget maar puur NAT heb je niet heel veel voor nodig. Hell, een pfSense doosje op een PC met 2 NIC's zou nog kunnen werken.

[Rolfie]

automation schreef op maandag 4 december 2017 @ 10:59:
Beste,

ik zal het verhaal wat context geven.

Het betreft een netwerk van PLC's en andere industriële hardware. PLC 192.168.10.5 moet gegevens uit PLC 172.30.2.5 halen. Beide PLC's communiceren met tientallen andere industriële apparaten van diverse leveranciers. Ik kan de adressen niet zomaar wijzigen omdat:

• Daarvoor productiestilstand nodig is.
• IP adressen zijn geconfigureerd in applicatiesoftware. Ik kan- en mag geen applicaties van derden wijzigen in verband met garanties.

Op termijn moet alle hardware in één en hetzelfde subnet komen. Het kost nogal wat tijd om dit af te stemmen tussen de beheerders, automatiseringsleveranciers en productieverantwoordelijken. Tot die tijd heb ik een workaround nodig.

Mijn eerste reactie is.... Ik zou hier erg mee uitkijken met dit soort hobbie oplossingen. Wat als het in eens fout gaat? En de productie gaat plat door jou "aanpassingen". Wie is er dan verantwoordelijk voor? Komen ze dan ook bij jou langs?

[automation]

Beste,

De uitbreiding die ik ga realiseren is niet kritisch in het productieproces. Ik heb mijn opdrachtgever erover geïnformeerd dat de (tijdelijk) gekozen oplossing niet duurzaam is.

Derhalve heb ik hier al enkele tips voorbij zien komen waar ik wellicht mee verder kan.

[unezra]

ralpje schreef op maandag 4 december 2017 @ 10:00:
[...]


Als je vanuit subnet A wilt communiceren met subnet B zul je altijd een default gateway in moeten stellen.

Hmmm. Ik lees nu dit pas.
Er staat *geen* default gateway ingesteld op die apparaten? Of de default gateway is telkens anders? (Dat laatste is prima op te lossen zonder NAT door het keurig te routeren maar domweg je router meerdere IP's te geven.)

[Annuk]

@automation Ik snap je bedoeling, maar is het in dit geval niet makkelijker 1 pc (de betreffende pc) met een dubbele (2e) netwerkkaart uit te rusten?

Zo kan je gewoon je bedrijfsnetwerk in (192.x.x.x) en je PLC netwerk (172.x.x.x), enige wat er dus veranderd moet is een 2e kaartje in prikken en even een vrijgegeven IP-adres in de 172 reeks in te stellen.

Bij ons op het werk hebben ze enkele jaren geleden dit juist uitgesloten (bovenstaande), en dat er geen enkele koppeling meer is tussen het PLC netwerk en het "normale" bedrijfsnetwerk, doordat er aangetoond werd dat van buitenaf destijds het bedrijfsnetwerk in te komen was en zodoende het gehele bedrijf plat zou kunnen leggen d.m.v. die ene pc die ook de koppeling had in het PLC netwerk.

[DataGhost]

ralpje schreef op maandag 4 december 2017 @ 10:00:
[...]


Als je vanuit subnet A wilt communiceren met subnet B zul je altijd een default gateway in moeten stellen.

Een gateway, geen default gateway. Je kan prima meerdere gateways instellen op je netwerk, voor verschillende IP-ranges. De default vangt alleen al het verkeer af waarvoor niks is ingesteld (doorgaans "het internet").

Wat is de setup van je netwerk? Als het zoiets is als A --- X --- B, en X de default gateway is op zowel A als B, dan hoef je alleen maar op apparaat X in te stellen dat de route 192... naar de kant van A gaat en 172... naar de kant van B. Je hoeft dan op A en B niks te wijzigen. Alternatief, als X alleen maar een simpele switch is, kan je op A en B gewoon een extra IP in beide ranges toevoegen en dan kunnen ze ook met elkaar praten.

[Paul]

ralpje schreef op maandag 4 december 2017 @ 10:00:
Als je vanuit subnet A wilt communiceren met subnet B zul je altijd een default gateway in moeten stellen.

Nee, je zult een route moeten specificeren. Dat hoeft niet per se de default gateway te zijn; je kunt prima het verkeer voor één adres (of subnet) naar de ene router sturen en al het andere verkeer naar een andere. Die andere router is dan je default gateway.

@automation Is er momenteel tussen die twee netwerken helemaal geen koppeling? Ze zitten op dezelfde switch, dus de kans is aanwezig dat ze beiden ook hetzelfde apparaat als gateway (maar beiden op een andere interface) gebruiken. Vaak is dat ofwel een L3 switch, ofwel een losse firewall.

De kans dat er geen verbinding te maken is tussen die twee terwijl ze wel op dezelfde switch zitten is erg klein; wel kan het zijn dat je bij de netwerkbeheerders langs moet om een aanpassing in een ACL of firewall te laten maken. Als ze dat niet willen, omdat er vanuit een bedrijfsbeleid geen verkeer mag zijn tussen de PLC's en het kantoornetwerk bijvoorbeeld, dan gaan ze ook niet gelukkig worden van je NAT-device en wordt dat ook gewoon losgetrokken als blijkt dat je het zonder overleg zou hebben geplaatst.

[automation]

Beste allen,

Voor de duidelijkheid wil ik nog vermelden dat de communicatie tussen twee PLC's (geen PC's) plaats moet vinden. Verder hebben we het hier uitsluitend over een machinenetwerk. Er is geenszins sprake van een koppeling met het internet of een bedrijfsnetwerk. Het huidige netwerk bevat geen routers of firewalls. Enkele "domme" switches.

Nog een belangrijke beperking van "mijn" PLC: om de verbinding te configureren, moeten de IP adressen in dezelfde range zitten. Zo niet, dan meldt de programmeeromgeving waarin de verbinding wordt gedefinieerd een fout, en kan de configuratie niet naar de PLC worden laden. De PLC's kunnen netwerktechnisch gezien dus wellicht communiceren, maar dit is uitgesloten op applicatieniveau.

[Paul]

Kun je op zo'n PLC op dezelfde interface meerdere IP-adressen invullen? Of heeft een van de PLC's de optie een 2e netwerkadapter aan te sluiten? En die applicatiebeperking, zegt die foutmelding "Het moet in hetzelfde subnet zitten" of iets als "no route to host"?

Als dat geen van beiden kan en je software erg krom is geschreven dan kom je inderdaad uit op een NAT-oplossing. Iedere willekeurige router die je wat meer opties geeft dan een domme thuisrouter kan dit. Denk aan een PC met pfSense, een pricewatch: Ubiquiti EdgeRouter X en vele anderen.

Dan is het inderdaad zaak twee interfaces te definiëren ,IP-adres aan koppelen om te managen, en omdat je dit zo te lezen nog een stuk vaker moet doen (je wil alle devices migreren naar één subnet; met zo'n NAT-device kun je dit per device regelen en dan één voor één de remote koppelingen overzetten naar het nieuwe adres) zou ik per PLC een virtueel IP-adres aanmaken. Vervolgens inderdaad twee 1:1 NAT-regels (beide kanten op één) en een firewall-regel die verkeer toestaat.

Wel zou ik dit eerst testen op een afgeschermd stukje (bijvoorbeeld met een losse switch en twee computers) zodat je tijdens het instellen niet per ongeluk iets omgooit in de productieomgeving.

[automation]

Beste Paul,

Door uw reactie bedacht ik mij plots dat de PLC wel degelijk uitbreidbaar is met een communicatieprocessor (netwerkkaart). En als ik voorgaande reacties over de NAT "oplossing" eens lees, is dat een uitstekende keuze, ondanks de dure hardware.

Alle tips over de NAT oplossing zal ik nog eens uitproberen in een verloren uurtje. Die Ubiquiti EdgeRouter X wil ik nog wel eens testen. Ik leg dit voor nu echter even naast me neer!

Edit (ter info, niet meer relevant voor mijn probleemstelling):
Volgens mij kan de Ubiquiti EdgeRouter X het niet. Je maakt hierin NAT-rules met een Source OF Destination vertaling. Vervolgens stel je prioriteiten in op de regels. De regel met de hoogste prioriteit wordt toegepast op het packet. Het lijkt erop dat er dus geen Source EN Destination vertaling op één packet toegepast kan worden. Bron: https://dl.ubnt.com/guides/edgemax/EdgeOS_UG.pdf
Met twee Ubiquiti EdgeRouter X lukt het misschien wel, maar of daar nu iemand vrolijk van gaat worden ...

[ Voor 47% gewijzigd door automation op 04-12-2017 17:13 ]

[Paul]

automation schreef op maandag 4 december 2017 @ 16:57:
Edit (ter info, niet meer relevant voor mijn probleemstelling):
Volgens mij kan de Ubiquiti EdgeRouter X het niet.

https://community.ubnt.co...LAN-NAT/m-p/755942#M25566

Maar 2e "netwerkkaart" in de PLC is wel een schonere oplossing inderdaad

[Cyberonline]

VLAN's instellen in de switch en in de Zone aangeven dat ze elkaar mogen bereiken?

[Paul]

Dan kun je er op laag 2 wel bij maar op laag 3 nog niet Afhankelijk van de huidige switch-config kunnen ze nu op laag 2 al bij elkaar.

Overigens, als je niet de adressen maar wel het subnetmasker aan mag passen, en er nu niet (helemaal niet...) wordt gerouteerd en je ook niet op (L3) broadcast vertrouwt, dan kun je het subnetmasker voor die twee PLC's zo ver oprekken dat beide devices wel in hetzelfde subnet zitten. Omdat er geen routers in het netwerk aanwezig zijn zorgt dit er niet voor dat de PLC ineens van alles lokaal gaat proberen te benaderen ipv via de router.