Tham gia Đăng nhập
Điểm:2
Micah Henning avatar Server

Không thể SSH sang giao diện mạng thứ hai trong Ubuntu 20.04 trên EC2

lá cờ br
Micah Henning

Tôi có một VPC 10.0.0.0/16 với một cổng Internet và hai mạng con 10.0.100.0/24 và 10.0.200.0/24 trong cùng một vùng khả dụng. Một nhóm bảo mật duy nhất cho phép tcp/22 đến từ 0.0.0.0/0 và mọi thứ bên ngoài. Tôi cũng có hai giao diện mạng được liên kết với nhóm bảo mật, một giao diện trong mỗi mạng con. Mỗi giao diện mạng có địa chỉ IP đàn hồi riêng. Có một bảng định tuyến cho mỗi điểm mạng con 0.0.0.0/0 đến cổng Internet.

Đây là vấn đề tôi đang gặp phải: Tôi có một phiên bản EC2 được ghép nối với cả hai giao diện mạng, nhưng chỉ có thể SSH từ Internet thông qua giao diện được ghép nối với eth0.

Đây là cấu hình:

$ uname -a
Linux ip-10-0-100-70 5.4.0-1045-aws #47-Ubuntu SMP Thứ ba ngày 13 tháng 4 07:02:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ip một
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 trạng thái qdisc noqueue nhóm UNKNOWN mặc định qlen 1000
    liên kết/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    máy chủ phạm vi inet 127.0.0.1/8 lo
       hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
    inet6 ::1/128 máy chủ phạm vi 
       hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 trạng thái qdisc fq_codel UP nhóm mặc định qlen 1000
    liên kết/ether 02:88:59:6e:78:c0 brd ff:ff:ff:ff:ff:ff
    inet 10.0.100.70/24 brd 10.0.100.255 phạm vi động toàn cầu eth0
       hợp lệ_lft 1806 giây ưa thích_lft 1806 giây
    liên kết phạm vi inet6 fe80::88:59ff:fe6e:78c0/64 
       hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc trạng thái fq_codel UP nhóm mặc định qlen 1000
    liên kết/ether 02:7d:b2:d4:b5:ea brd ff:ff:ff:ff:ff:ff
    inet 10.0.200.118/24 brd 10.0.200.255 phạm vi động toàn cầu eth1
       hợp lệ_lft 1807 giây ưa thích_lft 1807 giây
    liên kết phạm vi inet6 fe80::7d:b2ff:fed4:b5ea/64 
       hợp lệ_lft mãi mãi ưa thích_lft mãi mãi

tuyến đường $ ip
mặc định qua 10.0.100.1 dev eth0 proto dhcp src 10.0.100.70 số liệu 100 
mặc định qua 10.0.200.1 dev eth1 proto dhcp src 10.0.200.118 số liệu 200 
10.0.200.0/24 dev eth1 liên kết phạm vi kernel proto src 10.0.200.118 
10.0.200.1 dev eth1 liên kết phạm vi proto dhcp src 10.0.200.118 số liệu 200 
10.0.100.0/24 dev eth0 liên kết phạm vi kernel proto src 10.0.100.70 
10.0.100.1 dev eth0 liên kết phạm vi proto dhcp src 10.0.100.70 số liệu 100

quy tắc $ ip
0: từ tất cả tra cứu cục bộ
32766: từ tất cả tra cứu chính
32767: từ tất cả tra cứu mặc định

$ sudo ufw trạng thái dài dòng
Tình trạng: không hoạt động

$ ss -nlput
Netid State Recv-Q Send-Q Địa chỉ cục bộ:Địa chỉ ngang hàng cổng:Quá trình cổng   
udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:*                
udp UNCONN 0 0 10.0.200.118%eth1:68 0.0.0.0:*                
udp UNCONN 0 0 10.0.100.70%eth0:68 0.0.0.0:*                
tcp NGHE 0 4096 127.0.0.53%lo:53 0.0.0.0:*                
tcp NGHE 0 128 0.0.0.0:22 0.0.0.0:*                
tcp NGHE 0 128 [::]:22 [::]:*

Vì vậy, có vẻ như các giao diện mạng được định cấu hình đúng cách và daemon SSH đang lắng nghe trên tất cả các giao diện. Trình nền SSH đang hoạt động bình thường vì tôi đã kết nối qua SSH với eth0. Và cả hai giao diện dường như chuyển lưu lượng truy cập Internet tốt:

$ ping -I eth0 -c 5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) từ 10.0.100.70 eth0: 56(84) byte dữ liệu.
64 byte từ 1.1.1.1: icmp_seq=1 ttl=38 time=11,5 ms
64 byte từ 1.1.1.1: icmp_seq=2 ttl=38 time=11,5 ms
64 byte từ 1.1.1.1: icmp_seq=3 ttl=38 time=11,5 ms
64 byte từ 1.1.1.1: icmp_seq=4 ttl=38 time=11,6 ms
64 byte từ 1.1.1.1: icmp_seq=5 ttl=38 time=11,5 ms

--- 1.1.1.1 thống kê ping ---
Truyền 5 gói, nhận 5 gói, mất gói 0%, thời gian 4007ms
rtt tối thiểu/trung bình/tối đa/mdev = 11.470/11.515/11.567/0.031 ms

