Dotaz: nejde ping na statickou IP v LAN (Ubuntu 20.04)

[mrtn]

Zdravím,

potřeboval bych poradit nebo nasměrovat, v čem by mohl být problém: - mám domácí LAN 192.168.1.*, v ní několik PC, mobily a tablety členů rodiny, každý má statickou IP, domácí server má 192.168.1.35 - na serveru (Ubuntu 20.04) běží firewall ufw, na něm jsou jednotlivá zařízení povolená

Teď problém - pořídil jsem si nový tablet 192.168.1.90, povolil ve firewallu na serveru (stejně jako všechna ostatní zařízení), z tabletu není server 192.168.1.35 "vidět", nefunguje ani ping. Naopak taky ne.

Když tomu tabletu přiřadím IP jiného zařízení (např. 192.168.3.89, můj mobil), tak ping funguje. Naopak když zkusím přiřadit tuto IP mobilu, tak ping nefunguje.

Předpokládal jsem chybu nastavení firewallu, ale pořád to tak trvá, i když firewall vypnu (sudo ufw disable).

Na tom serveru běží ubuntu 20.04. Předpokládám, že tam asi něco blokuje tuto konkrétní IP adresu, ale netuším co by to mohlo být, když firewall vypnu.

Co by to mohlo být?

---

---

Odpovědi

[Jendа]

Přiřadit IP nejjednodušeji nějakému počítači kde jde pustit tcpdump/wireshark. Pustit ping, pustit tcpdump/wireshark na obou koncích, koukat.

[mrtn]

ok, přiřadil jsem tu IP adresu jednomu desktopu (taky Ubuntu 20.04), na oba nainstaloval wireshark a nechal běžet ping navzájem na sebe

z desktopu 192.168.1.90 odchází ping na server 192.168.1.35, zpátky ale vůbec nic

na server 192.168.1.35 ten ping dorazí, ale neodchází zpět nic, paket u něj vypadá takhle:

No.     Time           Source                Destination           Protocol Length Info
     14 0.368364797    192.168.1.90          192.168.1.35          ICMP     98     Echo (ping) request  id=0x0018, seq=2654/24074, ttl=64 (no response found!)

Frame 14: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface enp2s0, id 0
    Interface id: 0 (enp2s0)
    Encapsulation type: Ethernet (1)
    Arrival Time: Jun 24, 2023 13:37:59.678088089 CEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1687606679.678088089 seconds
    [Time delta from previous captured frame: 0.077377522 seconds]
    [Time delta from previous displayed frame: 0.077377522 seconds]
    [Time since reference or first frame: 0.368364797 seconds]
    Frame Number: 14
    Frame Length: 98 bytes (784 bits)
    Capture Length: 98 bytes (784 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:icmp:data]
    [Coloring Rule Name: ICMP]
    [Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: ASUSTekC_52:f7:ef (00:24:8c:52:f7:ef), Dst: TP-Link_8e:e4:89 (5c:a6:e6:8e:e4:89)
    Destination: TP-Link_8e:e4:89 (5c:a6:e6:8e:e4:89)
    Source: ASUSTekC_52:f7:ef (00:24:8c:52:f7:ef)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.90, Dst: 192.168.1.35
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 84
    Identification: 0xf365 (62309)
    Flags: 0x40, Don't fragment
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: ICMP (1)
    Header Checksum: 0xbf75 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.1.90
    Destination Address: 192.168.1.35
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0xc52d [correct]
    [Checksum Status: Good]
    Identifier (BE): 24 (0x0018)
    Identifier (LE): 6144 (0x1800)
    Sequence Number (BE): 2654 (0x0a5e)
    Sequence Number (LE): 24074 (0x5e0a)
    [No response seen]
    Timestamp from icmp data: Jun 24, 2023 13:37:59.000000000 CEST
    [Timestamp from icmp data (relative): 0.678088089 seconds]
    Data (48 bytes)

0000  31 4f 0a 00 00 00 00 00 10 11 12 13 14 15 16 17   1O..............
0010  18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27   ........ !"#$%&'
0020  28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37   ()*+,-./01234567
        Data: 314f0a0000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b…
        [Length: 48]

[Jendа]

z desktopu 192.168.1.90 odchází ping na server 192.168.1.35, zpátky ale vůbec nic

OK, zkontroloval bych, 1) jestli ve firewallu "nic není" (třeba dočasně) -- iptables-save vypíše celý firewall na stdout (jestli používáš nftables tak neporadím, ale Ubuntu 20.04 je snad dost staré aby nepoužívalo :), 2) jestli nemůže odpověď odcházet jiným interfacem (máš tam nějaký bridge, vpn…? - taky můžeš zkusit sniffovat na všech interfacech)

[mrtn]

