Перейти к содержанию

Рекомендуемые сообщения

  • Ответов 2,5 тыс
  • Создана
  • Последний ответ

Топ авторов темы

Опубликовано
On 12/21/2023 at 5:28 PM, Alexey77 said:

попробуйте поставить версию 1.8.4 вместо 1.8.6 

Хм, причём на сервере 1.8.6. Только сейчас глянул ))

Опубликовано (изменено)

Товарищи, кто-то настраивал xray клиент на другой машине и перенаправлял трафик на неё с минимальными потерями в скорости?

У меня есть KN-1011, прошивка 4.1 Beta 2

  • Ставил xkeen на роутер и проц долбится в сотку уже на ~30 мбит/с, как с использованием встроенного SOCKS в вебе, так и через REDIRECT правила (dokodemo-door в конфиге). Судя по htop, скорость упирается в сам xray клиент.
  • Поставил xray клиент на 4-ую Raspberry, перенаправлял трафик с помощью встроенных клиентов SOCKS и WireGuard. На SOCKS получилось максимум 40 мбит/с, а через WireGuard, на удивление, максимум 70 мбит/с.
  • Выполнял команду

    interface Proxy0 proxy socks5-udp

    Скорость так же режется.

Такие скорости меня не устраивают, тариф-то у меня 300 мбит/с, и прямое подключение к моему VPS через NekoBox тоже даёт 300 мбит/с. Скорость теряется даже если в правилах xray трафик идёт напрямую, не через VPS. Проблема исключительно в перенаправлении трафика с роутера на Raspberry. И это перенаправление ест много скорости.

Я ознакомился с TPROXY, но так и не понял, как правильно перенаправить. Получилось лишь полностью грохнуть интернет и доступ к роутеру, когда попробовал правила отсюда.


Мои вопросы таковы:

  • Как перенаправить трафик с помощью TPROXY на Raspberry? Есть ли примеры команд?
  • Обрежет ли TPROXY скорости так же, как делают встроенные SOCKS и WireGuard клиенты на кинетике?
  • Как использовать TPROXY вместе с политиками подключений? Имею в виду эти:
    Spoiler

    image.png.0f19efd263dd7cd26478a30127d710b0.png

  • Есть какие-то альтернативные варианты перенаправления? Какие-нибудь сторонние прокси клиенты на кинетик, которые так не обрезают скорость?

 

Вот мой xray конфиг на Raspberry для референса:

Spoiler
{
  "dns": {
    "disableFallback": true,
    "servers": [
      {
        "address": "https://8.8.8.8/dns-query",
        "domains": [],
        "queryStrategy": ""
      },
      {
        "address": "localhost",
        "domains": [],
        "queryStrategy": ""
      }
    ],
    "tag": "dns"
  },
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 2080,
      "protocol": "socks",
      "settings": {
        "udp": true
      },
      "sniffing": {
        "destOverride": [
          "http",
          "tls",
          "quic"
        ],
        "enabled": true,
        "metadataOnly": false,
        "routeOnly": true
      },
      "tag": "socks-in"
    },
    {
      "listen": "0.0.0.0",
      "port": 2081,
      "protocol": "http",
      "sniffing": {
        "destOverride": [
          "http",
          "tls",
          "quic"
        ],
        "enabled": true,
        "metadataOnly": false,
        "routeOnly": true
      },
      "tag": "http-in"
    },
    {
      "tag": "dokodemo-door",
      "port": 2082,
      "listen": "0.0.0.0",
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    },
    {
      "tag": "wgserver",
      "listen": "0.0.0.0",
      "port": 8888,
      "protocol": "wireguard",
      "settings": {
        "secretKey": "***",
        "peers": [
          {
            "publicKey": "***",
            "allowedIPs": [
              "192.168.6.0/24"
            ]
          }
        ],
        "kernelMode": false,
        "mtu": 1400
      }
    }
  ],
  "log": {
    "access": "/home/pi/Documents/xray/log/access.log",
    "error": "/home/pi/Documents/xray/log/error.log",
    "loglevel": "debug"
  },
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "domainStrategy": "AsIs",
      "flow": null,
      "settings": {
        "vnext": [
          {
            "address": "***",
            "port": 443,
            "users": [
              {
                "encryption": "none",
                "flow": "",
                "id": "***"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "fingerprint": "firefox",
          "publicKey": "***",
          "serverName": "google.com",
          "shortId": "***",
          "spiderX": "/"
        },
        "sockopt": {
          "mark": 2
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "domainStrategy": "",
      "streamSettings": {
        "sockopt": {
          "mark": 2
        }
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "streamSettings": {
        "sockopt": {
          "mark": 2
        }
      }
    },
    {
      "tag": "dns-out",
      "protocol": "dns",
      "proxySettings": {
        "tag": "proxy",
        "transportLayer": true
      },
      "settings": {
        "address": "8.8.8.8",
        "network": "tcp",
        "port": 53,
        "userLevel": 1
      },
      "streamSettings": {
        "sockopt": {
          "mark": 2
        }
      }
    }
  ],
  "policy": {
    "levels": {
      "1": {
        "connIdle": 30
      }
    },
    "system": {
      "statsOutboundDownlink": true,
      "statsOutboundUplink": true
    }
  },
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "inboundTag": [
          "socks-in",
          "http-in"
        ],
        "outboundTag": "dns-out",
        "port": "53",
        "type": "field"
      },
      {
        "outboundTag": "proxy",
        "port": "0-65535",
        "type": "field"
      }
    ]
  },
  "stats": {}
}
Изменено пользователем beubasser
Опубликовано (изменено)
20 часов назад, beubasser сказал:

