# Server nach Update "von Außen" nicht mehr erreichbar

## Obelix

Hallo zusammen,

ich versuche gerade einer äußerst merkwürdigen Problematik auf den Grund zu gehen:

Mein "Server" wurde seit einiger Zeit nicht mehr aktualisiert, daher habe ich am Wochenende mal wieder ein world-update gemacht. Es hat, inklusive Kernel, alles geklappt. Die Kiste ist von allen Rechnern im Netz erreichbar und scheint zu laufen.

Ich habe aber auch Dienste (ftp und rsync), die von außen bedient werden. Beide sind nicht mehr erreichbar. Jetzt sollte man meinen, dass der Router dafür verantwortlich ist (LANCom 1611+, meiner Meinung nach der Größte Mist, den man verwenden kann, aber das ist hier nicht das Thema. Das Teil wird in wenigen Stunden ersetzt). Der Router hat aber nichts damit zu tun. Wenn ich die Portweiterleitung an einen anderen Rechner mache, klappt alles ganz normal, außerdem habe ich am LANCom ja nichts verändert, sondern am gentoo-Server.

Leider verstehe ich schon mal gar nicht, warum alle (!!) Dienste "von innerhalb" erreichbar sind, aber "von außerhalb" nicht. Soll heißen, wenn es vom Router weitergeleitet wird, verweigert mein gentoo-System den Zugriff, kommt die Anfrage von einem Rechner aus dem lokalen Netz, klappts...

Für Hinweise und Vorschläge bin ich dankbar!

Gruß

Obelix

----------

## Hollowman

Hi

Guck dir doch mal die routing Tabelle an. Fehlt eventuell die default route? Klingt irgendwie so.

Zeig mal ein route -n

Sebastian

----------

## Obelix

gnas ~ # route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         192.168.1.1     0.0.0.0         UG    1      0        0 eth1

0.0.0.0         192.168.1.1     0.0.0.0         UG    2      0        0 eth0

127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

----------

## manuels

hmm, bin kein Routing-Experte, aber kann es sein, dass die Pakete, die am Server ankommen, über das eine ethX-Device ankommen, über das andere ethY-Device beantwortet werden [Y=(X+1) mod 2]?

----------

## py-ro

Also wenn das alles konfigurierte zum Routing ist, dann war das Zufall, dass das überhaupt mal funktioniert hat.

Häng mal bitte deine komplette Config dran.

----------

## Obelix

Danke schon mal, dass sich das jemand ansieht...

Die config (/etc/conf.d/net):

config_eth0="192.168.1.210 netmask 255.255.255.0 brd 192.168.1.255"

routes_eth0="default via 192.168.1.1"

config_eth1="192.168.1.211 netmask 255.255.255.0 brd 192.168.1.255"

routes_eth1="default via 192.168.1.1"

----------

## py-ro

So wirklich richtig kann das nicht funktionieren.

Du hast zwei Interfaces mit dem selben Subnet. Muss das unbedingt sein?

Um das so zum laufen zu bekommen, gibt es zwei Möglichkeiten die mir spontan einfallen. Policy-Based-Routing, damit die Pakete einer Verbindung auf der selben Netzwerkkarte rausgehen wie auch rein oder eine Bridge über beide Interfaces, diese sollten dann allerdings besser nicht am gleichen Switch hängen.

Py

----------

## Obelix

...hmmmm....

Meine Absicht war eigentlich, dass der Netzwerkverkehr auf dem Teil etwas "entzerrt" werden kann, in der irrigen Annahme, dass dienste, die ich über die eine IP anspreche auch über diese Netzwerkkarte laufen, und Dienste, die über die andere IP gehen, die andere Karte belegen.

Also konkret: Ich lass z.B. ftp und rsync und alles, was von außen über das Internet kommt über 192.168.1.211 gehen, und die cifs Freigabe zum Streamen über 192.168.1.210

Wie kann man das sauber realisieren? zugegeben ist das nicht notwendig, aber ich will ja was dazu lernen. Deswegen habe ich ja gentoo und nicht Windows HomeServer  :Wink: 

Danke für die Unterstützung

Obelix