$ ping -I eth1 -c 5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) từ 10.0.200.118 eth1: 56(84) byte dữ liệu.
64 byte từ 1.1.1.1: icmp_seq=1 ttl=38 time=11,7 ms
64 byte từ 1.1.1.1: icmp_seq=2 ttl=38 time=11,8 ms
64 byte từ 1.1.1.1: icmp_seq=3 ttl=38 time=11,7 ms
64 byte từ 1.1.1.1: icmp_seq=4 ttl=38 time=11,8 ms
64 byte từ 1.1.1.1: icmp_seq=5 ttl=38 time=11,8 ms

--- 1.1.1.1 thống kê ping ---
Truyền 5 gói, nhận 5 gói, mất gói 0%, thời gian 4008ms
rtt tối thiểu/trung bình/tối đa/mdev = 11,705/11,755/11,829/0,042 ms

Nhưng không thể kết nối:

$ ssh -i ~/.ssh/cert.pem ubuntu@3.<redacted> # EIP cho eth0
Chào mừng bạn đến với Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-1045-aws x86_64)
...

$ ssh -i ~/.ssh/cert.pem ubuntu@52.<redacted> # EIP cho eth1
ssh: kết nối với máy chủ 52.<redacted> cổng 22: Đã hết thời gian thao tác

Tôi thiết lập Netflow trên eth1 bộ điều hợp mạng trong AWS và có thể xem lưu lượng:

2 840416055907 eni-07cc18b6f1b89378e <đã biên tập lại> 10.0.200.118 54268 22 6 9 576 1623280724 1623280761 CHẤP NHẬN

Vì vậy, tôi cảm thấy như hệ điều hành đang giảm lưu lượng. Nhưng không có tường lửa nào được định cấu hình và trình nền SSH đang lắng nghe trên tất cả các giao diện. Tôi cũng đã thử theo dõi nhật ký /var/log/{syslog,auth.log,kern.log} và dmesg, nhưng không có gì xuất hiện trong bất kỳ nhật ký nào trong số chúng khi tôi cố gắng kết nối.

Tôi hy vọng tôi đang thiếu một cái gì đó dễ dàng bởi vì tôi đang có một chút mất mát ngay bây giờ. Bất kỳ trợ giúp sẽ được rất đánh giá cao!

1270
1 + 3
A.B avatar
lá cờ cl
A.B
Bạn nói "Có bảng ** định tuyến ** cho mỗi mạng con trỏ `0.0.0.0/0` tới cổng Internet." . Trong các kết xuất cấu hình mạng của bạn, không có bất kỳ bảng định tuyến bổ sung nào cũng như bất kỳ quy tắc định tuyến bổ sung nào trỏ đến các bảng định tuyến này. Vì vậy, bạn có thể làm rõ ý của mình với "Có một bảng định tuyến cho mỗi mạng con ..." không? Bảng định tuyến không phải là một tuyến đường (mục nhập). Và multi-homing chính xác cần có bảng và quy tắc
0
Hồi đáp
Micah Henning avatar
lá cờ br
Micah Henning
Cảm ơn bạn đã trả lời @A.B. Bảng định tuyến được xác định trong AWS để lưu lượng đi ra từ phiên bản EC2 có thể tìm thấy cổng Internet.
0
Hồi đáp
A.B avatar
lá cờ cl
A.B
Vì sshd không có tùy chọn -I như ping để khóa định tuyến đến một giao diện, tôi e rằng bạn sẽ gặp sự cố định tuyến trên phiên bản của mình. Chỉ tuyến mặc định đầu tiên hoạt động, tuyến thứ 2 không có tác dụng đối với sshd.
1
Hồi đáp
Điểm:0
Micah Henning avatar Server
lá cờ br
Micah Henning

Lưu lượng truy cập từ eth1 cần được cấu hình để định tuyến đúng cách:

$ quy tắc ip sudo thêm từ bảng 10.0.200.118 mặc định
$ Sudo ip route thêm mặc định qua 10.0.200.1 dev eth1 bảng mặc định
$ Sudo ip xóa bộ nhớ cache

Vì chúng tôi không muốn phải SSH thủ công vào phiên bản để nhập các lệnh này, nên tôi đã tạo một tập lệnh systemd để thực thi khi khởi động.

/home/ubuntu/dual-home.sh

#!/bin/bash

ADDR=$(ip -f inet addr show eth1 | sed -En -e 's/.*inet ([0-9.]+).*/\1/p')
GATEWAY=$(echo $ADDR | sed -En -e 's/(([0-9]+\.){3}).*/\11/p') # giả định /24 mặt nạ
quy tắc sudo ip thêm từ bảng $ADDR mặc định
Sudo ip route thêm mặc định thông qua bảng $GATEWAY dev eth1 mặc định
Sudo ip route xóa bộ nhớ cache

/etc/systemd/system/dual-home.service

[Đơn vị]
Mô tả=Cấu hình định tuyến eth1
Sau=mạng.mục tiêu
Sau=cloud-final.service

[Dịch vụ]
Loại = đơn giản
ExecStart=/bin/bash /home/ubuntu/dual-home.sh

[Cài đặt]
WantedBy=cloud-init.target

Sau đó kích hoạt dịch vụ: $ Sudo systemctl kích hoạt nhà kép

0 + 0
lá cờ VietNam
Phan Văn Trường
Câu hỏi này là trong các ngôn ngữ khác:

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.