[GATEWAYS] Meer dan 1 default gateway ??

[Verwijderd]

Ik heb een Windows Terminal Server achter een firewall draaien met 2 segmenten en op elk segment een eigen publieke ipnummer.

Als ik nu van buiten uit een connectie maak met de TS dan kan ik alleen via de of de andere gateway met TSC werken. Welk ik kan gebruiken hangt af van de Default Gateway die ik op de server instel.

Je kunt meer gateways in Windows toevoegen echter TS blijft maar op 1 gateway werken en is nooit bereikbaar via beide gateways.

Kun je hier iets aan doen ?

[Brahiewahiewa]

Uh . . . route tabel aanpassen?

[Verwijderd]

Je geeft niet aan om welke windows-versie het gaat, maar officieel ondersteund NT niet meerdere gateways.

Je kunt wel meerdere gateways instellen, echter dan is het meer een 'redundancy' optie.

Overigens heb ik zelf met een soortgelijk probleem gezeten met een NT-4 bak, toen lang gezocht en overal gevonden dat het niet kon. Na een avond lang heen en weer schuiven met NIC's en gateways deed ie ineens wat ik wilde..

[Verwijderd]

Ik heb MS WIndows 2000 als besturingssysteem en het interne ipnummer is 192.168.1.22 Als default gateway gebruik ik nu even 192.168.1.1 (Linux systeem met 2 netwerkkaarten). Er staat nog een Linux systeem met ook twee netwerkkaarten; 1 voor publieke ips (internet) en 1 met een intern ip :

Routersysteem 1 : Publiek 212.19.210.194 / Prive 192.168.1.1
Routersysteem 2 : Publiek 212.19.210.55 / Prive 192.168.1.2

Beide Privenetwerken gaan naar een switch en vanuit deze switch gaat
er een kabeltje naar de MS Windows 2000 server. Deze machine moet van beide publieke ips bereikbaar worden gemaakt.

[Koffie]

Move > NT

[Brahiewahiewa]

Je kunt gerust meerdere default gateways opgeven in Windows. E.e.a. staat uitgelegd in Dead Gateway Detection in TCP/IP for Windows NT (ja, geldt ook voor Windows 2000, ook al staat het er niet in. De parameter heet dan DeadGWDetectDefault)

[Verwijderd]

Brahiewahiewa schreef op 01 oktober 2002 @ 15:09:
Je kunt gerust meerdere default gateways opgeven in Windows. E.e.a. staat uitgelegd in Dead Gateway Detection in TCP/IP for Windows NT (ja, geldt ook voor Windows 2000, ook al staat het er niet in)

Helaas is dit niet de oplossing voor zijn probleem. Zoals ik al aangaf, dit wordt alleen gebruikt om een 'dode' gateway op te sporen. Dit houdt in dat hij ALTIJD gateway 1 zal gebruiken, tenzij die niet werkt.

Als ik topicstarter goed begrijp komt het hier op neer, hij heeft 2 gateways, zeg A en B. Als nu een PC contact maakt via gateway B moet het retourverkeer ook via gateway B lopen. Maakt de PC contact via gateway A dan moet het verkeer via gateway A lopen.

Wat die dead-gateway-detection doet is dit: Standaard gaat al het verkeer via A. Doet A het niet, dan pas loopt het via B. En dat is echt iets anders...

// vandaar ook dat ik het een 'redundancy optie' noemde...

[Brahiewahiewa]

Verwijderd schreef op 01 oktober 2002 @ 15:13:
[...]Als ik topicstarter goed begrijp komt het hier op neer, hij heeft 2 gateways, zeg A en B. Als nu een PC contact maakt via gateway B moet het retourverkeer ook via gateway B lopen. Maakt de PC contact via gateway A dan moet het verkeer via gateway A lopen.[...]

