[linux] gateway achter gateway als default zetten

[flowerp]

Ik probeer momenteel een linux distro (knoppix live, 3.2 en 5.0) binnen VPC 6 onder Mac OS X 10.4.7 werkend te krijgen.

Het gaat echter mis bij de networking. Omdat ik alleen shared networking kan gebruiken (virtual switch werkt niet onder OS X 10.4), krijgt linux een IP via DHCP van VPC. Het is hiermee de bedoeling dat het guest OS via de verkregen default gateway het internet op kan. Alleen dit werkt gewoon niet.

Wat wel werkt is dat ik computers op het lokale netwerk kan bereiken. Ping 10.0.0.1 en ssh 10.0.0.1 werkt (bereik ik het host os mee) en ping 10.0.0.138 werkt ook (is de adsl modem/router).

Omdat de router richting het internet bereikbaar is, leek het me toch niet onmogelijk om internet aan de gang te krijgen in het client os. Als ik echter via het commando route 10.0.0.138 als default gateway probeer in te stellen krijg ik de melding dat 10.0.0.138 niet reachable is. Ik heb nog geprobeerd om eerst 10.0.0.138 naar de huidige gateway te laten gaan en dan 'default' naar 10.0.0.138, maar ook dat werkt niet.

Heeft iemand een idee hoe ik dit ongeveer zou kunnen aanpakken?

[Paul]

Doe eens een traceroute naar die "lokale" IP's? Ik gok dat je DHCP van de VPC een andere range uitdeelt, en dat de gateway die daarbij opgegeven wordt de VPC is en je dus een extra hop hebt tussen je guest OS en je "lokale" ip's

De VPC zou ze dus verder moeten sturen naar internet. Kan de VPC zelf wel op internet?

[flowerp]

Paul Nieuwkamp schreef op zondag 16 juli 2006 @ 14:22:
Doe eens een traceroute naar die "lokale" IP's? Ik gok dat je DHCP van de VPC een andere range uitdeelt, en dat de gateway die daarbij opgegeven wordt de VPC is en je dus een extra hop hebt tussen je guest OS en je "lokale" ip's

De VPC zou ze dus verder moeten sturen naar internet. Kan de VPC zelf wel op internet?

Inderdaad, dat zou ook de bedoeling moeten zijn, maar dat gebeurd dus niet. Mischien dat de makers van VPC (connectix) destijds alleen met Windows getest hebben. Upgraden naar de huidige versie (die nu van MS is) heeft dan ook weinig zin.

Traceroute geeft dit aan:

code:

traceroute 10.0.0.138
traceroute to 10.0.0.138 (10.0.0.138), 30 hops max, 40 byte packets
1 192.168.131.254 (192.168.131.254) 328.307 ms  31.793 ms  9.486 ms

De eerste hop is natuurlijk meteen de default gateway van het client os:

code:

netstat -rn
Kernel  IP  routing  table
Destination        Gateway              Genmask              Flags
192.168.131.0    0.0.0.0                 255.255.255.0       U
0.0.0.0               192.168.131.254   0.0.0.0                 UG

Waarbij de IP die het client OS via DHCP van VPC heeft gehad inderdaad in het 192.168.131 netwerk ligt:

code:

ifconfig eth0
eth0    Link encap:Ethernet
          inet addr:192.168.131.67   Bcast:192.168.131.255   Mask:255.255.255.0

Het is dus de bedoeling dat de client die 10.0.0.138 gaat gebruiken, zoals de host dat ook doet. De host kent het subnet van VPC overigens niet.

Op de host (mac os x 10.4.7)

code:

netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            10.0.0.138         UGSc       27     1628    en0
10/24              link#4             UCS         1        0    en0
10.0.0.1           127.0.0.1          UHS         0        0    lo0
10.0.0.138         0:e:50:dc:bf:d     UHLW        1        3    en0   1117
127                127.0.0.1          UCS         0        0    lo0
127.0.0.1          127.0.0.1          UH         14   264922    lo0
169.254            link#4             UCS         0        0    en0

[Paul]

Wat is link4? Die 10/24 zou ik daar niet verwachten? Nu wil hij 10.0.0.138 naar link4 routen, whatever that is?