Товарищи, кто-то настраивал xray клиент на другой машине и перенаправлял трафик на неё с минимальными потерями в скорости?

У меня есть KN-1011, прошивка 4.1 Beta 2

  • Ставил xkeen на роутер и проц долбится в сотку уже на ~30 мбит/с, как с использованием встроенного SOCKS в вебе, так и через REDIRECT правила (dokodemo-door в конфиге). Судя по htop, скорость упирается в сам xray клиент.
  • Поставил xray клиент на 4-ую Raspberry, перенаправлял трафик с помощью встроенных клиентов SOCKS и WireGuard. На SOCKS получилось максимум 40 мбит/с, а через WireGuard, на удивление, максимум 70 мбит/с.
  • Выполнял команду

    interface Proxy0 proxy socks5-udp

    Скорость так же режется.

Такие скорости меня не устраивают, тариф-то у меня 300 мбит/с, и прямое подключение к моему VPS через NekoBox тоже даёт 300 мбит/с. Скорость теряется даже если в правилах xray трафик идёт напрямую, не через VPS. Проблема исключительно в перенаправлении трафика с роутера на Raspberry. И это перенаправление ест много скорости.

Я ознакомился с TPROXY, но так и не понял, как правильно перенаправить. Получилось лишь полностью грохнуть интернет и доступ к роутеру, когда попробовал правила отсюда.


Мои вопросы таковы:

  • Как перенаправить трафик с помощью TPROXY на Raspberry? Есть ли примеры команд?
  • Обрежет ли TPROXY скорости так же, как делают встроенные SOCKS и WireGuard клиенты на кинетике?
  • Как использовать TPROXY вместе с политиками подключений? Имею в виду эти:
      Показать содержимое

    image.png.0f19efd263dd7cd26478a30127d710b0.png

  • Есть какие-то альтернативные варианты перенаправления? Какие-нибудь сторонние прокси клиенты на кинетик, которые так не обрезают скорость?

 

Вот мой xray конфиг на Raspberry для референса:

  Показать содержимое
{
  "dns": {
    "disableFallback": true,
    "servers": [
      {
        "address": "https://8.8.8.8/dns-query",
        "domains": [],
        "queryStrategy": ""
      },
      {
        "address": "localhost",
        "domains": [],
        "queryStrategy": ""
      }
    ],
    "tag": "dns"
  },
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 2080,
      "protocol": "socks",
      "settings": {
        "udp": true
      },
      "sniffing": {
        "destOverride": [
          "http",
          "tls",
          "quic"
        ],
        "enabled": true,
        "metadataOnly": false,
        "routeOnly": true
      },
      "tag": "socks-in"
    },
    {
      "listen": "0.0.0.0",
      "port": 2081,
      "protocol": "http",
      "sniffing": {
        "destOverride": [
          "http",
          "tls",
          "quic"
        ],
        "enabled": true,
        "metadataOnly": false,
        "routeOnly": true
      },
      "tag": "http-in"
    },
    {
      "tag": "dokodemo-door",
      "port": 2082,
      "listen": "0.0.0.0",
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    },
    {
      "tag": "wgserver",
      "listen": "0.0.0.0",
      "port": 8888,
      "protocol": "wireguard",
      "settings": {
        "secretKey": "***",
        "peers": [
          {
            "publicKey": "***",
            "allowedIPs": [
              "192.168.6.0/24"
            ]
          }
        ],
        "kernelMode": false,
        "mtu": 1400
      }
    }
  ],
  "log": {
    "access": "/home/pi/Documents/xray/log/access.log",
    "error": "/home/pi/Documents/xray/log/error.log",
    "loglevel": "debug"
  },
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "domainStrategy": "AsIs",
      "flow": null,
      "settings": {
        "vnext": [
          {
            "address": "***",
            "port": 443,
            "users": [
              {
                "encryption": "none",
                "flow": "",
                "id": "***"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "fingerprint": "firefox",
          "publicKey": "***",
          "serverName": "google.com",
          "shortId": "***",
          "spiderX": "/"
        },
        "sockopt": {
          "mark": 2
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "domainStrategy": "",
      "streamSettings": {
        "sockopt": {
          "mark": 2
        }
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "streamSettings": {
        "sockopt": {
          "mark": 2
        }
      }
    },
    {
      "tag": "dns-out",
      "protocol": "dns",
      "proxySettings": {
        "tag": "proxy",
        "transportLayer": true
      },
      "settings": {
        "address": "8.8.8.8",
        "network": "tcp",
        "port": 53,
        "userLevel": 1
      },
      "streamSettings": {
        "sockopt": {
          "mark": 2
        }
      }
    }
  ],
  "policy": {
    "levels": {
      "1": {
        "connIdle": 30
      }
    },
    "system": {
      "statsOutboundDownlink": true,
      "statsOutboundUplink": true
    }
  },
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "inboundTag": [
          "socks-in",
          "http-in"
        ],
        "outboundTag": "dns-out",
        "port": "53",
        "type": "field"
      },
      {
        "outboundTag": "proxy",
        "port": "0-65535",
        "type": "field"
      }
    ]
  },
  "stats": {}
}

