înregistrare Logare
Puncte:2
Micah Henning avatar Server

Nu se poate SSH la a doua interfață de rețea în Ubuntu 20.04 pe EC2

drapel br
Micah Henning

Am un VPC 10.0.0.0/16 cu un gateway de internet și două subrețele 10.0.100.0/24 și 10.0.200.0/24 în aceeași zonă de disponibilitate. Un singur grup de securitate permite tcp/22 inbound din 0.0.0.0/0 și totul în afară. De asemenea, am două interfețe de rețea legate de grupul de securitate, câte una în fiecare subrețea. Fiecare interfață de rețea are propria sa adresă IP elastică. Există un tabel de rutare pentru fiecare punctare subrețea 0.0.0.0/0 către gateway-ul de internet.

Iată problema cu care mă confrunt: am o instanță EC2 asociată cu ambele interfețe de rețea, dar pot doar SSH de pe Internet prin cea asociată cu eth0.

Aceasta este configurația:

$ uname -a
Linux ip-10-0-100-70 5.4.0-1045-aws #47-Ubuntu SMP Mar 13 Apr 07:02:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue stare UNKNOWN grup implicit 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 pentru totdeauna preferred_lft pentru totdeauna
    inet6 ::1/128 scope host 
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc fq_codel state UP group default qlen 1000
    link/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 scope global dynamic eth0
       valid_lft 1806sec preferred_lft 1806sec
    inet6 fe80::88:59ff:fe6e:78c0/64 scope link 
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc fq_codel state UP group default qlen 1000
    link/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 scope global dynamic eth1
       valid_lft 1807sec preferred_lft 1807sec
    inet6 fe80::7d:b2ff:fed4:b5ea/64 scope link 
       valid_lft pentru totdeauna preferred_lft pentru totdeauna

$ traseu ip
implicit prin 10.0.100.1 dev eth0 proto dhcp src 10.0.100.70 metric 100 
implicit prin 10.0.200.1 dev eth1 proto dhcp src 10.0.200.118 metric 200 
10.0.200.0/24 dev eth1 proto kernel scope link src 10.0.200.118 
10.0.200.1 dev eth1 proto dhcp scope link src 10.0.200.118 metric 200 
10.0.100.0/24 dev eth0 proto kernel scope link src 10.0.100.70 
10.0.100.1 dev eth0 proto dhcp scope link src 10.0.100.70 metric 100

regula $ ip
0: din toate căutările locale
32766: din toate căutările principale
32767: din toate căutările implicite

$ sudo ufw status verbose
Stare: inactiv

$ ss -nlput
Netid State Recv-Q Send-Q Adresă locală: Port Peer Address: Port Process   
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 ASCULTĂ 0 4096 127.0.0.53%lo:53 0.0.0.0:*                
tcp ASCULTĂ 0 128 0.0.0.0:22 0.0.0.0:*                
tcp ASCULTĂ 0 128 [::]:22 [::]:*

Deci, se pare că interfețele de rețea sunt configurate corect și că demonul SSH ascultă pe toate interfețele. Daemonul SSH funcționează corect deoarece sunt deja conectat prin SSH la eth0. Și ambele interfețe par să transmită foarte bine traficul către Internet:

$ ping -I eth0 -c 5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) de la 10.0.100.70 eth0: 56(84) octeți de date.
64 de octeți din 1.1.1.1: icmp_seq=1 ttl=38 timp=11,5 ms
64 de octeți din 1.1.1.1: icmp_seq=2 ttl=38 timp=11,5 ms
64 de octeți din 1.1.1.1: icmp_seq=3 ttl=38 timp=11,5 ms
64 de octeți din 1.1.1.1: icmp_seq=4 ttl=38 timp=11,6 ms
64 de octeți din 1.1.1.1: icmp_seq=5 ttl=38 timp=11,5 ms

