Polskie Forum Użytkowników Debiana

Switch to aktualnie prosty niezarządzalny Netgear. Rzeczywiście nie sprawdzałem innego portu na nim. Kabel sprawdzałem, bo dorabiałem specjalnie, potem tester czy jest ok. Niestety obecnie na urlopie jestem i innego portu na switchu nie dam rady sprawdzić. Zdalnie do serwera jestem w stanie się łączyć poprzez inny komputer w sieci w firmie.

Zatem do Twojego powrotu do firmy sprawy raczej nie uda się ruszyć. Sprawdzić jeszcze możesz ethtool'em co pokaże Ci dla karty z publicznym IPkiem, czy widzi, że karta ma połączenie z czymś z drugiej strony i czy ma wynegocjowana prędkość.

Kod: Zaznacz cały

sadmin@scolo006:~$ ethtool enp2s0
Settings for enp2s0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Transmit-only
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

Dla porównania statystyki interfejsu LAN:

Kod: Zaznacz cały

sadmin@scolo006:~$ ethtool enp1s0
Settings for enp1s0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Transmit-only
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

Wygląda, że jest w porządku i ma "coś" po drugiej stronie. Jeśli na tej maszynie nie masz firewalla to albo kabel albo switch "blokuje" ruch.

Aktualnie firewall wygląda następująco, po prostu puszcza wszystko. Dla testu chciałem i jego wyeliminować:

Kod: Zaznacz cały

sadmin@scolo006:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Kod: Zaznacz cały

sadmin@scolo006:~$ sudo ufw status
Status: inactive

Kabel jest na 99,99% sprawny, bo tester to wykazał. Poza tym do służbowego laptopa go podłączałem jeszcze w celu dodatkowego testu działania.

Spróbuję może podpiąć do tego samego portu na switchu co obecnie działa ten drugi serwer. Gorzej jak się okaże, że to nie pomoże.

PS
Znalazłem jakiś czas temu ten sam link do manuala a propos onlink, który podałeś i znalazłem również fragment:
onlink pretend that the nexthop is directly attached to this link, even if it does not match any interface prefix.
Niestety nie ukrywam, że niezbyt rozumiem o co chodzi. Onlink oznacza, że router jest podłączony bezpośrednio nawet jeśli nie pasuje do prefixu interfejsu. Czym jest prefix interfejsu i czy dobrze zdekodowałem angielszczyznę?

Ja bym to interpretował, że ten IP bramy jest na pewno na tym interfejsie nawet jeśli "nie pasuje" do IP na interfejsie.
//Jeśli źle prawię, proszę poprawcie mnie.//

Btw. Zerknij raz jeszcze dokładnie na wpisy konfiguracji dla tego interfejsu, czy nie masz czasem czeskiego błędu (literówki/innej cyfry niż być powinna).

A ja mam inne pytanie:
Komputery w sieci lokalnej z których próbujesz pingnąć publiczny adres jaką mają adresację? Prywatną? Jeśli tak to czy ruch od nich idzie przez router .177?
Czy na routerze .177 nie ma ustawionych jakichś reguł blokujących ruch, np. mac-ip?

LordRuthwen pisze: ↑02 sierpnia 2017, 06:53 A ja mam inne pytanie:
Komputery w sieci lokalnej z których próbujesz pingnąć publiczny adres jaką mają adresację? Prywatną? Jeśli tak to czy ruch od nich idzie przez router .177?
Czy na routerze .177 nie ma ustawionych jakichś reguł blokujących ruch, np. mac-ip?

Komputery z sieci mają adresację prywatną, ale są w stanie pingować drugi serwer z końcówką .180 stojący obok w szafie, a tego ze .181 już nie. Jedyna różnica to "onlink" zwracane przez ip route. Reszta - z podstawowych komend zwraca to samo.

Jeśli macie jakieś komendy dodatkowe, które mogą pomóc zweryfikować problem to mogę je wykonywać na obu serwerach i wrzucać. Problem jest bardzo palący, a sprawa wyglądała na rutynową z początku - ot skonfigurować interfejs WAN.

Połącz się bezpośrednio kablem do tego serwera (najwygodniej pewnie z laptopa) do jego interfejsu, który ma adresację prywatną. Na laptopie ustaw adresację z tej sieci i daj jako bramę IP serwera.
1. Sprawdź z laptopa ping do bramy sieci lokalnej (pewnie pójdzie bez problemu)
2. Sprawdź z laptopa ping do adresu publicznego serwera
Jeśli w pkt. 2 ping nie pójdzie sprawdź na serwerze czy masz włączone przekazywanie pakietów (ip_forward).

[Bezpośrednie łączenie kablem w sumie może nie jest konieczne, konfiguracja interfejsów serwera i laptopa wg. powyższego opisu już tak, jednak pomoże wyeliminować ewentualną przyczynę problemów na switchu.]
Jeśli "ping test" z połączeniem bezpośrednim na publiczny IP będzie pozytywny, zepnij ten WANowy interfejs z miejscem, gdzie powinien on mieć dostęp do bramy (publiczny IP) i sprawdź ping a) z serwera do bramy (na publiczny IP), b) z laptopa podłączonego do interfejsu lokalnego do bramy (publicznego IP).

Dzięki wielkie za wszelakie sugestie. Ogarnąłem temat. Problemem był kabel od interfejsu WAN wpięty nie w ten port co trzeba.

Polskie Forum Użytkowników Debiana

Niewidoczny w sieci serwer z publicznym IP - Ubuntu 16.04

Re: Niewidoczny w sieci serwer z publicznym IP - Ubuntu 16.04

Re: Niewidoczny w sieci serwer z publicznym IP - Ubuntu 16.04

Re: Niewidoczny w sieci serwer z publicznym IP - Ubuntu 16.04

Re: Niewidoczny w sieci serwer z publicznym IP - Ubuntu 16.04

Re: Niewidoczny w sieci serwer z publicznym IP - Ubuntu 16.04

Re: Niewidoczny w sieci serwer z publicznym IP - Ubuntu 16.04

Re: Niewidoczny w sieci serwer z publicznym IP - Ubuntu 16.04

Re: Niewidoczny w sieci serwer z publicznym IP - Ubuntu 16.04

Re: Niewidoczny w sieci serwer z publicznym IP - Ubuntu 16.04

Re: Niewidoczny w sieci serwer z publicznym IP - Ubuntu 16.04