Clienții nu au acces la internet în timp ce routerul Ubuntu 20.04 are

Recent încerc să-mi configurez Ubuntu 20.04 ca router. A apărut o problemă ciudată când am crezut că am terminat toți pașii, că clienții care se conectează la routerul Ubuntu pur și simplu nu au acces la Internet în timp ce routerul Ubuntu însuși are.

Înainte de a pune configurații aici, voi pune o imagine a modului în care routerul se asociază cu alte dispozitive:

Router de prim nivel >----<[WAN] Router Ubuntu (IP dinamic) [LAN]>----< Client (DHCP)

Urmând ghidul, am făcut aceste configurații pe routerul Ubuntu. /etc/netplan/00-installer-config.yaml:

reţea:
  ethernet:
    wan1:
      Meci:
        adresa maca: xx:xx:xx:xx:xx:01
      nume-setare: wan1
    dhcp4: da
  eth1:
    Meci:
      adresa maca: xx:xx:xx:xx:xx:02
    nume-set: eth1
    dhcp4: nu
poduri:
  br:
    interfete:
      - et1
    adrese:
      - 192.168.3.1/24

Ieșirea ifconfig este aici:

br: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
    inet 192.168.3.1 netmask 255.255.255.0 difuzare 192.168.3.255
    inet6 fe80::f0de:2aff:fe06:98ad prefixlen 64 scopeid 0x20<link>
    ether a4:1a:3a:b6:08:b5 txqueuelen 1000 (Ethernet)
    Pachete RX 7283 octeți 456695 (456,6 KB)
    Erori RX 0 a scăzut 0 depășiri 0 cadru 0
    Pachete TX 295 octeți 36494 (36,4 KB)
    Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

eth1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
    ether a4:1a:3a:b6:08:b5 txqueuelen 1000 (Ethernet)
    Pachete RX 7283 octeți 558657 (558,6 KB)
    Erori RX 0 a scăzut 0 depășiri 0 cadru 0
    Pachete TX 287 octeți 35750 (35,7 KB)
    Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
    inet 127.0.0.1 netmask 255.0.0.0
    inet6 ::1 prefixlen 128 scopeid 0x10<gazdă>
    loop txqueuelen 1000 (Loopback local)
    Pachete RX 7941154 octeți 604164948 (604,1 MB)
    Erori RX 0 a scăzut 0 depășiri 0 cadru 0
    Pachete TX 7941154 octeți 604164948 (604,1 MB)
    Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

wan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    inet 192.168.1.4 netmask 255.255.255.0 difuzare 192.168.1.255
    inet6 fe80::da50:e6ff:fe3f:fdcb prefixlen 64 scopeid 0x20<link>
    inet6 2409:8a50:1873:70b3:da50:e6ff:fe3f:fdcb prefixlen 64 scopeid 0x0 <global>
    ether d8:50:e6:3f:fd:cb txqueuelen 1000 (Ethernet)
    Pachete RX 39031 octeți 3017742 (3,0 MB)
    Erori RX 0 a scăzut 2229 depășiri 0 cadru 0
    Pachete TX 35636 octeți 36600911 (36,6 MB)
    Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

De asemenea, am activat redirecționarea ipv4 adăugând această linie la /etc/sysctl.conf:

net.ipv4.ip înainte=1

Iptables au fost setate ca următoarea linie de mai jos și menținute făcând ca systemd să ruleze iptables-restore on-boot:

sudo iptables -t nat -A POSTROUTING -o wan1 -j MASQUERADE

Am instalat dnsmasq și am editat /etc/dnsmasq.conf în următoarele: (systemd-resolved a fost oprit și dezactivat)

adresa-ascultă=127.0.0.1,192.168.3.1
port=53
interfață=eth1
dhcp-range=192.168.3.100,192.168.3.199,255.255.255.0,24h
dhcp-option=option:router,192.168.3.1
dhcp-option=option:dns-server,192.168.3.1

După ce le-am configurat, se pare că funcționează. Pot confirma că DHCP funcționează, deoarece pot vedea jurnalele dnsmasq, iar routerul Ubuntu însuși are acces la internet.

Dar ceva nu era în regulă. De pe dispozitivul Client, am încercat să ping un domeniu. Domeniul a fost rezolvat la adresa IPV4 corectă, dar clientul nu o poate accesa. Apoi am dat ping de la client la router și invers, ambele au funcționat. Ghidul pe care l-am urmat nu a menționat niciodată despre asta.Vă rog să-mi spuneți dacă aveți idee de ce nu funcționează, mulțumesc anticipat!

Încercați să adăugați această regulă:

iptables -A FORWARD --in-interface br -j ACCEPT