Доброго Вам дня!

Поддержки TProxy пока что нет в релизной версии Xkeen. В настоящий момент ведется работа над обновлением.
Для увеличения скорости рекомендую использовать метод Redirect + bbr на сервере.
Или можно выполнить полную оптимизацию именно сервера

Скрытый текст
echo "tcp_bbr" > /etc/modules-load.d/modules.conf
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
echo "net.core.rmem_max = 67108864" >> /etc/sysctl.conf
echo "net.core.wmem_max = 67108864" >> /etc/sysctl.conf
echo "net.core.netdev_max_backlog = 10000" >> /etc/sysctl.conf
echo "net.core.somaxconn = 4096" >> /etc/sysctl.conf
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf
echo "net.ipv4.tcp_fin_timeout = 30" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_time = 1200" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_probes = 5" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_intvl = 30" >> /etc/sysctl.conf
echo "net.ipv4.tcp_max_syn_backlog = 8192" >> /etc/sysctl.conf
echo "net.ipv4.tcp_max_tw_buckets = 5000" >> /etc/sysctl.conf
echo "net.ipv4.tcp_fastopen = 3" >> /etc/sysctl.conf
echo "net.ipv4.tcp_mem = 25600 51200 102400" >> /etc/sysctl.conf
echo "net.ipv4.udp_mem = 25600 51200 102400" >> /etc/sysctl.conf
echo "net.ipv4.tcp_rmem = 4096 87380 67108864" >> /etc/sysctl.conf
echo "net.ipv4.tcp_wmem = 4096 65536 67108864" >> /etc/sysctl.conf
echo "net.ipv4.tcp_mtu_probing = 1" >> /etc/sysctl.conf
echo "net.ipv4.tcp_slow_start_after_idle=0" >> /etc/sysctl.conf


Так же с самим конфигом тоже много проблем. 
Используйте просто ленивый конфиг для Redirect, наполнив своими данными от сервера.

Он как раз сделан для Reality.

Изменено пользователем Skrill0
Опубликовано

@Skrill0, приветствую!

А это точно надо?

2 часа назад, Skrill0 сказал:
echo "tcp_bbr" > /etc/modules-load.d/modules.conf

Современные ядра линукса, если не ошибаюсь, поддерживают модуль bbr из коробки.

Я использую почти такой же, как вашем сообщении твик sysctl.conf в Ubuntu 20, только без добавления tcp_bbr в modules.conf. Производительность сети отличная.

Опубликовано (изменено)

А кто-то может проконсультировать про дебагу Xray 1.8.6?

Периодически "залипает" сервер, т.е. коннект к нему есть, но никакие сайты через shadowsocks или vless не открываются. Несколько раз в день такое бывает. Залипоны по времени тоже рандомные, может залипуть на несколько часов, а может и на несколько минут.

Сам VPS при этом не виснет, все сайты спокойно резолвит. Нагрузки на виртулку нет никакой (1-2% CPU Load, 20% Mem).

Изменено пользователем surfuser
Опубликовано (изменено)

 

4 hours ago, Skrill0 said:

Доброго Вам дня!

Поддержки TProxy пока что нет в релизной версии Xkeen. В настоящий момент ведется работа над обновлением.
Для увеличения скорости рекомендую использовать метод Redirect + bbr на сервере.
Или можно выполнить полную оптимизацию именно сервера

  Reveal hidden contents