p.s. für die schnelle aktivierung meiner Dienste deaktiviere ich mal die zweite Netzwerkkarte - aber die andere Lösung wäre mir lieber...

----------

## py-ro

Diese Annahme ist leider falsch, der Kernel verwendet zum antworten prinzipiel das "erste" Interface das eine passende Route aufweisen kann. Bisher war das bei Dir eben zufällig das richtige.

Das Stichwort ist Policy-Based Routing und ist gar nicht so einfach, sobald ich daheim bin, kann ich dir eine Beispiel /etc/conf.d/net posten, dann kann sich der Kernel so verhalten, wie Du (und ich früher auch) es erwarten.

Ansonsten sei auf:

http://lartc.org/howto/

verwiesen.

Bye

Py

----------

## Obelix

...das mit dem Beispiel wäre nett. Vorerst habe ich eine Schnittstelle deaktiviert, aber um was neues zu lernen stelle ich sie gerne wieder aktiv...

Gruß

Obelix

----------

## py-ro

Nein, das war schon immer so.

Was du meinst ist das schon genannte ufed...

Bye

Py

----------

## mv

 *py-ro wrote:*   

> Was du meinst ist das schon genannte ufed...

 

Verwechslung des Threads  :Wink: 

----------

## py-ro

Jop, zu müde und zu viele Tabs.  :Wink: 

Aber ich hab das Beispiel gestern komplett vergessen, das ist noch auf meinem DOM-Modul daheim, hab mein NAS am Wochenende zerlegt, sonst könnte ich das auch Remote holen.

Py

----------

## py-ro

Sorry, bin Momentan etwas im Streß, ich hab das DOM-Modul schon wieder vergessen mitzunehmen...

----------

## Hollowman

Hi

Wo steht der Server denn? Ist das eher nen Heimserver oder steht der in ner gescheiten Netzumgebung? Wenn ja dann schau doch mal ob der Switch hinten dran mit bonding klar kommt. Dann solltest du Netzmässig keine Probleme mehr haben.

Ansonsten bleibt nur policy routing. Da kann ich die Woche mal gucken ob ich eine config für dich hab. Da komm ich aber jetzt nicht ran.

Sebastian

----------

## py-ro

Besser spät als nie.

Viel Spaß beim Verstehen.  :Wink: 

```

config_eth0="null"

bridge_br0="eth0"

config_br0="

        192.168.2.2/24

        2a01:xxx:2c5::1/48"

dns_servers="127.0.0.1 8.8.8.8 8.8.4.4"

dns_domain="home.xxxxxxxxx.de"

dns_search="home.xxxxxxxx.de"

#rc_need_ppp0="net.br0"

link_ppp0="br0"

plugins_ppp0="pppoe"

username_ppp0='xxxxxxxx'

password_ppp0='xxxxxxxx'

pppd_ppp0="

        noauth

        nodefaultroute

        holdoff 3

        persist

        lcp-echo-failure 3

        lcp-echo-interval 3

        updetach

        "  

rules_br0="dev br0 table pynet"

routes_br0="

        192.168.2.0 dev br0 src 192.168.2.2 table pynet

        default via 192.168.2.1 table pynet

        192.168.2.0 dev br0 src 192.168.2.2

        default via 192.168.2.1

"

#rules_ppp0="dev ppp0 table xxx_uplink"

rules_ppp0="from 85.116.xxx.154 table xxx_uplink"

routes_ppp0="

        85.116.xx2.1 dev ppp0 src 85.116.xx3.154 table xxx_uplink

        default dev ppp0 table xxx_uplink

        89.238.75.0/24 dev ppp0 

        217.11.51.0/24 dev ppp0

        85.116.xx2.1 dev ppp0 src 85.116.xx3.154

        91.184.37.98 dev ppp0 src 85.116.xx3.154

"

#rc_need_gre1="net.ppp0"

iptunnel_gre1="mode gre remote 89.238.75.161 key 0xxxxxxxx ttl 255"

config_gre1="192.168.3.2/24"

routes_gre1="

        192.168.3.0/24 dev gr1 src 192.168.3.2 table gre_up

        default dev gr1 table gre_up

        192.168.3.0/24 dev gr1"

```

----------