Even voor de duidelijkheid:
Client OS: 192.168.131.67
VPC Virtual: 192.168.131.254

VPC Echt: 10.0.0.1
Speedtouch modem: 10.0.0.138

[flowerp]

Paul Nieuwkamp schreef op zondag 16 juli 2006 @ 18:20:
Wat is link4? Die 10/24 zou ik daar niet verwachten? Nu wil hij 10.0.0.138 naar link4 routen, whatever that is?

Ik heb eigenlijk geen idee. In BSD zijn de meeste commando's en output ongeveer zoals in GNU/Linux maar niet exact hetzelfde. Zo werkt ook bijvoorbeeld alleen het commando 'route' zonder params niet (werkt wel onder Linux) en wordt eth0 en0, etc. Die link4 ken ik dan ook niet. Ik neem aan dat dit iets typisch BSD is, want de internet verbinding op de host werkt perfect.
Voor als het iemand interesseerd, uname -srv geeft op de host:

code:

Darwin 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26 15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC

Even voor de duidelijkheid:
Client OS: 192.168.131.67
VPC Virtual: 192.168.131.254

VPC Echt: 10.0.0.1
Speedtouch modem: 10.0.0.138

Ja, dat klopt. Waarbij 10.0.0.1 dus het IP is van het OS/de machine waarop VPC zelf direct draait.

Wat ook opvalt is dat in het client OS, ifdown eth0 en ifup eth0 niet werkt. Meestal probeer ik dit als eerste om een nieuwe IP te forceren, maar in dit geval krijg ik zowel in een 2.4 kernel client (knoppix 3.2) alsmede een 2.6.17 (knoppix 5.0) een melding dat eth0 'not configured; is, ondanks dat ik dus wel eth0 kan gebruiken om naar 10.0.0.1 en 10.0.0.138 te pingen.

[CyBeR]

Probeer VPC eens te upgraden anders. VPC6 is oud en niet gemaakt om onder Tiger te draaien.

[Verwijderd]

Probeer op je ADSL modem een extra route aan te maken:
192.168.131.67/24 moet dit modem sturen naar 10.0.0.1

[ Voor 46% gewijzigd door Verwijderd op 16-07-2006 18:43 ]

[flowerp]

CyBeR schreef op zondag 16 juli 2006 @ 18:37:
Probeer VPC eens te upgraden anders. VPC6 is oud en niet gemaakt om onder Tiger te draaien.

Das natuurlijk een hele andere optie. In VPC7 update 2 werkt de virtual switch weer en dan zou het zowieso makkelijker gaan. Helaas is een upgrade niet helemaal triviaal omdat VPC commercieel is en er geen trials van zijn. Dit is heel flauw, want voor Windows geeft MS VPC wel gratis weg (vanwege de concurentie met VMWare). Ik ga morgen langs een vriend die dacht nog ergens vpc7 te hebben liggen en die niet meer gebruikt.

Toch vind ik het wel interessant vanuit technisch oogpunt om te proberen of het via een soort tunnel toch mogelijk is.

Ik begin de hoop echter wel een beetje op te geven. 10.0.0.138 is zoals gezegd wel te pingen, maar het modem weigert http requesten te accepteren, dit terwijl dit vanaf de host wel lukt. Als het al http requesten weigert, dan weigert het waarschijnlijk ook te routen mocht het me lukken 10.0.0.138 rechtstreeks door de client als gateway in te stellen.

Opzich zou het toch mogelijk moeten zijn dan de OS X box (de host: 10.0.0.1) zich als router gaat gedragen en verkeer komend vanaf het client OS door speelt naar 10.0.0.138. Ik weet echter niet precies hoe je dit opzet.

[flowerp]

Even een kleine update:

Ik heb vandaag de beschikking gekregen over VPC 7 die online was te updaten naar 7.02. De virtual switch doet het nu weer en mijn client os krijgt nu direct een IP via DHCP van het modem/router (in dit geval kreeg de client 10.0.0.2 terwijl de host dus 10.0.0.1 is).

Vanuit technisch oogpunt ben ik nog wel nieuwschierig of het met shared networking werkend te krijgen was geweest, maar vanuit practisch oogpunt werkt dit natuurlijk veel beter.

Iniedergeval bedankt voor het advies