Vat ik niet. Waarom zou een verbinding die binnenkomt via gate A, ook persé via gate A naar buiten moeten? Da's niet des TCP/IP's. De opzet van IP is nu juist dat een verbinding binnenkomend via gate A en prima via gate B uit zou moeten kunnen gaan.
De ontvangende party (in dit geval de terminal server client) gaat echt niet van elk pakketje controleren of het wel de juiste route heeft gevolgd. Als het maar aankomt. En als het niet aankomt is er dus iets anders mis; waarschijnlijk in één van beide gateways.

[Verwijderd]

Stel je het volgende voor. Ik heb een mailserver welke in twee segmenten hangt (multi-homed). In het ene segment heeft hij ip 1.1.1.1 en in het andere segment 2.2.2.2. Beide segmenten beschikken uiteraard over een default gateway (1.1.1.1 --> A, 2.2.2.2 -->B)

Stel ik laat die communiceren met een mailclient welke achter NAT zit, via het 2e segment (gateway B ). Dit pakketje wordt genat als 'verzonden aan 2.2.2.2', gaat door gateway B naar de mailserver, deze retourneerd het via z'n 1e default gateway (A) en dus met IP 1.1.1.1. Dat pakketje komt bij de NAT-machine aan. Die checked 'nope, niets verzonden aan 1.1.1.1' en weet dus niet waar hij met dat pakketje naar toe moet.

Dit levert zowieso problemen op, NAT of geen NAT.

//voor alle duidelijkheid.. het probleem zit 'm in het feit dat de PC verschillende IP's heeft voor beide segmenten.

[Brahiewahiewa]

Verwijderd schreef op 01 oktober 2002 @ 15:30:
[...]//voor alle duidelijkheid.. het probleem zit 'm in het feit dat de PC verschillende IP's heeft voor beide segmenten.

Hmm, ja. En dat heeft Winegummetje z'n server dus niet. Desondanks heb je een punt vwb NAT. 'k Denk dat een NAT gate niet zomaar adresjes gaat vertalen zonder dat er een established session is.

[Verwijderd]

Brahiewahiewa schreef op 01 oktober 2002 @ 16:10:
[...]

Hmm, ja. En dat heeft Winegummetje z'n server dus niet. Desondanks heb je een punt vwb NAT. 'k Denk dat een NAT gate niet zomaar adresjes gaat vertalen zonder dat er een established session is.

Ehm, ik lees in winegummetje's post:

en op elk segment een eigen publieke ipnummer.

[Brahiewahiewa]

Voordat je ook lid wordt van de NT irritation crew...als ik Winegummetjes posts lees:

Routersysteem 1 : Publiek 212.19.210.194 / Prive 192.168.1.1
Routersysteem 2 : Publiek 212.19.210.55 / Prive 192.168.1.2

en

het interne ipnummer is 192.168.1.22

stel ik me het volgende voor:

code:

          (192.168.1.0/24)
                 |
                 +----- (.1) Gate1 (212.19.210.194)
                 |
Server (.22)-----+
                 |
                 +----- (.2) Gate2 (212.19.210.55)

"de PC" (Winegummetjes server) heeft zit maar in 1 segment, waarin echter twee gateways zitten.
Omdat beide gateways NAT-en zal inderdaad een binnenkomende sessie via dezelfde gateway beantwoord moeten worden.

[Verwijderd]

Ah... nader bekeken heb je idd. gelijk

Wat betreft die NT irritation crew, waar kan ik me inschrijven?

//edit
bij nalezing schiet mij ook de oplossing voor dit probleem te binnen. Geef de 2e router een IP uit een ander segment, en bind in NT 2 ip's aan 1 NIC.

dus:

code:

                                          +----- (1.1) Gate1 (212.19.210.194)
                                           |
Server (192.168.1.22)------+
           (192.168.0.22)------+
                                          |
                                          +----- (0.1) Gate2 (212.19.210.55)

Op die manier weet je zeker dat een (natted) verbinding afkomstig van Gate2 ook terug gaat naar gate2...

//edit 2
wazige handel die [code] tags.. ze werken niet goed..

[Verwijderd]

