Tại sao Ubuntu không thể truy cập Raspberry Pi của tôi trên mạng LAN?

Được rồi, gần đây tôi đã có Raspberry Pi và tôi đã kết nối nó với Wi-Fi của mình - Tôi đã bật SSH và cài đặt Hiawatha và tôi có thể truy cập nó tốt từ Máy tính để bàn của tôi, lúc đó đang chạy Puppy Linux.

Tôi cũng có thể truy cập nó tốt khi khởi động vào Windows (PuTTY trên Win XP Pro,) và Netbook cũng có thể truy cập nó thông qua PuTTY. (Giành chiến thắng 7)

Tuy nhiên, khi tôi khởi động vào Ubuntu, tất cả các kết nối SSH, HTTP và HTTPS đều bị từ chối. Để xác nhận rằng đó là Ubuntu và chỉ Ubuntu, có vấn đề về kết nối, tôi đã khởi động lại vào Puppy Linux - được kết nối tốt và vào Windows - được kết nối tốt. Netbook có thể kết nối với cả 3 dịch vụ mà không gặp vấn đề gì. Chỉ có Ubuntu nói rằng kết nối đã từ chối.

Tôi muốn biết điều gì sai - Tôi đã thực hiện tất cả các khắc phục sự cố cơ bản: khởi động lại RPi, khởi động lại máy tính của tôi, khởi động lại bộ định tuyến không dây, v.v. Raspberry Pi không bật Tường lửa và Bộ định tuyến của tôi cung cấp tất cả các thiết bị được kết nối với LAN không giới hạn truy cập lẫn nhau. Tôi đã thực hiện thử nghiệm rộng rãi và Ubuntu đã được chứng minh vượt ra khỏi sự nghi ngờ là người duy nhất không sẵn sàng kết nối.

CẬP NHẬT: Chỉ cần thử nghiệm truy cập qua IP bên ngoài của tôi và mọi thứ đều chạy trơn tru trên Ubuntu! Tuy nhiên, Ubuntu vẫn không thể truy cập Pi từ bất kỳ địa phương nào và tôi chỉ xác nhận lại rằng hệ điều hành khác của tôi có thể . Tôi nghĩ thật kỳ lạ khi Ubuntu gặp sự cố khi kết nối cục bộ (không giống như các hệ điều hành khác của tôi), nhưng việc truy cập Pi thông qua IP bên ngoài của tôi vẫn ổn.

UPDATE 2: Vô hiệu hóa tường lửa của tôi cho phép tôi truy cập vào thiết bị này, nhưng báo cáo mật khẩu như không chính xác mỗi . độc thân . thời gian . Tôi đã thử nhập nó vào Gedit, sau đó kéo và thả nó vào dấu nhắc mật khẩu trong khi đăng nhập SSH và nó cho phép khi truy cập pi@jamestheawesomedude.cu.cc, nhưng KHÔNG khi truy cập pi@192.168.2.128. Điều này là không thể tin được bực bội.

Vì vậy, cho đến khi bạn đã ufwbật cài đặt mặc định trên máy Ubuntu, kết nối luôn được báo cáo Connection refused. Sau khi bạn vô hiệu hóa ufwứng dụng khách của bạn, kết nối được thiết lập nhưng mật khẩu luôn bị từ chối?

Tôi đoán trong trường hợp đó, vấn đề của bạn là 192.168.2.128ip được chuyển trở lại máy khách Ubuntu của bạn và thực sự bạn đang kết nối với sshmáy chủ đang chạy trên máy Ubuntu của bạn. Điều này sẽ giải thích:

• Tại sao bạn có thể kết nối từ internet.

• Tại sao kết nối của bạn bị từ chối khi bật tường lửa trên máy khách Ubuntu của bạn.

• Tại sao kết nối không bị từ chối với tường lửa máy khách bị tắt.

• Tại sao bây giờ kết nối được thiết lập, nhưng xác thực thất bại.

Để khắc phục sự cố này:

• Kiểm tra khóa máy chủ của máy chủ với ssh -v pi@192.168.2.128cả cục bộ và kết nối internet. Nó báo cáo cùng một khóa?

• Hoặc trong khi bạn đang kết nối từ cục bộ và bạn đang ở dấu nhắc nhập mật khẩu của mình, từ một thiết bị đầu cuối khác: sudo netstat -tupanvà xem liệu kết nối có được thiết lập với sshdUbuntu không.

Mặc dù trường hợp này sẽ giải thích mọi thứ, nhưng thật kỳ lạ khi tôi nghi ngờ rằng đây là vấn đề của bạn.

