[Slack] 2 nic's -> 2 gateways

[Mr. Right 1]

Ik heb een Slack-bak met 2 nics. Aan iedere nic hangt een router, welke beide met een andere ISP verbonden zijn. De IP-adressen op beide nics, zijn publieke adressen maar voor het gemak noem ik ze maar ff 192.168.1.10 en 192.168.2.10. De subnets zijn beide 255.255.255.0 en de gateways resp. 192.168.1.1 en 192.168.2.1

Onderstaand mijn rc.inet1:

code:

#! /bin/sh
# /etc/rc.d/rc.inet1

# Edit these values to set up your first Ethernet card (eth0):
IPADDR="192.168.1.10"
NETMASK="255.255.255.0"
NETWORK="192.168.1.0"
BROADCAST="192.168.1.255"
GATEWAY="192.168.1.1"

# Edit these values to set up your second Ethernet card (eth1),
IPADDR2="192.168.2.10"
NETMASK2="255.255.255.0"
NETWORK2="192.168.2.0"
BROADCAST2="192.168.2.255"
GATEWAY2="192.168.2.1"

# Set up the loopback interface:
/sbin/ifconfig lo 127.0.0.1
/sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo

# Set up the eth0 interface:
echo "Configuring eth0:"
/sbin/ifconfig eth0 ${IPADDR} broadcast ${BROADCAST} netmask ${NETMASK}

# Set up the eth1 interface:
echo "Configuring eth1:"
/sbin/ifconfig eth1 ${IPADDR2} broadcast ${BROADCAST2} netmask ${NETMASK2}

# Set up the gateway:
/sbin/route add default gw ${GATEWAY} metric 1

# End of /etc/rc.d/rc.inet1

Nu kan ik van buitenaf alleen eth0 pingen en niet eth1. Als ik de route omzet naar GATEWAY2, dan kan ik alleen eth1 pingen.

Wat moet ik veranderen om beide nics bereikbaar te maken voor de buitenwereld?

[Verwijderd]

echo 1 > /proc/sys/net/ipv4/ip_forward

probeer dat eens

[Mr. Right 1]

Ik zie niets gebeuren als ik dat doe

[CyBeR]

Mr. Right 1 schreef op 29 August 2003 @ 19:32:
Ik zie niets gebeuren als ik dat doe

Je hoort ook niets te zien. Maar IP forwarding staat nu aan

[Mr. Right 1]

Maar ik kan de 2e nic nog steeds niet bereiken...

[Sendy]

Dat lijkt me gewoon moeten werken. Heb je gecontrolleerd of de ifconfig instellingen ook zijn doorgekomen? Zet ook je routing tabel eens neer.

[CyBeR]

Wel, via die 2e nick worden de packets waarschijnlijk niet goed terug gezonden. Ze komen in principe aan, maar daarna worden ze via de andere nic weer terug gestuurd. Ik probeer te bedenken hoe je dat verhelpt, maar ik kan niet zeggen dat ik ervaring heb met machines die op 2 verschillende manieren aan hetzelfde netwerk (internet) hangen.

[Sendy]

Ik denk ook dat zoiets het moet zijn. Daarom: de routing tabel

[Verwijderd]

route table doe je met route -n of netstat -rn

[Mr. Right 1]

Hier de routing table:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.2.1 0.0.0.0 UG 1 0 0 eth1

En nu?

[Sendy]

Ooei, een beetje formatting zou geen kwaad kunnen... ([code] tags?)

En kan je van binnenuit wel machines buiten pingen?

[ Voor 30% gewijzigd door Sendy op 29-08-2003 20:01 ]

[Mr. Right 1]

Sorry...

code:

Kernel IP routing table
Destination   Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.1.0   0.0.0.0         255.255.255.0 U        40 0          0 eth0
192.168.2.0   0.0.0.0         255.255.255.0 U        40 0          0 eth1
127.0.0.0     0.0.0.0         255.0.0.0     U        40 0          0 lo
0.0.0.0       192.168.2.1     0.0.0.0       UG       40 0          0 eth1

[ Voor 28% gewijzigd door Mr. Right 1 op 29-08-2003 20:03 ]

[Mr. Right 1]

Ja, ik kan wel alles van binnenuit pingen

De kaarten komen wel op....als ik namelijk de GATEWAY omzet in de laatste route add, dan werkt het net de andere kant op.

[Sendy]

Wel vreemd. Je default gw zou niets uit moeten maken voor pakketjes die specifiek naar een (1) van de netwerken op eth0 en eth1 gaan. Ik zou zeggen dat het moet werken...

Wat gebeurt er als je de default gw weghaalt? Dan zou je toch de computers in je twee netwerken moeten kunnen pingen.

[ Voor 46% gewijzigd door Sendy op 29-08-2003 20:07 ]

[Kees]

De route die een packet volgt is wel van belang

Stel, ik ping vanaf 10.0.0.1 naar 2.10, de gateway staat op 1.1 ingesteld:

