TCP chết trên máy tính xách tay Linux


17

Một lần trong vài ngày tôi có vấn đề sau. Máy tính xách tay của tôi (kiểm tra Debian) đột nhiên không thể hoạt động với các kết nối TCP với internet.

Những điều sau đây tiếp tục hoạt động tốt:

  • UDP (DNS), ICMP (ping) - Tôi nhận được phản hồi tức thì
  • Kết nối TCP đến các máy khác trong mạng cục bộ (ví dụ: tôi có thể ssh với máy tính xách tay hàng xóm)
  • mọi thứ đều ổn đối với các máy khác trong mạng LAN của tôi

Nhưng khi tôi thử các kết nối TCP từ máy tính xách tay của mình, chúng hết thời gian (không có phản hồi với các gói SYN). Đây là một đầu ra curl điển hình:

% curl -v google.com     
* About to connect() to google.com port 80 (#0)
*   Trying 173.194.39.105...
* Connection timed out
*   Trying 173.194.39.110...
* Connection timed out
*   Trying 173.194.39.97...
* Connection timed out
*   Trying 173.194.39.102...
* Timeout
*   Trying 173.194.39.98...
* Timeout
*   Trying 173.194.39.96...
* Timeout
*   Trying 173.194.39.103...
* Timeout
*   Trying 173.194.39.99...
* Timeout
*   Trying 173.194.39.101...
* Timeout
*   Trying 173.194.39.104...
* Timeout
*   Trying 173.194.39.100...
* Timeout
*   Trying 2a00:1450:400d:803::1009...
* Failed to connect to 2a00:1450:400d:803::1009: Network is unreachable
* Success
* couldn't connect to host
* Closing connection #0
curl: (7) Failed to connect to 2a00:1450:400d:803::1009: Network is unreachable

Khởi động lại kết nối và / hoặc tải lại mô-đun hạt nhân của card mạng không giúp ích gì. Điều duy nhất giúp là khởi động lại.

Rõ ràng có gì đó không ổn với hệ thống của tôi (mọi thứ khác đều hoạt động tốt), nhưng tôi không biết chính xác là gì.

Thiết lập của tôi là một bộ định tuyến không dây được kết nối với ISP thông qua PPPoE.

Có lời khuyên nào không?

Trả lời ý kiến

Nó là gì vậy?

12:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
  Subsystem: Dell Inspiron M5010 / XPS 8300
  Flags: bus master, fast devsel, latency 0, IRQ 17
  Memory at fbb00000 (64-bit, non-prefetchable) [size=16K]
  Capabilities: [40] Power Management version 3
  Capabilities: [58] Vendor Specific Information: Len=78 <?>
  Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
  Capabilities: [d0] Express Endpoint, MSI 00
  Capabilities: [100] Advanced Error Reporting
  Capabilities: [13c] Virtual Channel
  Capabilities: [160] Device Serial Number 00-00-9d-ff-ff-aa-1c-65
  Capabilities: [16c] Power Budgeting <?>
  Kernel driver in use: brcmsmac

Trạng thái của NIC của bạn khi sự cố xảy ra là gì?

iptables-save không in gì cả.

ip rule show:

0:  from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default 

ip route show table all:

default via 192.168.1.1 dev wlan0 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.105 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.1.0 dev wlan0  table local  proto kernel  scope link  src 192.168.1.105 
local 192.168.1.105 dev wlan0  table local  proto kernel  scope host  src 192.168.1.105 
broadcast 192.168.1.255 dev wlan0  table local  proto kernel  scope link  src 192.168.1.105 
fe80::/64 dev wlan0  proto kernel  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101 hoplimit 255
local ::1 via :: dev lo  table local  proto none  metric 0 
local fe80::1e65:9dff:feaa:b1f1 via :: dev lo  table local  proto none  metric 0 
ff00::/8 dev wlan0  table local  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101 hoplimit 255

Tất cả những điều trên đều giống nhau khi máy hoạt động ở chế độ bình thường.

ifconfig- Tôi đã chạy nó, nhưng bằng cách nào đó đã quên lưu trước khi khởi động lại. Sẽ phải đợi đến lần sau sự cố xảy ra. Xin lỗi vì điều đó.

Bất kỳ QoS tại chỗ?

Có lẽ là không - ít nhất là tôi chưa làm gì đặc biệt để kích hoạt nó.

Bạn đã thử đánh hơi lưu lượng truy cập thực sự được gửi trên giao diện chưa?

Tôi đã chạy curl và tcpdump nhiều lần, và có hai mẫu.

Đầu tiên chỉ là các gói SYN mà không có câu trả lời.

17:14:37.836917 IP (tos 0x0, ttl 64, id 4563, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42030 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0xbea8), seq 3764607647, win 13600, options [mss 1360,sackOK,TS val 33770316 ecr 0,nop,wscale 4], length 0
17:14:38.836650 IP (tos 0x0, ttl 64, id 4564, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42030 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0xbdae), seq 3764607647, win 13600, options [mss 1360,sackOK,TS val 33770566 ecr 0,nop,wscale 4], length 0
17:14:40.840649 IP (tos 0x0, ttl 64, id 4565, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42030 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0xbbb9), seq 3764607647, win 13600, options [mss 1360,sackOK,TS val 33771067 ecr 0,nop,wscale 4], length 0

Thứ hai là đây:

17:22:56.507827 IP (tos 0x0, ttl 64, id 41583, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42036 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0x2244), seq 1564709704, win 13600, options [mss 1360,sackOK,TS val 33894944 ecr 0,nop,wscale 4], length 0
17:22:56.546763 IP (tos 0x58, ttl 54, id 65442, offset 0, flags [none], proto TCP (6), length 60)
    fra07s07-in-f102.1e100.net.http > 192.168.1.105.42036: Flags [S.], cksum 0x6b1e (correct), seq 1407776542, ack 1564709705, win 14180, options [mss 1430,sackOK,TS val 3721836586 ecr 33883552,nop,wscale 6], length 0
17:22:56.546799 IP (tos 0x58, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.105.42036 > fra07s07-in-f102.1e100.net.http: Flags [R], cksum 0xf301 (correct), seq 1564709705, win 0, length 0
17:22:58.511843 IP (tos 0x0, ttl 64, id 41584, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42036 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0x204f), seq 1564709704, win 13600, options [mss 1360,sackOK,TS val 33895445 ecr 0,nop,wscale 4], length 0
17:22:58.555423 IP (tos 0x58, ttl 54, id 65443, offset 0, flags [none], proto TCP (6), length 60)
    fra07s07-in-f102.1e100.net.http > 192.168.1.105.42036: Flags [S.], cksum 0x3b03 (correct), seq 1439178112, ack 1564709705, win 14180, options [mss 1430,sackOK,TS val 3721838596 ecr 33883552,nop,wscale 6], length 0
17:22:58.555458 IP (tos 0x58, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.105.42036 > fra07s07-in-f102.1e100.net.http: Flags [R], cksum 0xf301 (correct), seq 1564709705, win 0, length 0

đầu ra ethtool

ethtool -k wlan0:

Features for wlan0:
rx-checksumming: off [fixed]
tx-checksumming: off
  tx-checksum-ipv4: off [fixed]
  tx-checksum-unneeded: off [fixed]
  tx-checksum-ip-generic: off [fixed]
  tx-checksum-ipv6: off [fixed]
  tx-checksum-fcoe-crc: off [fixed]
  tx-checksum-sctp: off [fixed]
scatter-gather: off
  tx-scatter-gather: off [fixed]
  tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
  tx-tcp-segmentation: off [fixed]
  tx-tcp-ecn-segmentation: off [fixed]
  tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: on [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]

iptables

# namei -l "$(command -v iptables)"
f: /sbin/iptables
drwxr-xr-x root root /
drwxr-xr-x root root sbin
lrwxrwxrwx root root iptables -> xtables-multi
-rwxr-xr-x root root   xtables-multi

# dpkg -S "$(command -v iptables)"
iptables: /sbin/iptables

# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
# iptables -t mangle -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
# iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
# iptables -t security -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

thông tin mô-đun

# ethtool -i wlan0                   
driver: brcmsmac
version: 3.2.0-3-686-pae
firmware-version: N/A
bus-info: 0000:12:00.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

# modinfo brcmsmac
filename:       /lib/modules/3.2.0-3-686-pae/kernel/drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko
license:        Dual BSD/GPL
description:    Broadcom 802.11n wireless LAN driver.
author:         Broadcom Corporation
alias:          pci:v000014E4d00000576sv*sd*bc*sc*i*
alias:          pci:v000014E4d00004727sv*sd*bc*sc*i*
alias:          pci:v000014E4d00004353sv*sd*bc*sc*i*
alias:          pci:v000014E4d00004357sv*sd*bc*sc*i*
depends:        mac80211,brcmutil,cfg80211,cordic,crc8
intree:         Y
vermagic:       3.2.0-3-686-pae SMP mod_unload modversions 686 

Không có /sys/module/brcmsmac/parameters. Đây là những gì tôi có ở đó:

# tree /sys/module/brcmsmac
/sys/module/brcmsmac
├── drivers
│   └── pci:brcmsmac -> ../../../bus/pci/drivers/brcmsmac
├── holders
├── initstate
├── notes
├── refcnt
├── sections
│   └── __bug_table
└── uevent

Một số trang web thực sự hoạt động

Theo đề xuất của dr , tôi đã thử một số trang web khác, và thật ngạc nhiên khi một số trong số chúng thực sự hoạt động. Dưới đây là một số máy chủ đã hoạt động:

  • rambler.ru
  • google.ru
  • ya.ru
  • opennet.ru
  • tut.by
  • ro-hoe.info
  • yahoo.com
  • ebay.com

Và đây là một số điều không được:

  • vk.com
  • meta.ua
  • ukr.net
  • nguyên lý.ua
  • vũ hội
  • reddit.com
  • github.com
  • stackexchange.com

Chụp mạng

Tôi đã thực hiện một chụp mạng và tải nó lên đây .


1
Chỉ bởi sự tò mò: Trạng thái của NIC của bạn khi sự cố xảy ra là gì? (/ sbin / ifconfig?)
yves Baume

Bạn đã thử đánh hơi lưu lượng truy cập thực sự được gửi trên giao diện (wireshark / tcpdump ...)? Nó là gì vậy? Có phải là không dây? Sản lượng của iptables-save, của ip rule show, ip route show table all. Bất kỳ QoS tại chỗ?
Stéphane Chazelas

Cập nhật bài viết với câu trả lời cho câu hỏi của bạn.
Roman Cheplyaka

1
Tôi đã không xây dựng trình điều khiển từ nguồn. Bản thân mô-đun xuất phát từ hạt nhân Debian (gói linux-image-3.2.0-3-686-pae) và phần sụn đến từ firmware-brcm80211gói. Bạn có vấn đề tương tự như của tôi? Tôi muốn tránh xây dựng công cụ bằng tay, trừ khi đó là một số vấn đề được biết đến. Ngoài ra, tại sao một vấn đề mô-đun NIC sẽ tự biểu hiện trên lớp 4?
Roman Cheplyaka

1
Nhiều khả năng bất cứ điều gì sai là trên trạm gốc, bộ chuyển mạch hoặc bộ định tuyến Wi-Fi của bạn. Nếu có thể hãy thử truy tìm các gói (hoặc số gói) ở đó. Nếu không, hãy thử hoán đổi chúng với các lựa chọn thay thế.
bahamat

Câu trả lời:


5

Trong bản chụp bạn đã cung cấp, Trả lời Dấu thời gian trong SYN-ACK trong gói thứ hai không khớp với TSVal trong SYN trong gói đầu tiên và chậm hơn vài giây.

Và hãy xem tất cả các TSecr được gửi bởi cả 173.194,70.108 và 209,85.148.100 đều giống nhau và không liên quan từ TSVal mà bạn gửi.

Dường như có gì đó hòa lẫn với dấu thời gian TCP. Tôi không biết điều gì có thể gây ra điều đó, nhưng có vẻ như nó nằm ngoài máy của bạn. Có phải khởi động lại bộ định tuyến trong trường hợp này?

Tôi không biết liệu đó có phải là nguyên nhân khiến máy của bạn gửi RST (trên gói thứ 3). Nhưng nó chắc chắn không giống như SYN-ACK đó, và đó là điều duy nhất tôi có thể tìm thấy về nó. Lời giải thích duy nhất khác mà tôi có thể nghĩ đến là nếu đó không phải là máy của bạn đang gửi RST nhưng do chênh lệch thời gian giữa SYN-ACK và RST tôi sẽ nghi ngờ như vậy. Nhưng chỉ trong trường hợp, bạn có sử dụng máy ảo hoặc thùng chứa hoặc không gian tên mạng trên máy này không?

Bạn có thể thử vô hiệu hóa dấu thời gian TCP hoàn toàn để xem có giúp được không:

sudo sysctl -w net.ipv4.tcp_timestamps=0

Vì vậy, các trang web đó gửi TSecr không có thật hoặc có một cái gì đó đang trên đường (bất kỳ bộ định tuyến nào trên đường đi hoặc proxy trong suốt) mang theo TSVal hoặc TSecr gửi đến hoặc proxy có ngăn xếp TCP không có thật. Tại sao người ta lại đọc các dấu thời gian tcp mà tôi chỉ có thể suy đoán: lỗi, trốn tránh phát hiện xâm nhập, thuật toán định hình lưu lượng truy cập quá thông minh / không có thật. Đó không phải là điều tôi đã nghe trước đây (nhưng sau đó tôi không phải là chuyên gia về chủ đề này).

Cách điều tra thêm:

  • Xem liệu bộ định tuyến TPLink có đổ lỗi tại sao đặt lại nó để xem liệu điều đó có giúp hoặc nắm bắt lưu lượng ở bên ngoài không nếu có thể để xem liệu nó có xáo trộn dấu thời gian không
  • Kiểm tra xem có một proxy trong suốt trên đường bằng cách chơi với TTL không, xem các tiêu đề yêu cầu mà máy chủ web nhận được hoặc xem hành vi khi yêu cầu các trang web chết.
  • nắm bắt lưu lượng truy cập trên một máy chủ web từ xa để xem đó là TSVal hoặc TSecr được xử lý.

Không, tôi không có vms / container nào đang chạy. Tôi sẽ thử đề xuất của bạn lần sau, cảm ơn.
Roman Cheplyaka

1
Xm .. Bạn đề nghị về tcp_timestamp chắc chắn giải quyết vấn đề của tôi. Không có vấn đề gì với google và trang web khác sau khi đặt net.ipv4.tcp_timestamp thành 0 và tất cả các vấn đề lại xảy ra trong trường hợp net.ipv4.tcp_timestamp = 1 nhưng TẠI SAO?
dr.

1

Nó nói tổng kiểm tra không chính xác ở trên. Có giảm tải tổng kiểm tra cho thiết bị đó không (tôi không biết các thiết bị không dây có thể giảm tải tổng kiểm tra).

Điều gì sudo ethtool -k wlan0nói với bạn. Nếu có giảm tải, bạn có thể muốn thử và vô hiệu hóa nó.

Bạn cần phải root để gọi iptables-save. Vẫn còn một số cơ hội từ xa rằng một cái gì đó đang xáo trộn các gói ở đó. Nếu iptables-savekhông hoạt động, hãy thử:

iptables -nvL
iptables -t mangle -nvL
iptables -t nat -nvL
iptables -t security -nvL

Trong chụp mạng của bạn, địa chỉ MAC đích có khớp với địa chỉ của bộ định tuyến không. Có gì thú vị khi so sánh từ lưu lượng UDP với lưu lượng TCP không?

Ngoài ra, $devtrình điều khiển hạt nhân (mô-đun) (xem ethtool -i wlan0) cho bộ điều hợp không dây của bạn ở đâu, làm gì modinfo "$dev"grep . /sys/module/"$dev"/parameters/*cho bạn biết?


Nắm bắt tốt! Tôi đã không nhận thấy tổng kiểm tra sai. Tôi sẽ cập nhật câu trả lời với đầu ra ethtool. iptables-save được chạy dưới quyền root, không in gì cả. Lần sau tôi sẽ chạy lại tcpdump để hiển thị địa chỉ MAC.
Roman Cheplyaka

Nếu iptables-save trả về không có gì, thì chắc chắn có điều gì đó không ổn. Làm gì namei -l "$(command -v iptables)"dpkg -S "$(command -v iptables)"nói với bạn?
Stéphane Chazelas

Đăng đầu ra.
Roman Cheplyaka

Cập nhật bài viết với thông tin mô-đun.
Roman Cheplyaka

Cảm ơn. Xem các chỉnh sửa của tôi để trả lời của tôi. Bạn cũng có thể dán một pcap để chụp ở đâu đó, hoặc có thể là đầu ra của tshark -Viwlan0 tcpmột trong những gói SYN ở đây không?
Stéphane Chazelas

1

Có vẻ như, tôi cũng có hành vi tương tự ở máy tính xách tay của mình. Tôi không biết lý do, nhưng thỉnh thoảng tôi không thể kết nối với google.com và một số tài nguyên bên ngoài khác. Truy vấn ping và DNS hoạt động hoàn hảo. Ngoài ra, tôi chỉ tìm thấy một giải pháp: khởi động lại .

Tôi có thể thêm một số quan sát:

  1. Nếu tôi khởi động một số HĐH khác trong Hộp ảo của mình (Windows, ArchLinux, Ubuntu), tôi có thể thiết lập kết nối TCP với máy chủ có vấn đề mà không gặp sự cố nào.
  2. Một số máy chủ lưu trữ trên Internet hoạt động như google.com, nhưng có rất nhiều trong số chúng, thường có thể truy cập bằng telnet hoặc trình duyệt web
  3. Tôi không có bộ chuyển đổi WIFI trên máy tính xách tay của mình, tôi chỉ có liên kết Ethernet đến bộ định tuyến
  4. Tôi đã cố gắng chroot vào không gian người dùng debian / gentoo - không giúp được gì
  5. Tôi đã thay thế NIC của mình bằng cái mới - nó không giúp được gì

Một số thông tin kỹ thuật về hộp của tôi:

HĐH: Last ArchLinux amd64

$ ethtool -i  eth0
driver: via-rhine
version: 1.5.0
firmware-version: 
bus-info: 0000:02:07.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

$uname -a
Linux eniac-2 3.5.4-1-ARCH #1 SMP PREEMPT Sat Sep 15 08:12:04 CEST 2012 x86_64 GNU/Linux

Tôi cho rằng, hành vi lỗi này xảy ra do một số lỗi tinh vi trong một số phiên bản nhân Linux, nhưng tôi không biết cách gỡ lỗi vấn đề này và do việc sao chép không ổn định tôi bị mắc kẹt.


Cám ơn vì đã chia sẻ! Một số ví dụ về các máy chủ làm việc là gì?
Roman Cheplyaka

Ví dụ về máy chủ lưu trữ, hoạt động khi xảy ra hành vi lỗi này: opennet.ru, tut.by.
dr.

Bây giờ tôi tin chắc rằng chúng ta thực sự có cùng một vấn đề ...
Roman Cheplyaka

Vâng! Tôi đồng ý. Tôi đang suy nghĩ về việc cập nhật phần sụn cho bộ định tuyến của mình trên một cái gì đó như dd-wrt hoặc openwrt, hoặc chỉ hạ cấp kernel linux. Bạn đã thử bất kỳ bước nào trong số này chưa?
dr.

1
Không. Tôi rất muốn tìm hiểu những gì đang xảy ra ở đây.
Roman Cheplyaka

0
/sbin/iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Tôi đã có cùng một vấn đề mà bạn đã mô tả cho đến khi thêm lệnh trên vào các lệnh iptables cổng Internet của tôi. Trong được bao gồm theo mặc định trong gói rp-pppoe và những người khác. Nhưng khi bạn chọn cấu hình tùy chỉnh và không đặt thủ công, các máy tính trong mạng LAN phía sau cổng sẽ có các vấn đề bạn mô tả.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.