--- 1.1.1.1 statistici ping ---
5 pachete transmise, 5 primite, 0% pierdere de pachete, timp 4007 ms
rtt min/avg/max/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) de la 10.0.200.118 eth1: 56(84) octeți de date.
64 de octeți din 1.1.1.1: icmp_seq=1 ttl=38 timp=11,7 ms
64 de octeți din 1.1.1.1: icmp_seq=2 ttl=38 timp=11,8 ms
64 de octeți din 1.1.1.1: icmp_seq=3 ttl=38 timp=11,7 ms
64 de octeți din 1.1.1.1: icmp_seq=4 ttl=38 timp=11,8 ms
64 de octeți din 1.1.1.1: icmp_seq=5 ttl=38 timp=11,8 ms

--- 1.1.1.1 statistici ping ---
5 pachete transmise, 5 primite, 0% pierdere de pachete, timp 4008 ms
rtt min/avg/max/mdev = 11,705/11,755/11,829/0,042 ms

Dar nu se poate conecta:

$ ssh -i ~/.ssh/cert.pem ubuntu@3.<redactat> # EIP pentru eth0
Bun venit la Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-1045-aws x86_64)
...

$ ssh -i ~/.ssh/cert.pem ubuntu@52.<redactat> # EIP pentru eth1
ssh: conectați-vă la gazda 52. <redacted> port 22: Operațiunea a expirat

Am configurat Netflow pe et1 adaptor de rețea în AWS și poate vedea traficul:

2 840416055907 eni-07cc18b6f1b89378e <redactat> 10.0.200.118 54268 22 6 9 576 1623280724 1623280761 ACCEPT OK

Așa că simt că sistemul de operare reduce traficul. Dar nu există niciun firewall configurat și demonul SSH ascultă pe toate interfețele. Am încercat și jurnalele de urmărire /var/log/{syslog,auth.log,kern.log} și dmesg, dar nu a apărut nimic în niciunul dintre ele în timp ce încercam să mă conectez.

Sper că pierd ceva ușor pentru că sunt puțin în pierdere acum. Orice ajutor ar fi foarte apreciat!

1270
1 + 3
A.B avatar
drapel cl
A.B
Spuneți „Există un **tabel** de rutare pentru fiecare subrețea care indică `0.0.0.0/0` către gateway-ul de internet”. . În depozitele de configurare a rețelei nu există tabele de rutare suplimentare și nici reguli de rutare suplimentare care să indice aceste tabele de rutare. Deci, puteți clarifica ce ați vrut să spuneți cu „Există un tabel de rutare pentru fiecare subrețea...”? Un tabel de rutare nu este o rută (intrare). Și multi-homing corectă necesită tabele și reguli
0
Răspunde
Micah Henning avatar
drapel br
Micah Henning
Multumesc pentru raspuns @A.B. Tabelele de rutare sunt definite în AWS, astfel încât traficul de ieșire din instanța EC2 să poată găsi gateway-ul de internet.
0
Răspunde
A.B avatar
drapel cl
A.B
Deoarece sshd nu are o opțiune -I precum ping pentru a bloca rutarea către o interfață, mă tem că veți avea probleme de rutare pe instanța dvs. Doar prima rută implicită funcționează, a doua nu are efect pentru sshd.
1
Răspunde
Puncte:0
Micah Henning avatar Server
drapel br
Micah Henning

Trafic din et1 trebuie configurat pentru a ruta corect:

$ sudo ip rule add from 10.0.200.118 table default
$ sudo ip route add default prin 10.0.200.1 dev eth1 table default
$ sudo ip route spălați memoria cache

Deoarece nu dorim să avem manual SSH în instanță pentru a introduce aceste comenzi, am creat un script systemd pentru a fi executat la pornire.

/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') # presupune /24 masca
sudo ip rule add from $ADDR table default
sudo ip route add default via $GATEWAY dev eth1 table default
sudo ip route spălați memoria cache

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

[Unitate]
Descriere=Configurați rutarea eth1
După=rețea.țintă
After=cloud-final.service

[Serviciu]
Tip=simplu
ExecStart=/bin/bash /home/ubuntu/dual-home.sh

[Instalare]
WantedBy=cloud-init.target

Apoi activați serviciul: $ sudo systemctl activa dual-home

0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.