Verbindung zweier System

[malzusrex]

Hallo Gemeinde.
Folgendes Problem:
2 AS/400 sind über 2 Router und VPN verbunden. Soweit ja nix besonderes. Haben wir auch mit diversen Maschinen am laufen.
Ich habe aber 2 Kisten, da funktioniert von A nach B soweit alles: Telnet, Ftp, Ping, Sndnetf,....
Von System nach B nach A geht aber nix... ?
CFGTCP, CHGNETA, *dftroute, Grundeinstellungen für SNAoverIP ist mit den anderen Systemen, wo es ja geht, abgeglichen.
Hat jemand einen Ansatzpunkt für mich, wo ich noch nachschauen kann...

Gruß Ronald

[Fuerchau]

Mittels TRACEROUTE mal nachsehen, ab wann die Verbindung schief geht, schließlich sind ja da mehrere beteiligt.

[malzusrex]

Das Prottokoll sagt mir da nicht viel (zumindestens mir nicht)

TRACEROUTE RMTSYS(XXX) OUTPUT(*VERBOSE) ADRVERFMT(*IP4)
Mögliche Leitwege zu GTC10 (192.168.1.1) mit Schnittstelle *ANY werden
untersucht.
36 BYTES FROM 172.16.1.2 TO 172.16.1.26: ICMP TIME EXCEEDED (TYPE 11 CODE
0).
RECVFROM() DATA (CATEGORY: -3) (40 OF 40 BYTES)
4500 0038 1E47 0000 3C01 0642 AC10 0102
AC10 011A 0B00 9DA6 0000 0000 4500 0028
E3FB 0000 0101 6706
36 BYTES FROM 172.16.1.2 TO 172.16.1.26: ICMP TIME EXCEEDED (TYPE 11 CODE
0).
RECVFROM() DATA (CATEGORY: -3) (40 OF 40 BYTES)
4500 0038 1E49 0000 3C01 0640 AC10 0102
AC10 011A 0B00 E0DD 0000 0000 4500 0028
E3FD 0000 0101 6704
36 BYTES FROM 172.16.1.2 TO 172.16.1.26: ICMP TIME EXCEEDED (TYPE 11 CODE
0).
RECVFROM() DATA (CATEGORY: -3) (40 OF 40 BYTES)
4500 0038 1E4B 0000 3C01 063E AC10 0102
AC10 011A 0B00 E757 0000 0000 4500 0028
E3FF 0000 0101 6702
1 172.16.1.2 1,53 0,822 1,09
48 BYTES FROM 82.82.6.90 TO 172.16.1.26: ICMP DEST UNREACHABLE (TYPE 3
CODE 13).
RECVFROM() DATA (CATEGORY: 13) (40 OF 40 BYTES)
4500 0044 0000 0000 FE01 B6E2 5252 065A
AC10 011A 030D 9FF9 0000 0000 4500 0028
1E4D 0000 0001 2DB5
48 BYTES FROM 82.82.6.90 TO 172.16.1.26: ICMP DEST UNREACHABLE (TYPE 3
CODE 13).
RECVFROM() DATA (CATEGORY: 13) (40 OF 40 BYTES)
4500 0044 0000 0000 FE01 B6E2 5252 065A
AC10 011A 030D 9FF9 0000 0000 4500 0028
1E56 0000 0001 2DAC
48 BYTES FROM 82.82.6.90 TO 172.16.1.26: ICMP DEST UNREACHABLE (TYPE 3
CODE 13).
RECVFROM() DATA (CATEGORY: 13) (40 OF 40 BYTES)
4500 0044 0000 0000 FE01 B6E2 5252 065A
AC10 011A 030D 9FF9 0000 0000 4500 0028
1E58 0000 0001 2DAA
2 82.82.6.90 38,0/13 20,6/13 20,8/13
TRACEROUTE: END OF TRACEROUTE 0/3.

An welcher Stelle muss ich nun schauen ?

[Fuerchau]

Hier ist die Frage, wer sich hinter den genannten IP-Adresse verbirgt und wo die Standorte dazu sind.

Wenn ICMP abgeschaltet ist, kann der Traceroute wohl nicht viel harausbekommen.

Ich nehme mal an 172.16.1.2 ist deine AS/400 und 172.16.1.26 ist dein Router.

Wer ist dann 82.82.6.90 ?
Dein VPN-Provider ?

[malzusrex]

da sind wir noch am suchen.
deine Vermutungen sind richtig.
Wenn ich den Spaß von der anderen Seite mache, dann steht am Anfang und am Ende der Route je die Maschine wie es sein sollte. Wer diese IP ist, sind wir noch am suchen...

.mal sehen ob wir auch finden werden ;-)

[Pikachu]

Wer ist dann 82.82.6.90 ?
Dein VPN-Provider ?

82.82.6.90 ist derzeit die Arcor AG

[holgerscherer]

Wenn ich den Spaß von der anderen Seite mache, dann steht am Anfang und am Ende der Route je die Maschine wie es sein sollte. Wer diese IP ist, sind wir noch am suchen...

Da stimmt was im Routing nicht. Lass das *verbose mal weg, das irritiert nur.

82.82.6.90 weiss nicht, wohin mit den Paketen, da es eine Routing-Anfrage in einen privaten Netzbereich kriegt. Also dürfte der Router, an dem 172.16.1.26 hängt, nicht wissen, wohin die Pakete für 192.168.1.1 gehen sollen.
Wenn die Gegenrichtung läuft, ist das nix besonderes, da das Antworten der Pakete auch von der Quell-MAC-Adresse abhängt. Wie sieht die Routing-Tabelle aus?

-h

[Fuerchau]

OK, da stimmt was nicht mit dem VPN, denn Arcor ist nicht für das Routing in diesem Fall verantwortlich.

Wenn das VPN aktiv ist, wird nicht nach Arcor sondern zum VPN-Provider geroutet, da nur der das Ziel kennen kann.

Also ist entweder das VPN noch gar nicht geöffnet (auf dem lokalen Router) oder das Gateway der AS/400 weist nicht zu der Einheit, die die VPN-Verbindung aufmacht.