Problém s lantencí (ztráta paketů) na veřejné IP

[Warezjoe]

Zdavím,

   měl jsem porvé v životě tu čest souštět server s veřenou IP. Bohužel mám s tím v hlavičce uvedený problém. Zde jsou detaily verze serveru.

Kód: [Vybrat]

./+o+-
                  yyyyy- -yyyyyy+      OS: Ubuntu 20.04 focal
               ://+//////-yyyyyyo      Kernel: x86_64 Linux 5.4.0-59-generic
           .++ .:/++++++/-.+sss/`      Uptime: 50m
         .:++o:  /++++++++/:--:/-      Packages: 616
        o:+o+:++.`..```.-/oo+++++/     Shell: bash 5.0.17
       .:+o:+o/.          `+sssoo+/    Disk: 7.4G / 18G (44%)
  .++/+:+oo+o:`             /sssooo.   CPU: Intel Xeon E5410 @ 2.333GHz
 /+++//+:`oo+o               /::--:.   GPU: VMware SVGA II Adapter
 \+/+o+++`o++o               ++////.   RAM: 483MiB / 3936MiB
  .++.o+++oo+:`             /dddhhh. 
       .+.o+oo:.          `oddhhhh+   
        \+.++o+o``-````.:ohdhhhhh+   
         `:o+++ `ohhhhhhhhyo++os:     
           .o:`.syhhhhhhh/.oo++o`     
               /osyyyyyyo++ooo+++/   
                   ````` +oo+++o\:   
                          `oo++.
   Obě rozhraní běží bez problému. Přistup k DNS taky funguje. Jako firewall jsem použil UFW. Iptables jsem úplně vyčistil.

Kód: [Vybrat]

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:76:e4:0d brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.32/24 brd 192.168.100.255 scope global ens160
       valid_lft forever preferred_lft forever
3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:76:e4:17 brd ff:ff:ff:ff:ff:ff
    inet 83.208.220.156/29 brd 83.208.220.159 scope global ens192
       valid_lft forever preferred_lft forever   Ještě sem přivám obsah yaml souboru k netplan. Renderery jsem zkoušel oba, funguje mi jen ten nezakomentovaný.

Kód: [Vybrat]

network:
  version: 2
  renderer: networkd
#NetworkManager
  ethernets:
   ens192:
    dhcp4: no
    addresses: [83.208.220.156/29]
    gateway4: 83.208.220.153
    nameservers:
     addresses: [8.8.8.8]
Ping na danou IP se asi může každý zkusit sám. Předem děkuji za každou radu, google mi v tomto vůbec nepomohl.

[Reklama]

[IDontCare]

Problem je mezi tvoji gateway  83.208.220.153 a serverem 83.208.220.156 protoze gateway odpovida uplne v pohode:

PING 83.208.220.153 (83.208.220.153) 56(84) bytes of data.
64 bytes from 83.208.220.153: icmp_seq=1 ttl=250 time=1.82 ms
64 bytes from 83.208.220.153: icmp_seq=2 ttl=250 time=1.62 ms
64 bytes from 83.208.220.153: icmp_seq=3 ttl=250 time=1.64 ms
64 bytes from 83.208.220.153: icmp_seq=4 ttl=250 time=1.53 ms
64 bytes from 83.208.220.153: icmp_seq=5 ttl=250 time=1.63 ms
64 bytes from 83.208.220.153: icmp_seq=6 ttl=250 time=1.64 ms
....

[Warezjoe]

To mi moc nedává smysl. GW na našel PFsence je nastavená úplně stejně. Ten jsem tedy nenastavoval já, ale Ping na ní odpovídá normálně (83.208.220.155). Takže volat providera?

[cek_post.cz]

Malo informaci....

fyzickej/virtualni?
vytizeni HW?
sitove je to jak propojeny?
z toho serveru ping ven taky pada?

za me po cem bych sel jako prvnim: Pokud fyzicky zelezo, zkontroluj kabely. Pokud virtualni, podival bych se po kolizi adres.

[TWVzc2E]

Jenom tipuju - zkus vypnout offloading, jestli to pomůže.

sudo ethtool -K ethx rx off tx off sg off tso off ufo off gso off gro off lro off 

[Reklama]

[Warezjoe]

Pro TWVzc2E:
Tenhle příkaz neznám. Vrací mi toto:

Kód: [Vybrat]

sudo ethtool -K ens192 rx off tx off sg off tso off ufo off gso off gro off lro off 
Cannot change udp-fragmentation-offload
Pro cek_post.cz:
1. Virtuál, běží na ESXI.
2. V příloze.
3. Jednoduše 2xInterface, jeden vnitřní, jeden vnější
4. Ne komunikace ven je v pohodě.

Jinak kolize nehrozí.

[_Jenda]

"tcpdump -ni ens192 icmp" nebo "tcpdump -ni ens192 host ip_odkud_pingáš" a uvidíš, jestli pakety vůbec nepřijdou, nebo na ně neodpovíš, nebo nepřijde odpověď. Pak totéž na gateway.

[Warezjoe]

Dobrá rada jsem zase blíž k řešení. Server na některé requesty vůbec neodpovídá. Je možné, že je to někdy v nějakém cofigu omezené? Jak dál?

Btw co se gateway týče, nemám ji ve správě. Musel bych to řešit s providerem.

Kód: [Vybrat]

sudo tcpdump -ni ens192 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), capture size 262144 bytes
08:41:42.204563 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 1, length 64
08:41:42.204664 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 1, length 64
08:41:43.391105 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 2, length 64
08:41:43.391189 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 2, length 64
08:41:44.471222 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 3, length 64
08:41:45.178873 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 4, length 64
08:41:45.178969 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 4, length 64
08:41:46.349173 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 5, length 64
08:41:47.201026 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 6, length 64
08:41:47.201117 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 6, length 64
08:41:48.181012 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 7, length 64
08:41:49.200990 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 8, length 64
08:41:49.201076 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 8, length 64
08:41:50.390776 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 9, length 64
08:41:51.220899 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 10, length 64
08:41:51.220987 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 10, length 64
08:41:52.221047 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 11, length 64
08:41:52.221134 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 11, length 64
08:41:53.230977 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 12, length 64
08:41:53.231058 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 12, length 64
08:41:54.401043 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 13, length 64
08:41:54.401127 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 13, length 64
08:41:55.221117 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 14, length 64
08:41:55.221200 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 14, length 64
08:41:56.240834 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 15, length 64
08:41:56.240914 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 15, length 64
08:41:57.240784 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 16, length 64
08:41:57.240890 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 16, length 64
^C
28 packets captured
28 packets received by filter
0 packets dropped by kernel