Hoàn toàn có khả năng máy Ubuntu của bạn đang nhận được một địa chỉ IP mạng khác với những gì được mong đợi. Hãy thử như sau:

• Trên raspi, kiểm tra địa chỉ IP của nó với ifconfig | grep 192.168
• trên máy ubfox, kiểm tra địa chỉ IP của nó với ifconfig | grep 192.168

Để có thể nói chuyện với nhau trên mạng cục bộ của bạn, cả hai nên sử dụng cùng một mạng con - hãy xem phần thứ ba của địa chỉ IP để xem chúng có đúng không. Trong trường hợp của bạn, cả hai nên nằm trên mạng con 192.168.2. *.

Hãy chắc chắn rằng họ thực sự có địa chỉ IP khác nhau quá. Điều này có vẻ rõ ràng, nhưng có thể xảy ra nếu một trong số họ đang sử dụng DHCP và cái còn lại được đặt tĩnh.

Nếu tất cả đã kiểm tra xong, thì hãy chạy lệnh sau để xem các gói tin của bạn sẽ đi đâu:

route -n

Nhìn vào đầu ra cho mạng con đích áp dụng cho pi mâm xôi của bạn. Thực sự chỉ nên có 3 hàng:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0

Nếu bạn có nhiều hàng hơn hoặc mọi thứ sẽ đến những điểm kỳ lạ, thì đó là câu trả lời.

Tôi đoán là kết nối ssh của bạn cuối cùng đã đánh một máy chủ SSH khác với máy chủ trên raspberry pi của bạn, đó là lý do tại sao việc thay đổi tường lửa ubfox ảnh hưởng đến nó và thông tin đăng nhập của bạn không hoạt động.

Theo những gì trong PasteBin của bạn, "kết nối bị từ chối" cho biết bạn đang thiết lập lại TCP từ bất cứ thứ gì có tại địa chỉ IP đó.

Kiểm tra vệ sinh: Trong khi xử lý sự cố, DISABLE ufw.

Với tường lửa máy tính để bàn của bạn bị vô hiệu hóa, bạn có thể ping Pi từ máy tính để bàn của bạn không? Bạn có thể ping máy tính để bàn từ Pi của bạn?

Sau khi thử ping theo cả hai hướng, hãy xem đầu ra của 'arp -n' trên cả hai máy. Họ có nhìn thấy địa chỉ MAC (phần cứng Ethernet) của nhau không hoặc là thứ gì đó đang chuyển hướng / chặn lưu lượng?

Nếu bạn có thể ping theo cả hai hướng và 'arp -n' cho biết các địa chỉ MAC thích hợp đang được sử dụng (kiểm tra 'ifconfig' trên máy đối diện), bước tiếp theo là kiểm tra /var/log/auth.log trên Pi. Nó sẽ cho bạn biết những gì sai với nỗ lực kết nối.

Nếu cách trên không có ích, vui lòng chỉ cho chúng tôi đầu ra từ các lệnh sau trên Pi:

sudo ifconfig -a
cat /etc/resolv.conf
arp -n
netstat -rn
sudo iptables-save
sudo grep ssh /var/log/auth.log | tail -50

Và trên máy tính để bàn của bạn:

sudo ifconfig -a
cat /etc/resolv.conf
arp -n
netstat -rn
sudo iptables-save

Tôi thấy một số điều này được dán trong các ý kiến ​​trên, nhưng toàn bộ điều quan trọng là phải lấy tường lửa ra, trước tiên. Nếu bạn có thể làm cho nó hoạt động với tường lửa tắt, thì bạn có thể tiến hành khắc phục sự cố các quy tắc tường lửa của mình.

Ngoài ra, ngay cả khi bạn đang nhắm mục tiêu địa chỉ IP, cài đặt DNS vẫn có vấn đề vì SSH sử dụng DNS trong quá trình xác thực khóa máy chủ.

Xóa ~/.ssh/known_hoststập tin và thử lại. Nếu trước đây có một máy chủ có cùng địa chỉ IP ssh có thể truy cập, bạn có thể giữ dấu vân tay không hợp lệ

Trên Ubuntu 13.10, tôi không thể ssh với pi của mình, khi trước đó tôi có thể vào 13.04 và Mint 16. Khi thử

ssh -vvv user@host

Tôi đã nhận :

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

Tôi đã chạy qua một đề nghị cho biết đặt MTU cho Máy (không phải pi) thành 1200 thay vì tự động. Tôi đã làm điều này, tắt -> sau đó trên wifi của tôi và kết nối với ssh với PI trong lần thử đầu tiên. Hy vọng điều này sẽ giúp được ai đó.