și în cele din urmă înlocuiți sudo iptables -t nat -A POSTROUTING -o wan1 -j MASQUERADE de

sudo iptables -t nat -A POSTROUTING -s 192.168.3.0/24 -o wan1 -j MASQUERADE

Un Wireshark (sau tshark, tcpdump) poate fi utilizat pentru diagnosticare pe ambele interfețe simultan.

Analiză extinsă

Pot exista multe motive pentru care routerul nu funcționează:

• Redirecționarea IP nu este activată
• Serverul DNS este inaccesibil pentru gazdele LAN
• Setarea NAT (traducere adrese de rețea) nu funcționează pentru gazdele LAN
• ...

Reporniți computerul pentru a aduce toate serviciile la starea lor normală.

Nu utilizați nume, ci adrese IP numerice pentru a testa ping până când verificați că toate celelalte teste enumerate mai jos sunt OK. Eliminați posibila problemă DNS simultană în acest fel.

Testul 1

Verificați starea de rutare IP (redirecționare) (rezultatul 1 înseamnă că redirecționarea este activată):

cat /proc/sys/net/ipv4/ip_forward

Testul 2

Verificați setarea corectă NAT (masquerade) pentru interfața dvs. LAN:

ping -c 3 8.8.8.8
ping -c 3 -I 192.168.3.1 8.8.8.8

Prima comandă de mai sus este un test de accesibilitate al adresei IP de destinație. Trebuie să obțineți 3 răspunsuri ping valide. A doua comandă testează dacă NAT funcționează pentru adresele IP LAN. Dacă nu primiți niciun răspuns, înseamnă că Masquerade nu poate traduce adresa sursă 192.168.3.1. și celelalte adrese din LAN (192.168.3.0/24) au aceeași problemă. Verificați cu mare atenție secțiunea NAT din setarea iptables. Continuați cu testele următoare dacă setarea NAT arată bine, dar nu primiți niciun răspuns ping.

Dacă răspunsul ping este OK, dar alte noduri de rețea din LAN încă nu pot trimite ping la 8.8.8.8, atunci soluția posibilă este să specificați adresa completă a rețelei (nu numai propria proprie). br adresa de interfață 192.168.3.1) ca sursă pentru NAT:

sudo iptables -t nat -A POSTROUTING -s 192.168.3.0/24 -o wan1 -j MASQUERADE

Testul 3

Pachetele WAN de ieșire și adresele lor IP:

Verificați tcpdump este instalat și instalați-l, dacă nu este prezent.

care tcpdump
sudo apt-get install tcpdump

Procesul descris vă va ghida să verificați funcționalitatea tcpdump și o captare a datelor din rețea. Puteți opri procesul de capturare apăsând Ctrl+C în fereastra instanței tcpdump care rulează. Deschideți a doua fereastră de terminal (T2). Primul (T1) va fi utilizat pentru generarea de trafic și verificarea răspunsului. Veți folosi cel de-al doilea terminal (T2) pentru a porni și opri sarcinile de capturare folosind tcpdump. Este posibil să utilizați un singur terminal pentru ambele sarcini, dar dacă nu sunteți familiarizat cu comutarea sarcinilor în prim-plan și în fundal, este mai sigur să utilizați două terminale.

T2

sudo tcpdump -i wan1 -n icmp și gazdă 8.8.8.8

T1

ping -c 2 8.8.8.8

Veți vedea cele două pachete de ieșire ICMP (cerere ecou) și două răspunsuri ecou de intrare. Urmăriți adresele IP sursă și destinație. Pachetul de ieșire are IP destinație 8.8.8.8 și sursa este adresa IP WAN publică. Le veți compara cu adresele afișate în pasul următor.

Apăsați tasta Enter în terminalul T2 pentru a crea un nou spațiu de linie acolo în ieșirea rulării tcpdump. Vă ajută să separați datele vechi și noi capturate în fereastră.

T1

ping -c 2 -I 192.198.3.1 8.8.8.8

Ce vezi? Există aceste posibilități:

• nu sunt capturate pachete
• sunt afișate numai pachetele de ieșire și au o adresă IP sursă greșită (de exemplu, 192.168.3.1 în loc de adresa IP publică a interfeței WAN).
• atât pachetele de ieșire, cât și cele de intrare sunt vizibile.

Rupe tcpdump în fereastra T2 (Ctrl+C). Vă rugăm să copiați răspunsul de la T2 și să-l lipiți aici în răspunsul dvs. Adăugați răspunsul lui ruta ip și în cele din urmă aceste comenzi:

ip neigh
sudo iptables-save

Descrieți rezultatele altor teste.