echo "tcp_bbr" > /etc/modules-load.d/modules.conf
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
echo "net.core.rmem_max = 67108864" >> /etc/sysctl.conf
echo "net.core.wmem_max = 67108864" >> /etc/sysctl.conf
echo "net.core.netdev_max_backlog = 10000" >> /etc/sysctl.conf
echo "net.core.somaxconn = 4096" >> /etc/sysctl.conf
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf
echo "net.ipv4.tcp_fin_timeout = 30" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_time = 1200" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_probes = 5" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_intvl = 30" >> /etc/sysctl.conf
echo "net.ipv4.tcp_max_syn_backlog = 8192" >> /etc/sysctl.conf
echo "net.ipv4.tcp_max_tw_buckets = 5000" >> /etc/sysctl.conf
echo "net.ipv4.tcp_fastopen = 3" >> /etc/sysctl.conf
echo "net.ipv4.tcp_mem = 25600 51200 102400" >> /etc/sysctl.conf
echo "net.ipv4.udp_mem = 25600 51200 102400" >> /etc/sysctl.conf
echo "net.ipv4.tcp_rmem = 4096 87380 67108864" >> /etc/sysctl.conf
echo "net.ipv4.tcp_wmem = 4096 65536 67108864" >> /etc/sysctl.conf
echo "net.ipv4.tcp_mtu_probing = 1" >> /etc/sysctl.conf
echo "net.ipv4.tcp_slow_start_after_idle=0" >> /etc/sysctl.conf


Так же с самим конфигом тоже много проблем. 
Используйте просто ленивый конфиг для Redirect, наполнив своими данными от сервера.

Он как раз сделан для Reality.

Добрый день. Спасибо за советы, но к сожалению, это не помогает. Всё снова упирается в слабый процессор роутера, который еле тянет работу xray.


Конфиг на роутере:

  • 07_inbounds.json:
    Spoiler
    {
      "inbounds": [
        {
          "listen": "192.168.1.1",
          "port": 54836,
          "protocol": "dokodemo-door",
          "settings": {
            "network": "tcp,udp",
            "followRedirect": true
          },
          "sniffing": {
            "enabled": true,
            "destOverride": [
              "http",
              "tls"
            ]
          },
          "tag": "socks-in"
        }
      ]
    }
    
  • 08_outbounds.json:
    Spoiler
    {
      "outbounds": [
        {
          "domainStrategy": "UseIPv4",
          "protocol": "vless",
          "settings": {
            "vnext": [
              {
                "address": "***",
                "port": 443,
                "users": [
                  {
                    "encryption": "none",
                    "flow": "xtls-rprx-vision",
                    "id": "***"
                  }
                ]
              }
            ]
          },
          "streamSettings": {
            "network": "tcp",
            "security": "reality",
            "realitySettings": {
              "publicKey": "***",
              "fingerprint": "firefox",
              "serverName": "google.com",
              "shortId": "***",
              "spiderX": "/"
            }
          },
          "tag": "proxy"
        },
        {
          "protocol": "freedom",
          "tag": "direct"
        },
        {
          "protocol": "blackhole",
          "tag": "block"
        }
      ]
    }

 

Конфиг на VPS:

  • Inbound:
    Spoiler

    image.thumb.png.0f91ddc12f4eeff627b2aa202e1a66c4.png

  • Клиент - роутер:
    Spoiler

    image.png.cb1a14b0bed7d1b05574a0ecf2ec7ab8.png

 

Твики на VPS:

Spoiler
root@inexpensive-pen:~# cat /etc/sysctl.conf
...
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.core.netdev_max_backlog = 10000
net.core.somaxconn = 4096
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_mem = 25600 51200 102400
net.ipv4.udp_mem = 25600 51200 102400
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_slow_start_after_idle=0

Neofetch на VPS:

Spoiler

image.png.50386cdfc85e4c7fc28bdfbeddfa4e8b.png

Лог запуска/остановки xkeen:

Spoiler

image.png.8cda0167b4e7d420779f30e2183d8325.png