Brahiewahiewa >> Helemaal goed begrepen. Ik ben niet zo goed in tekeningetjes (sorry). Jouw tekening geeft de situatie goed weer. Het is dus het probleem met de TS client die gewoon via .55 niet wil connecten omdat daar zijn default gateway niet terug naar toe gestuurd wordt.

Dat gaat dus gout maar wat ga ik er nu aan doen ??

[Brahiewahiewa]

Ik twijfel enigzins aan Hezik's workaround. Maar 'k kan effe niet sluiten beredeneren waarom het niet zou werken. Hij zou dus ook gelijk kunnen hebben.

Een geheel andere vraag is: waarom moet er van zowel via 212.19.210.55 als via 212.19.210.194 een connectie kunnen worden gemaakt? Wat is de meerwaarde van twee IP-adressen die in hetzelfde C-klasse subnet vallen en bij dezelfde provider worden gehost? (voorzover ik dat vanaf hier kan bekijken)

[Verwijderd]

Als je mijn workaround door-redeneert zul je zien dat die werkt..

even de twee situaties:

1) pakketje komt binnen bij router 1. Deze NAT 't naar het 1e interne segment, en stuurt 'm door naar de server. Deze krijgt een pakketje binnen van een computer uit het 1e segment, behandeld dit, en antwoord naar de computer binnen het 1e segment. Omdat alleen de router1 zich in het 1e segment bevind komt dit pakketje automatisch bij router 1 uit. Geen wisselende IP's ofzo dus NAT heeft er geen problemen mee.

2) pakketje komt binnen bij router 2. Deze NAT't naar het 2e interne segment (ander subnet), en stuurt 'm door naar de server. Deze krijgt een pakketje binnen van een computer uit het 2e segment, behandeld dit, en antwoord naar de computer binnen het 2e segment. Omdat alleen router2 zich in het 2e segment bevind komt dit pakketje automatisch bij router 2 uit.

Problem solved

[Brahiewahiewa]

Hmmz, pakketjes komen niet van die segmenten, althans ze zijn niet traceerbaar naar die segmenten. Iemand maakt vanaf internet (bijv: 62.63.64.65) een verbinding naar 212.19.210.55. De NAT verandert het to-adres naar 192.168.1.22 en stuurt 't door naar de server. Die server zie alleen maar from: 62.63.64.65 en to192.168.1.22. (da's IP, hij doet geen tracert o.i.d.). Hij beantwoordt dus vrolijk met een pakketje to 62.63.64.65 een stuurt dat via z'n default gateway naar buiten. Althans ik kan geen reden verzinnen waarom hij hiervoor een andere route zou willen kiezen. Default gateway is helaas 192.168.0.1 en - als deze al wil NAT-en; hij heeft immers geen established session, maar dat kun je idd uitzetten - daar wordt het ge-NAT naar een from-adres 212.19.210.194.

Op IP 62.63.64.65 komt een pakketje binnen from 212.19.210.194 en die machine denkt: "dûh, daar praat ik nie mee; DROP!" En da's maar goed ook; als een client dat wel zou accepteren, zou je een major security breach hebben. Dan worden er aan de lopende band sessions ge-hyjacked.

[Verwijderd]

[knip heel verhaal]

Ik ben idd niet duidelijk genoeg

Je hele verhaal klopt, als je alleen van DNAT uit gaat. Ik ga er bij mijn aannames van uit dat hij ook SNAT gaat toepassen op de routers.

Een pakketje komt dus aan met een inet-adres x.x.x.x geadresseerd aan poort y. De router trekt het source-IP eraf en plakt zijn eigen interne IP er aan, en dnat het hele zooitje naar de server.

Een soortgelijke setup heb ik al meerdere keren met succes toegepast, vnl in situaties waarbij er van provider gewisseld werd en bv. het MX-record voor de mail gewijzigd was/moest worden.

[Brahiewahiewa]

Verwijderd schreef op 02 oktober 2002 @ 11:26:
[knip heel verhaal]

Ik ben idd niet duidelijk genoeg
8<knip>8

Nu wel