înregistrare Logare
Puncte:0
avatar Server

Jurnalul Ubuntu UFW arată adresele publice care trimit trafic către adresa mea privată RFC1918

drapel mk
Tirki

Aceasta este într-adevăr o întrebare de rutare, dar aici este fundalul:

Rulez Ubuntu 20.04.3 LTS cu UFW. Rețeaua mea internă este 10.126.1.0/24. Fără traduceri de intrare la marginea Internetului. Dacă îmi inspectez jurnalele UFW, văd mesaje similare cu acesta:

20 august 17:41:01 Nucleu XPS-8100: [ 1964.382883] [UFW BLOCK] IN=enp5s0 OUT= MAC=84:2b:2b:9d:ae:44:02:81:51:8b:22:18: 08:00 SRC=142.250.111.109 DST=10.126.1.41 LEN=85 TOS=0x00 PREC=0x00 TTL=36 ID=11413 PROTO=TCP SPT=993 DPT=40634 WINDOW=SHx00 URGPRES=0x00

Dacă citesc corect, tabele IP/UFW blochează traficul de intrare de la 142.250.111.109 la 10.126.1.41. Confuzia mea provine din traficul IP de la o adresă IP publică transmisă la o adresă IP privată, apoi refuzată (din fericire).

Cu excepția cazului în care înțeleg greșit regulile de rutare pentru Internetul public, niciun ISP care se respectă nu va transporta trafic pentru adrese private și cu atât mai puțin să găsească una dintre miile de instanțe de adrese IP private și apoi să furnizeze traficul.

Fie UFW este confuz, fie eu sunt confuz, fie Internetul face ceva la care nu mă așteptam. Are cineva vreun gând?

Starea UFW returnează această listă de porturi deschise pe mașina Ubuntu:

(bază) glenn@XPS-8100:~/Desktop$ sudo ufw status
Stare: activ

La Acțiune De la
-- ------ ----
137/udp ALLOW 10.126.1.0/24             
138/udp ALLOW 10.126.1.0/24             
139/tcp ALLOW 10.126.1.0/24             
445/tcp ALLOW 10.126.1.0/24             
514/tcp ALLOW 10.126.1.0/24             
514/udp ALLOW 10.126.1.0/24             
22/tcp ALLOW 10.126.1.0/24             
5001/tcp ALLOW 10.126.1.0/24             
5001/udp ALLOW 10.126.1.0/24             
137/tcp ALLOW 10.126.1.0/24             
139/udp ALLOW 10.126.1.0/24             
80/tcp ALLOW 10.126.1.0/24             
8080/tcp ALLOW 10.126.1.0/24             
5201 PERMITERE 10.126.1.0/24
141
0 + 0
Michael Hampton avatar
drapel cz
Michael Hampton
Cu siguranță acest lucru se datorează NAT și este perfect normal (în măsura în care NAT este normal).
2
Răspunde
drapel in
Zoredache
DNAT are loc înainte de rutare și înainte ca tabelul de filtrare să fie procesat. Uită-te la masa ta de nat.
0
Răspunde
Michael Hampton avatar
drapel cz
Michael Hampton
Mai probabil cred că NAT-ul a fost făcut la un router extern.
0
Răspunde
drapel mk
Tirki
Se pare că există un pic de confuzie aici. A văzut cineva o diagramă care demonstrează procesul NAT pentru tabelele IP? Acest lucru ar putea izola în mod clar locul în care are loc acest NAT.
0
Răspunde
drapel mk
Tirki
Am vorbit prea devreme. Acest tutorial de tabele IP arată fluxul.https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES
0
Răspunde
drapel mk
Tirki
Cred că sunt de acord cu Michael Hampton. Am presupus că aceste pachete au fost nesolicitate, dar porturile sunt fie bine cunoscute (porturi de sistem), fie porturi de utilizator. Cred că am solicitat aceste pachete și tabelele IP au blocat o parte a conversației. NAT s-ar întâmpla la marginea Internetului, astfel încât nu există nicio încălcare a regulilor de rutare a Internetului.
0
Răspunde
Puncte:0
avatar Server
drapel fr
Tomek

Ceea ce afișați într-un jurnal este un pachet de returnare/răspuns la o conexiune de IEȘIRE la serverul IMAPS, probabil GMAIL.

SNAT/MASQUARADE care se face în POSTROUTING are propriul său omolog DNAT care are loc în PREROUTING care restabilește adresele originale în pachetele de răspuns pentru conexiunea de ieșire.

Deoarece pachetul pare a fi blocat, acest lucru poate însemna că firewall-ul dvs. este prea restrictiv și nu lasă pachetele STABILITE înapoi. Sau este prea lax și conexiunea ar fi trebuit să fie blocată în primul rând în faza de stabilire.

0 + 0
drapel mk
Tirki
Mulțumiri. Se pare că trebuie să mă duc prin tabelele IP înainte să înțeleg asta.
0
Răspunde
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.