Со всем этим, результаты получились такие (все тесты с xray без правил маршрутизации, весь трафик идёт через VPS без исключений):

  • Htop во время бездействия:
    Spoiler

    На роутере:
    image.thumb.png.74eb02b5c01b29c3b9d3235980840eff.png

    На raspberry:
    image.thumb.png.b0b5dd092acb81a14c911db2177898ef.png

  • Прямой тест без xray, скорость провайдера:
    Spoiler

    image.png.7efd7f1b9d51c5b8dc5a45d67b9b34e7.png

    Htop на роутере при тесте скачивания:

    image.thumb.png.9d61669c50735d71ef52c929decc23d0.png

  • Тест с xray через NekoBox Android, прямое подключение к VPS по его IP:
    Spoiler

    image.png.deb4357f26f1b5effeb6db513b3cd904.png

    Htop на роутере при тесте скачивания:

    image.thumb.png.3f288e976b489177c34c611b071a7194.png

  • Тест с xray через NekoBox Android, подключение к raspberry pi в локальной сети по SOCKS, на которой стоит xray клиент с outbound на мою VPS:
    Spoiler

    image.png.800908ba33bbbec0b6395444a36754f6.png

    Htop на роутере при тесте скачивания:
    image.thumb.png.bf71e2fa6a6fa068ead7fefe368877d6.png

    Htop на raspberry при тесте скачивания:

    image.thumb.png.e533bfad557db504b90534cc20b87c31.png

  • Тест с xray через NekoBox Android, подключение к raspberry pi в локальной сети по WireGuard inbound (MTU 1400), на которой стоит xray клиент с outbound на мою VPS:
    Spoiler

    image.png.b48dc456e2529c950148c734d677f3cf.png

    И я только тут понял, что WireGuard inbound в xray как раз и является ботлнеком, а не роутер. Фикса пока не нашёл.

    Htop на роутере при тесте скачивания:
    image.thumb.png.3183a314352c1d0968a3fc2c76a90195.png

    Htop на raspberry при тесте скачивания:image.thumb.png.1a836189f067f7d1d91fc7ba6954aa63.png

  • Тест с xkeen на роутере, REDIRECT, политика "xkeen" есть, клиент в неё занесён:
    Spoiler

    image.png.645d28cbf89500cf471d81b51d33fc2f.png

    Htop на роутере при тесте скачивания:
    image.thumb.png.4457547f9cfc6d43f08ee21ccebbae87.png

  • Тест с xray на raspberry, роутер подключается к raspberry по стоковому SOCKS5 из веб-интерфейса, предварительно выполнена команда interface Proxy0 proxy socks5-udp, создана политика "VPN" с приоритетом подключения к прокси, клиент в неё занесён:
    Spoiler

    image.png.c83e43fb26cfa587384c82f1d714bce3.png

    Htop на роутере при тесте скачивания:
    image.thumb.png.9bd0dd1ddaf5f7481b34adf86584674a.png

    (клиент SOCKS кинетика даже не утилизирует процессор полностью)

    Htop на raspberry при тесте скачивания:
    image.thumb.png.2495076e3f964652399caaf19f23580f.png

  • Тест с xray на raspberry, роутер подключается к raspberry по стоковому WireGuard из веб-интерфейса, создана политика "VPN" с приоритетом подключения к WG-туннелю, клиент в неё занесён:
    Spoiler

    image.png.fd9df7aa865077ef4b7a68c9e90545aa.png

    Htop на роутере при тесте скачивания:
    image.thumb.png.45b8676d7a1751e899ee8d31665a4a04.png

    Htop на raspberry при тесте скачивания:
    image.thumb.png.34047c0f2d570edb7cfa8d58045a20fa.png

 

В общем, выглядит печально. Но в документации v2fly я увидел какую-то конфигурацию, когда IP raspberry ставится как основной шлюз на клиентах. В нашем случае можно перевести кинетик в режим Relay и вписать туда IP raspberry, которая и будет заниматься маршрутизацией. Пока буду копать в эту сторону.

Spoiler

image.png.c72f9c926ac54963b685b1fd04a8937b.png

Изменено пользователем beubasser
Опубликовано
3 часа назад, jameszero сказал:

@Skrill0, приветствую!

А это точно надо?

Современные ядра линукса, если не ошибаюсь, поддерживают модуль bbr из коробки.

Я использую почти такой же, как вашем сообщении твик sysctl.conf в Ubuntu 20, только без добавления tcp_bbr в modules.conf. Производительность сети отличная.

Доброй Вам ночи!

Да, Вы правы. Но так как конфигурация общая, для избежания проблем решила включить в список.
Если команда

echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf

применяется без добавления tcp_bbr в modules.conf, то он и не нужен)
Цель просто переключиться на bbr.

Опубликовано
2 часа назад, beubasser сказал:

 

Добрый день. Спасибо за советы, но к сожалению, это не помогает. Всё снова упирается в слабый процессор роутера, который еле тянет работу xray.


Конфиг на роутере:

  • 07_inbounds.json:
      Показать содержимое
    {
      "inbounds": [
        {
          "listen": "192.168.1.1",
          "port": 54836,
          "protocol": "dokodemo-door",
          "settings": {
            "network": "tcp,udp",
            "followRedirect": true
          },
          "sniffing": {
            "enabled": true,
            "destOverride": [
              "http",
              "tls"
            ]
          },
          "tag": "socks-in"
        }
      ]
    }
    
  • 08_outbounds.json:
      Показать содержимое
    {
      "outbounds": [
        {
          "domainStrategy": "UseIPv4",
          "protocol": "vless",
          "settings": {
            "vnext": [
              {
                "address": "***",
                "port": 443,
                "users": [
                  {
                    "encryption": "none",
                    "flow": "xtls-rprx-vision",
                    "id": "***"
                  }
                ]
              }
            ]
          },
          "streamSettings": {
            "network": "tcp",
            "security": "reality",
            "realitySettings": {
              "publicKey": "***",
              "fingerprint": "firefox",
              "serverName": "google.com",
              "shortId": "***",
              "spiderX": "/"
            }
          },
          "tag": "proxy"
        },
        {
          "protocol": "freedom",
          "tag": "direct"
        },
        {
          "protocol": "blackhole",
          "tag": "block"
        }
      ]
    }

 