packet van 10.0.0.1 komt aan op 2.10, deze wordt intern verwerkt en er wordt een reply gestuurd. deze reply gaat naar 10.0.0.1, deze zit dus _niet_ in je routetabel, dus de eerste default gateway wordt gepakt, en dat is 1.1. mijn host (10.0.0.1) pingt nu dus 192.168.1.10 en krijgt antwoord over 192.168.1.1, nu zijn de meeste ISP's er niet zo happy op gespoofde IP adressen en blokkeren ze dus een uitgaand packet met een onbekend IP, gevolg: je packet wordt gedropt. en je krijgt geen reply.

[topic-titel-edit]Topic titel veel minder schreeuwerig gemaakt, denk er aub om dat wij gevoelige mensen zijn die niet tegen schreeuwen kunnen

[ Voor 13% gewijzigd door Kees op 29-08-2003 20:25 ]

[Mr. Right 1]

Sorry Kees

[CyBeR]

* CyBeR streelt kees

Wel vreemd. Je default gw zou niets uit moeten maken voor pakketjes die specifiek naar een (1) van de netwerken op eth0 en eth1 gaan. Ik zou zeggen dat het moet werken...

Normaal klopt dat. Maar wat als die twee nics nu deel uitmaken van het zelfde netwerk? Normaal zou je de routes per netwerk instellen, maar dat is hier dus niet het geval.

[Sendy]

CyBeR: als beide nics in hetzelfde netwerk zouden zitten dan zouden er geen twee route-tabel entries (voor de verschillende netwerken) zijn. Wat Kees zegt vind ik eigenlijk ook een beetje raar. Het pong pakketje heeft nu toch gewoon als afzender 192.168.1.1? Nou, toch, misschien gaat het wel zo inderdaad.

[Kees]

Als het pong packetje als afzender 192.168.1.1 heeft, dan negeert mijn ping-host hem, want ik ping 192.168.2.10 en niet 192.168.1.1 of .1.10

[Sendy]

Ik denk dat ping dat eigenlijk niet doet. Als je bijvoorbeeld een netwerk- of broadcast adres pingt, pingen verschillende machines terug. Jouw ping geeft dat allemaal weer. Ik denk niet dat ping de intellegentie heeft ingebouwd om te zien dat jij een netwerkadres intikte en dus alleen pakketjes van machine met dat netwerkadres laat zien. tcp is natuurlijk anders, want daarvoor moet er een bind() gedaan worden.

Het is misschien wel leuk eens met een sniffer te kijken welke pakketjes nu precies waarheen gaan. En als er dit soort 'vage' dingen gebeuren met multihomed hosts vraag ik me af hoe zoiets dan wel kan werken

-- edit
maar ik ben dan ook redelijk moe en zie de problemen en oplossingen niet meer zo goed.

[ Voor 9% gewijzigd door Sendy op 29-08-2003 22:04 ]

[CyBeR]

Ik denk dat de icmp echo reply packets (voor het gemak pong genoemd ) wel de goede afzender hebben, maar het verkeerde netwerk in gaan. Daar worden ze dan waarschijnlijk tegen gehouden. Alleen prutserige netwerken staan toe dat die packets geroute worden.

Je zou uitgaande packets moeten routen op welk adres er gebruikt wordt. Alleen heb ik dus geen idee hoe.

[Mr. Right 1]

Het vreemde blijft dat ik vanaf andere machines in beide netwerken beide kaarten kan pingen....maar van buitenaf kan ik er maar 1 bereiken.

[Verwijderd]

Sorry dat ik deze omhoog schop.

Het antwoord op je vraag waarom van buiten maar 1 nic te bereiken is, is deze:

Regel 6 in je route tabel zegt dat alle ips die niet onder bovenstaande regels vallen, via eth1 moeten worden geroute.
Dus het wam ip van eth1 is bereijkbaar van buiten af, omdat er een route regel bestaat voor deze eth.

De andere router (die aan eth0 hangt), heeft voor non-private ips, geen route regel, en is dus niet benaderbaar van buitenaf.

Als je bijv. een route regelmaakt, die zegt dat een specifiek ip via eth0 moet worden geroute, kan je via dat ip, je doos bereiken via de router die aan eth0 hangt.

Met de ouwe route, kan je niet zo maar 2 default gateways gebruiken.
Zo ver ik weet moet je met iproute2 package gaan spelen.
Misschien zijn hier mensen die een mooi werkend dual gateway op 1 system setupje hebben ? Eventueel ook met load balancing...

[CyBeR]

policy routing, idd met iproute2.

Gaat ongeveer zo:
ip route add default dev ethX via 123.45.67.89 table 123
ip rule add from 123.45.67.123 table
ip route flush cache

Alles vanaf ip 123.45.67.123 gaat nu via routing tabel 123, waar de default route op 123.45.67.89 staat. Uiteraard moet je ook eventuele andere routes zelf nog toevoegen.