OK, zkontroloval bych, 1) jestli ve firewallu "nic není" (třeba dočasně) -- iptables-save vypíše celý firewall na stdout (jestli používáš nftables tak neporadím, ale Ubuntu 20.04 je snad dost staré aby nepoužívalo :), 2) jestli nemůže odpověď odcházet jiným interfacem (máš tam nějaký bridge, vpn…? - taky můžeš zkusit sniffovat na všech interfacech)

Tak nakonec to byl ten firewall.

Ve tom výstupu iptables-save bylo upozornění, že existuje ještě iptables-legacy-save a když jsem zkoumal dál, tak jsem zjistil, že v tom prvním mám kromě té .90 ještě dvě další .91 a .92, na kterých jsem to zkoušel dál (a taky nefungovaly). Takže to vypadalo, že sice dělám změny v iptables, ale nějak to běží podle toho iptables-legacy, i když jsem vypínal firewall.

Nakonec jsem odinstaloval všechno s iptables a teď to jede všechno. Nanovo nastavení firewallu si už nechám na jindy.

Díky za rady.

[Jendа]

Doporučení: já u firewallu nikdy nedávám DROP, ale vždycky se snažím dávat REJECT. Když je pak nějaké spojení zakázané firewallem, přijde mi nějaké odmítnutí místo toho aby se to tiše ztratilo, a dá se to pak líp ladit.

Někdo tvrdí, že je lepší vůbec případným útočníkům neříkat, že nějaká cesta/server existuje a proto tiše zahazovat, ale mně to nepřijde nějak zásadní a pak se to dá právě ladit.

[mrtn]

Doporučení: já u firewallu nikdy nedávám DROP, ale vždycky se snažím dávat REJECT. Když je pak nějaké spojení zakázané firewallem, přijde mi nějaké odmítnutí místo toho aby se to tiše ztratilo, a dá se to pak líp ladit.

Někdo tvrdí, že je lepší vůbec případným útočníkům neříkat, že nějaká cesta/server existuje a proto tiše zahazovat, ale mně to nepřijde nějak zásadní a pak se to dá právě ladit.

Aha, super, to udělám.

[ewew]

V prvom rade je nutné sa prihlásiť do routra a pozrieť aktuálne aktívne zariadenia. Ako druhý krok skontrolovať v akom rozsahu je povolené DHCP. Ďalej je nutné skontrolovať či nemáš nastavenú izoláciu medzi WLAN a LAN. Skotroluj či nemáš na tablete zapnutú anonymizáciu, keďže pri každom pripojení zmeni MAC adresu čo si vezme jednú volnú IP na DHCP.

Môžeš skúsiť arping. Napríklad arping -d -c 1 192.168.1.90;echo $? a počkaj na výsledok. Ak bude 1, to znamená, že dve zariadenia majú rovnakú ip.

Pozor ak používaš lokálne ip adresy triedy C s sieťovou maskou 255.255.255.0 alebo /24, tak pre zariadenia môžeš použiť len od 1 do 254. Sieť je určená prvými tromi oktetmi x.y.z a adresa zariadenia je a.

Príklad sieťovania.

• Router - 192.168.1.1
• Ďalšie routre - 192.168.1.2 - 192.168.1.6
• Servery - 192.168.1.7 - 192.168.1.12
• PC - 192.168.1.13 - 192.168.1.33
• Tablety - 192.168.1.34 - 192.168.1.64
• Mobily - 192.168.1.65 - 192.168.1.105