Конфиг на VPS:

  • Inbound:
      Показать содержимое

    image.thumb.png.0f91ddc12f4eeff627b2aa202e1a66c4.png

  • Клиент - роутер:
      Показать содержимое

    image.png.cb1a14b0bed7d1b05574a0ecf2ec7ab8.png

 

Твики на VPS:

  Показать содержимое
root@inexpensive-pen:~# cat /etc/sysctl.conf
...
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.core.netdev_max_backlog = 10000
net.core.somaxconn = 4096
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_mem = 25600 51200 102400
net.ipv4.udp_mem = 25600 51200 102400
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_slow_start_after_idle=0

Neofetch на VPS:

  Показать содержимое

image.png.50386cdfc85e4c7fc28bdfbeddfa4e8b.png

Лог запуска/остановки xkeen:

  Показать содержимое

image.png.8cda0167b4e7d420779f30e2183d8325.png


Со всем этим, результаты получились такие (все тесты с xray без правил маршрутизации, весь трафик идёт через VPS без исключений):

  • Htop во время бездействия:
      Показать содержимое

    На роутере:
    image.thumb.png.74eb02b5c01b29c3b9d3235980840eff.png

    На raspberry:
    image.thumb.png.b0b5dd092acb81a14c911db2177898ef.png

  • Прямой тест без xray, скорость провайдера:
      Скрыть содержимое

    image.png.7efd7f1b9d51c5b8dc5a45d67b9b34e7.png

    Htop на роутере при тесте скачивания:

    image.thumb.png.9d61669c50735d71ef52c929decc23d0.png

  • Тест с xray через NekoBox Android, прямое подключение к VPS по его IP:
      Показать содержимое

    image.png.deb4357f26f1b5effeb6db513b3cd904.png

    Htop на роутере при тесте скачивания:

    image.thumb.png.3f288e976b489177c34c611b071a7194.png

  • Тест с xray через NekoBox Android, подключение к raspberry pi в локальной сети по SOCKS, на которой стоит xray клиент с outbound на мою VPS:
      Показать содержимое

    image.png.800908ba33bbbec0b6395444a36754f6.png

    Htop на роутере при тесте скачивания:
    image.thumb.png.bf71e2fa6a6fa068ead7fefe368877d6.png

    Htop на raspberry при тесте скачивания:

    image.thumb.png.e533bfad557db504b90534cc20b87c31.png

  • Тест с xray через NekoBox Android, подключение к raspberry pi в локальной сети по WireGuard inbound (MTU 1400), на которой стоит xray клиент с outbound на мою VPS:
      Показать содержимое

    image.png.b48dc456e2529c950148c734d677f3cf.png

    И я только тут понял, что WireGuard inbound в xray как раз и является ботлнеком, а не роутер. Фикса пока не нашёл.

    Htop на роутере при тесте скачивания:
    image.thumb.png.3183a314352c1d0968a3fc2c76a90195.png

    Htop на raspberry при тесте скачивания:image.thumb.png.1a836189f067f7d1d91fc7ba6954aa63.png

  • Тест с xkeen на роутере, REDIRECT, политика "xkeen" есть, клиент в неё занесён:
      Показать содержимое

    image.png.645d28cbf89500cf471d81b51d33fc2f.png

    Htop на роутере при тесте скачивания:
    image.thumb.png.4457547f9cfc6d43f08ee21ccebbae87.png

  • Тест с xray на raspberry, роутер подключается к raspberry по стоковому SOCKS5 из веб-интерфейса, предварительно выполнена команда interface Proxy0 proxy socks5-udp, создана политика "VPN" с приоритетом подключения к прокси, клиент в неё занесён:
      Показать содержимое

    image.png.c83e43fb26cfa587384c82f1d714bce3.png

    Htop на роутере при тесте скачивания:
    image.thumb.png.9bd0dd1ddaf5f7481b34adf86584674a.png

    (клиент SOCKS кинетика даже не утилизирует процессор полностью)

    Htop на raspberry при тесте скачивания:
    image.thumb.png.2495076e3f964652399caaf19f23580f.png

  • Тест с xray на raspberry, роутер подключается к raspberry по стоковому WireGuard из веб-интерфейса, создана политика "VPN" с приоритетом подключения к WG-туннелю, клиент в неё занесён:
      Показать содержимое

    image.png.fd9df7aa865077ef4b7a68c9e90545aa.png

    Htop на роутере при тесте скачивания:
    image.thumb.png.45b8676d7a1751e899ee8d31665a4a04.png

    Htop на raspberry при тесте скачивания:
    image.thumb.png.34047c0f2d570edb7cfa8d58045a20fa.png

 

В общем, выглядит печально. Но в документации v2fly я увидел какую-то конфигурацию, когда IP raspberry ставится как основной шлюз на клиентах. В нашем случае можно перевести кинетик в режим Relay и вписать туда IP raspberry, которая и будет заниматься маршрутизацией. Пока буду копать в эту сторону.

  Показать содержимое

image.png.c72f9c926ac54963b685b1fd04a8937b.png

Если с Redirect Ваша скорость ~30мб, то TProxy будет иметь меньшую скорость на ~5%.
Также, в теме уже не раз запускали на том же Viva 1910 ядро Xray со скоростью ~100+ мб.

Опубликовано
3 часа назад, surfuser сказал:

А кто-то может проконсультировать про дебагу Xray 1.8.6?

Периодически "залипает" сервер, т.е. коннект к нему есть, но никакие сайты через shadowsocks или vless не открываются. Несколько раз в день такое бывает. Залипоны по времени тоже рандомные, может залипуть на несколько часов, а может и на несколько минут.

Сам VPS при этом не виснет, все сайты спокойно резолвит. Нагрузки на виртулку нет никакой (1-2% CPU Load, 20% Mem).

Доброй Вам ночи!

С 1.8.6 у некоторых пользователей аналогичные проблемы.
Рекомендую откатиться на 1.8.4.

Если обновлялись с него, то бекапы лежат в 

/opt/backups

 

Опубликовано (изменено)
11 hours ago, Skrill0 said:

в теме уже не раз запускали на том же Viva 1910 ядро Xray со скоростью ~100+ мб.

Что-то у меня на 1910 более 200 мбит выдаёт.

Только что попробовал - более 300 мбит, проц около 20-30%.

Изменено пользователем LDude
добавил
Опубликовано (изменено)

Skrill0 Огромнейшее вам спасибо за труды. Я настроил, VPN работает. Осталось только с роутингом разобраться.  Я правильно понимаю что вот так VPN должен работать только на instagram? 

 

Скрытый текст


1.png

2.png

 

Изменено пользователем madsen
Опубликовано
6 минут назад, madsen сказал:

Осталось только с роутингом разобраться.  Я правильно понимаю что вот так VPN должен работать только на instagram? 

1. Политика для xray должна называться xkeen, а не как-то иначе.

2. У Вас всё кроме instagram идёт на proxy, а instagram на direct, то есть мимо proxy. То есть всё наоборот.

Опубликовано (изменено)
1 час назад, Marassa сказал:

2. У Вас всё кроме instagram идёт на proxy, а instagram на direct, то есть мимо proxy. То есть всё наоборот.

Да, точно. Всё получилось, я тупил

 

Изменено пользователем madsen
Опубликовано

Всем привет! Подскажите пожалуйста, почему со стороны сервера (при условии корректного подключения в redirect-режиме) может спамить такой ошибкой? Тега нигде не нахожу. При этом общей работоспособности вроде как не мешает.
 

2023/12/27 12:34:37 WARNING - XRAY: [1421492819] app/dispatcher: non existing outTag: IPv4

 

Опубликовано

Всем большой привет! Подскажите, такой вот вопрос: можно ли маскировать весь трафик под определенных домен. К примеру kion.ru. При использовании данного сервиса лимит мобильного трафика на МТС не уменьшается. В связи с этим и возник данный вопрос.

Заранее спасибо за ответ!

Опубликовано
1 час назад, LPA сказал:

Всем большой привет! Подскажите, такой вот вопрос: можно ли маскировать весь трафик под определенных домен. К примеру kion.ru. При использовании данного сервиса лимит мобильного трафика на МТС не уменьшается. В связи с этим и возник данный вопрос.

Заранее спасибо за ответ!

И Вам доброго вечера!

Да, Reality как раз лучше всех других методов справляется с этой задачей.
Если хотите не использовать индивидуальную маршрутизацию, то можно в 10_routing просто направить все на прокси. И весь трафик будет маскироваться под выбранное Вами доменное имя.

Опубликовано
3 hours ago, LPA said:

При использовании данного сервиса лимит мобильного трафика на МТС не уменьшается.

Вы хотите через Keenetic взять инет от МТС через 4G? Напишите, получится ли их обмануть таким образом, интересно.

Опубликовано (изменено)
14 часа назад, LDude сказал:

Вы хотите через Keenetic взять инет от МТС через 4G? Напишите, получится ли их обмануть таким образом, интересно.

Доброго Вам вечера!

Да, это вполне рабочий метод получения бесплатного интернета на мобильной связи.
Нужно выбрать сервис, для которого Ваш провайдер предоставляет бесплатный интернет и заменить ServerName и Dest на соответствующий в настройках Xray.