Extrémne riešenie je použiť lokálne ip adresy triedy A a B. Teoretický rozsah A je 16777214 (10.0.0.1 až 10.255.255.254) a rozsah B je 65534 (172.16.0.1 až 172.16.255.254. Tu nemusíš sledovať počet adries.

[mrtn]

V prvom rade je nutné sa prihlásiť do routra a pozrieť aktuálne aktívne zariadenia. Ako druhý krok skontrolovať v akom rozsahu je povolené DHCP.

tohle je v pořádku, je tam 2 - 254

Ďalej je nutné skontrolovať či nemáš nastavenú izoláciu medzi WLAN a LAN.

Trvá to, i když tu IP adresu zkusím přidělit desktopu, tedy i v samotné LAN.

Skotroluj či nemáš na tablete zapnutú anonymizáciu, keďže pri každom pripojení zmeni MAC adresu čo si vezme jednú volnú IP na DHCP.

Nemám a děje se to, i když tu IP přidělím telefonu.

Môžeš skúsiť arping. Napríklad arping -d -c 1 192.168.1.90;echo $? a počkaj na výsledok. Ak bude 1, to znamená, že dve zariadenia majú rovnakú ip.

Nemělo by, kontroloval jsem to i na routeru. Ale i tak by se ten ping občas měl chytit? Když jsem s tím zkoušel tak různě měnit IP adresy, tak jsem tomu tabletu přidělil IP jiného desktopu (takže měly v tu dobu stejnou) a ping se chytil. A hlavně z jiných zařízení ten ping je v pohodě, jen z toho jediného (serveru) ne.

Pozor ak používaš lokálne ip adresy triedy C s sieťovou maskou 255.255.255.0 alebo /24, tak pre zariadenia môžeš použiť len od 1 do 254. Sieť je určená prvými tromi oktetmi x.y.z a adresa zariadenia je a.

Príklad sieťovania.

• Router - 192.168.1.1
• Ďalšie routre - 192.168.1.2 - 192.168.1.6
• Servery - 192.168.1.7 - 192.168.1.12
• PC - 192.168.1.13 - 192.168.1.33
• Tablety - 192.168.1.34 - 192.168.1.64
• Mobily - 192.168.1.65 - 192.168.1.105

Extrémne riešenie je použiť lokálne ip adresy triedy A a B. Teoretický rozsah A je 16777214 (10.0.0.1 až 10.255.255.254) a rozsah B je 65534 (172.16.0.1 až 172.16.255.254. Tu nemusíš sledovať počet adries.

Všechno to je v rozsahu 192.168.1.*, nejvyšší číslo je 192.168.1.116, ostatní jsou nižší, podobně jako ten příklad.

[ewew]

Nemôžeš mať statické adresy v rozsahu DHCP. Ak tam chceš mať statické musíš posunúť dolný rozsah dhcp na 117. Alebo si v routri pridel statické ip v dhcp.

[mrtn]

Nemôžeš mať statické adresy v rozsahu DHCP. Ak tam chceš mať statické musíš posunúť dolný rozsah dhcp na 117. Alebo si v routri pridel statické ip v dhcp.

To jsem asi špatně vyjádřil, je to:

"Use Router as DHCP Server"
Starting IP Address: 192.168.1.2
Ending IP Address 192.168.1.254

Address Reservation
1 192.168.1.9 devicename1 MAC Address
2 192.168.1.35 devicename2 MAC Address
atd.

Možná jsem to neměl nazvat statické, jsou tam přidělené resp. rezervované konkrétním zařízením, každé má svou.

[ewew]

Už mi nič iné nevychádzda. Možný problém je v tom, že niektoré routre majú v dĺžke prenájmu IP nastavené nekonečno. Zrejme si tam mal zariadenie bez pridelenia IP, v podstate dynamicky. Moja teoria je, že dhcp má tento záznam a nechce prideliť túto adresu, keďže je ako používaná a zrejme nedostal dhcp paket, ktorý uvoľnuje IP. Zmeň čas prenájumu na jednú hodinu (3600 sekúnd) a čakaj či neuvolní problémovú adresu.

Môžeš skúsiť zrušiť pridelenie IP adresy so štvrtým oktetom 90 a potom pozri či sa zariadenie, ktoré adresu používa. Skús ten arping -c 1-d 192.168.1.90. Alebo na linuxovom stroji ip neigh. Vypíše všetky zariadenia,ktoré majú zaznám v arp tabulke.

Extrémne riešenie je vymazať všetky pridelenia a nechať to nejaký čas kým si IP adresy nepovyberajú zariadenia. Keďže dynamický režim nedovolí aby mali dve zariadenia rovnakú IP. Nemáš niekde nastavenú statickú ip namiesto dynamického pridelovania cez DHCP ?

[mrtn]

Už mi nič iné nevychádzda. Možný problém je v tom, že niektoré routre majú v dĺžke prenájmu IP nastavené nekonečno. Zrejme si tam mal zariadenie bez pridelenia IP, v podstate dynamicky. Moja teoria je, že dhcp má tento záznam a nechce prideliť túto adresu, keďže je ako používaná a zrejme nedostal dhcp paket, ktorý uvoľnuje IP. Zmeň čas prenájumu na jednú hodinu (3600 sekúnd) a čakaj či neuvolní problémovú adresu.

Môžeš skúsiť zrušiť pridelenie IP adresy so štvrtým oktetom 90 a potom pozri či sa zariadenie, ktoré adresu používa. Skús ten arping -c 1-d 192.168.1.90. Alebo na linuxovom stroji ip neigh. Vypíše všetky zariadenia,ktoré majú zaznám v arp tabulke.

Extrémne riešenie je vymazať všetky pridelenia a nechať to nejaký čas kým si IP adresy nepovyberajú zariadenia. Keďže dynamický režim nedovolí aby mali dve zariadenia rovnakú IP. Nemáš niekde nastavenú statickú ip namiesto dynamického pridelovania cez DHCP ?

Tak nakonec tam ještě nějak strašil firewall, i když jsem ho vypnul a podle sudo ufw status byl inactive, tak navíc nepřidal pravidlo toho nového zařízení. Po kompletní odinstalaci to teď jede, další kolo nastavování příště. Díky za pomoc.