Важно учитывать, что подмена ServerName и Dest будет осуществляться только для проксируемого на VPS соединения.
То есть Direct будет расходовать трафик.

Если оперируете большими объемами трафика, то рекомендую выбирать именно стриминговые сервисы, такие как Rutube | YouTube | VK …

Изменено пользователем Skrill0
Опубликовано
12 часа назад, Skrill0 сказал:

Нужно выбрать сервис, для которого Ваш провайдер предоставляет бесплатный интернет и заменить ServerName на соответствующий в настройках Xray.

@Skrill0, спасибо за ответ! Подскажите, так будет достаточно? За что отвечает и на что влияет параметр Dest. Первоначально было настроено на youtube в Dest и Server Names. Нужно ли менять и Dest?

image.png.2f7104cfd5f631c2a50e8021d861e040.png

Опубликовано
28 минут назад, LPA сказал:

@Skrill0, спасибо за ответ! Подскажите, так будет достаточно? За что отвечает и на что влияет параметр Dest. Первоначально было настроено на youtube в Dest и Server Names. Нужно ли менять и Dest?

image.png.2f7104cfd5f631c2a50e8021d861e040.png

Доброго Вам дня!

Dest и Server Names рекомендуется настраивать на однин сервис.
Dest — это адрес в формате domain:port, откуда получается сертификат SSL.

Server Name — это допустимые адреса для обращения к этому домену. 
К примеру, www.youtube.com и youtube.com — одинаково допустимые имена. 
В контексте настройки клиентов ядер прокси, скорее является одним из вариантов аутентификации пользователя.
Если Server Name не совпадет ни с одним из указанных в параметрах сервера — подключение отклониться.

Опубликовано (изменено)

После перезагрузки роутера не запускается xkeen, сценарий initrc- /opt/etc/init.d/rc.unslung.

Куда копать?

Изменено пользователем stalker-dm
Опубликовано
13 часа назад, Skrill0 сказал:

Важно учитывать, что подмена ServerName и Dest будет осуществляться только для проксируемого на VPS соединения.
То есть Direct будет расходовать трафик.

Здравствуйте! Интересует аналогичный вопрос, получение трафика через подмену на youtube.com. С настройками VPS все понятно, а что конкретно надо настроить в xkeen и в роутере, чтобы весь трафик лить через VPS? Не совсем это понял, если не сложно, поясните, пожалуйста.

Опубликовано
7 минут назад, stalker-dm сказал:

После перезагрузки роутера не запускается xkeen, сценарий initrc- /opt/etc/init.d/rc.unslung.

Куда копать?

Аналогично, никак не могу добиться автозапуска. Запускаю вручную после каждой перезагрузки. Присоединяюсь к вопросу.

 

Опубликовано
36 минут назад, Pawant сказал:

Здравствуйте! Интересует аналогичный вопрос, получение трафика через подмену на youtube.com. С настройками VPS все понятно, а что конкретно надо настроить в xkeen и в роутере, чтобы весь трафик лить через VPS? Не совсем это понял, если не сложно, поясните, пожалуйста.

Доброго Вам дня!

Вот конфигурация клиента, с направлением всего соединения на VPS

Скрытый текст
// Настройка маршрутизации

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      // Настройка черного списка
      {
        "inboundTag": ["socks-in"],
        "domain": [
          "ext:geosite_v2fly.dat:category-ads-all",
          "google-analytics",  // Могут быть проблемы с сервисами Google. Нужны тесты
          "analytics.yandex"  // Могут быть проблемы с сервисами Yandex. Нужны тесты
        ],
        "outboundTag": "block",
        "type": "field"
      },

      // Направление соединения на VPS
      {
        "inboundTag": ["socks-in"],
        "outboundTag": "proxy",
        "type": "field"
      }
    ]
  }
}

 

Опубликовано
45 минут назад, stalker-dm сказал:

После перезагрузки роутера не запускается xkeen, сценарий initrc- /opt/etc/init.d/rc.unslung.

37 минут назад, Pawant сказал:

Аналогично, никак не могу добиться автозапуска. Запускаю вручную после каждой перезагрузки. Присоединяюсь к вопросу.


Здравствуйте)

В файле S24Xray по пути

/opt/etc/init.d/


Попробуйте увеличить стартовую задержку автозапуска.
Для этого нужно изменить значение в переменной

initial_delay=2


2 — стоит по умолчанию. В тяжелых случаях помогает изменить время на 10 секунд.

Опубликовано
1 час назад, Skrill0 сказал:
initial_delay=2


2 — стоит по умолчанию. В тяжелых случаях помогает изменить время на 10 секунд.

Поставил 10, все равно не запускается после перезагрузки

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   1 пользователь онлайн

×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.