DHCP

DHCP je zkratka pro w: Dynamic Host Configuration Protocol

DHCP server

dnsmasq

w: dnsmasq je jednoduchý DNS a DHCP server

Instalace a help:

sudo apt-get install dnsmasq
man dnsmasq

Konfigurační soubor:

/etc/dnsmasq.conf

Pro spuštění DHCP serveru tam stačí odkomentovat řádek:

dhcp-range=192.168.0.50,192.168.0.150,12h

a specifikovat port (jinak poběží na všech portech, což nemusí být bezpečné), např.:

interface=enp0s25

Po změně konfigurace otestujeme syntax:

dnsmasq --test

a restartujeme server:

service dnsmasq restart

Status:

sudo systemctl status dnsmasq

A pak se podíváme, které adresy jsou propůjčené:

cat /var/lib/misc/dnsmasq.leases

Externí odkazy:

wiki.debian.org: HowTodnsmasq
linuxexpres.cz (Michal Dočekal 2012-08-07): Správa linuxového serveru: DNS a DHCP server dnsmasq

Brána

IP adresu brány nastavím staticky v souboru:

/etc/network/interfaces

Například takto:

auto enp0s25
iface enp0s25 inet static
address 192.168.0.1
netmask 255.255.255.0
gateway 255.255.255.0

A buď restartuji celé síťové služby

service networking restart

anebo jenom shodím a nahodím bránu:

ifdown enp0s25
ifup enp0s25

Zkontroluji:

ifconfig

Routování

Nastavení forwardingu brány (v případě, že budeme chtít routovat pakety):

Editujeme:

/etc/sysctl.conf

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

Poté mu řekneme, aby vzal změněnou tabulku v potaz:

sysctl -p

Případně:

service networking restart

A ještě zkontrolujeme routovací tabulku:

route

Může se stát, že se náš počítač bude chtít defaultně připojovat na rozhraní, odkuď posíláme konektivitu dál:

Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
default         255.255.255.0   0.0.0.0         UG    0      0        0 enp0s25

Takže to musíme vymazat z tabulky:

route -v del default dev enp0s25

Externí odkazy:

wiki.mojefedora.cz: [https://wiki.mojefedora.cz/doku.php?id=navody:f14:sit Fedora v počítačové síti

Problémy

Zjistíme, jestli neběží firewall:

ufw status

Zkusíme dohledat pakety pomocí tcpdump

Ještě zkusíme

cat /proc/sys/net/ipv4/conf/all/rp_filter
cat /proc/sys/net/ipv4/conf/enp0s25/rp_filter
cat /proc/sys/net/ipv4/conf/wlp3s0/rp_filter

pokud jsou v odpovědi jedničky, nastavíme je na nuly:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 >  /proc/sys/net/ipv4/conf/enp0s25/rp_filter
echo 0 >  /proc/sys/net/ipv4/conf/wlp3s0/rp_filter

Viz Dotaz: Nejde ping na server z jiné sítě

wiki.ubuntu.cz: Firewall, router, gateway

Zkusím tcpdump

m-linux.cz (Martin 2014-10-22): TCPDUMP základy
danielmiessler.com (2018-07-15): A tcpdump Tutorial and Primer with Examples

Z 192.168.0.111 pingám na 192.168.0.1, jede jak po másle.

tcpdump host 192.168.0.111

neukáže nic. Zkusím tedy:

# tcpdump -i enp0s25
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
15:25:58.816839 IP Alena-PC.54419 > 192.168.0.1.domain: 53247+ A? detectportal.firefox.com. (42)
15:25:58.816897 IP 192.168.0.1 > Alena-PC: ICMP 192.168.0.1 udp port domain unreachable, length 78
15:25:59.830785 IP Alena-PC.54419 > 192.168.0.1.domain: 53247+ A? detectportal.firefox.com. (42)
15:25:59.830853 IP 192.168.0.1 > Alena-PC: ICMP 192.168.0.1 udp port domain unreachable, length 78

Zajímavý. Už jsem dopingal, ale zřejmě Firefox se furt snaží. Zavřu ho tedy.

tcpdump -i enp0s25
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
15:28:49.299459 IP6 fe80::224:81ff:feb1:bf48.mdns > ff02::fb.mdns: 0 [9q] PTR (QM)? _nfs._tcp.local. PTR (QM)? _ipp._tcp.local. PTR (QM)? _ipps._tcp.local. PTR (QM)? _ftp._tcp.local. PTR (QM)? _webdav._tcp.local. PTR (QM)? _webdavs._tcp.local. PTR (QM)? _sftp-ssh._tcp.local. PTR (QM)? _smb._tcp.local. PTR (QM)? _afpovertcp._tcp.local. (141)
15:28:56.728124 IP Alena-PC.53018 > 192.168.0.1.domain: 2569+ A? teredo.ipv6.microsoft.com. (43)
15:28:56.728225 IP 192.168.0.1 > Alena-PC: ICMP 192.168.0.1 udp port domain unreachable, length 79
15:28:57.741184 IP Alena-PC.53018 > 192.168.0.1.domain: 2569+ A? teredo.ipv6.microsoft.com. (43)
15:28:57.741274 IP 192.168.0.1 > Alena-PC: ICMP 192.168.0.1 udp port domain unreachable, length 79

Pořád se někdo snaží.

Mezitím Windoze zahlásí konflikt IP adres. Jaký konflikt? 111 přeci nikdo jiný nemá:

nmap -sn 192.168.0.0/24

Starting Nmap 7.01 ( https://nmap.org ) at 2018-07-23 15:37 CEST
Nmap scan report for Alena-PC (192.168.0.111)
Host is up (0.00026s latency).
MAC Address: 00:1F:C6:F4:17:FB (Asustek Computer)
Nmap scan report for 192.168.0.1
Host is up.
Nmap done: 256 IP addresses (2 hosts up) scanned in 8.52 seconds

No možná tam ta Windozí hláška visela od minule. Tak to vypadá, že Windoze se už uklidnily a vidím už jen to pingání:

tcpdump -i enp0s25 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
15:46:56.626744 IP 192.168.0.111 > 192.168.0.1: ICMP echo request, id 1, seq 104, length 40
15:46:56.626829 IP 192.168.0.1 > 192.168.0.111: ICMP echo reply, id 1, seq 104, length 40
15:46:57.637180 IP 192.168.0.111 > 192.168.0.1: ICMP echo request, id 1, seq 105, length 40
15:46:57.637266 IP 192.168.0.1 > 192.168.0.111: ICMP echo reply, id 1, seq 105, length 40
15:46:58.651427 IP 192.168.0.111 > 192.168.0.1: ICMP echo request, id 1, seq 106, length 40
15:46:58.651514 IP 192.168.0.1 > 192.168.0.111: ICMP echo reply, id 1, seq 106, length 40
15:46:59.665336 IP 192.168.0.111 > 192.168.0.1: ICMP echo request, id 1, seq 107, length 40
15:46:59.665419 IP 192.168.0.1 > 192.168.0.111: ICMP echo reply, id 1, seq 107, length 40
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel

Teď popingkám na Wi-Fi port:

tcpdump -i enp0s25 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
15:46:18.615029 ARP, Request who-has 192.168.0.1 tell 192.168.0.111, length 46
15:46:18.615091 ARP, Reply 192.168.0.1 is-at 00:24:81:b1:bf:48, length 28
15:46:18.615429 IP 192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 100, length 40
15:46:18.615489 IP 192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 100, length 40
15:46:19.619539 IP 192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 101, length 40
15:46:19.619617 IP 192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 101, length 40
15:46:20.633557 IP 192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 102, length 40
15:46:20.633615 IP 192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 102, length 40
15:46:21.647547 IP 192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 103, length 40
15:46:21.647642 IP 192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 103, length 40
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

(Jen nechápu, kde to napočítalo 10 paketů, když jich vidím jen 8

Zkusím se omezit jen na hosta 192.168.0.111:

 tcpdump -i enp0s25 -n host 192.168.0.111
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
15:54:58.628900 IP 192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 120, length 40
15:54:58.628954 IP 192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 120, length 40
15:54:59.638104 IP 192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 121, length 40
15:54:59.638157 IP 192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 121, length 40
15:55:00.652205 IP 192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 122, length 40
15:55:00.652291 IP 192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 122, length 40
15:55:01.666047 IP 192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 123, length 40
15:55:01.666133 IP 192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 123, length 40
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel

Dosud O.K.

Teď odeberu omezení na eth interface (a nejspíš tcpdump jako defaultní bere to Wi-Fi):

tcpdump -n host 192.168.0.111
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Hmmm, tak tomuhle už pomalu přestávám rozumět, ping se mi na Windoze v pořádku vrací a na Wi-Fi portu wlp3s0 žádná aktivita? Tak kdo to tedy odpovídá? Tak jako že systém nějak usoudí, že když někdo přes eth port 192.168.0.111 pingá na Wi-Fi port 192.168.43.196, že by bylo slušné mu odpovědět, i když ten forwarding v jádře třeba zcela nefunguje?

Zkusím tam dát zase ten eth. port a nechat si vypsat podrobnosti:

 tcpdump -v -i enp0s25 -n host 192.168.0.111
tcpdump: listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
16:05:30.408337 IP (tos 0x0, ttl 128, id 6757, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 128, length 40
16:05:30.408425 IP (tos 0x0, ttl 64, id 57139, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 128, length 40
16:05:31.423799 IP (tos 0x0, ttl 128, id 6758, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 129, length 40
16:05:31.423882 IP (tos 0x0, ttl 64, id 57226, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 129, length 40
16:05:32.437854 IP (tos 0x0, ttl 128, id 6759, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 130, length 40
16:05:32.437950 IP (tos 0x0, ttl 64, id 57297, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 130, length 40
16:05:33.451871 IP (tos 0x0, ttl 128, id 6760, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 131, length 40
16:05:33.451964 IP (tos 0x0, ttl 64, id 57376, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 131, length 40
16:05:33.671266 IP (tos 0x0, ttl 128, id 6761, offset 0, flags [none], proto UDP (17), length 71)
    192.168.0.111.59071 > 192.168.0.1.53: 44694+ A? teredo.ipv6.microsoft.com. (43)
16:05:33.671364 IP (tos 0xc0, ttl 64, id 9253, offset 0, flags [none], proto ICMP (1), length 99)
    192.168.0.1 > 192.168.0.111: ICMP 192.168.0.1 udp port 53 unreachable, length 79
        IP (tos 0x0, ttl 128, id 6761, offset 0, flags [none], proto UDP (17), length 71)
    192.168.0.111.59071 > 192.168.0.1.53: 44694+ A? teredo.ipv6.microsoft.com. (43)
16:05:34.684252 IP (tos 0x0, ttl 128, id 6762, offset 0, flags [none], proto UDP (17), length 71)
    192.168.0.111.59071 > 192.168.0.1.53: 44694+ A? teredo.ipv6.microsoft.com. (43)
16:05:34.684347 IP (tos 0xc0, ttl 64, id 9468, offset 0, flags [none], proto ICMP (1), length 99)
    192.168.0.1 > 192.168.0.111: ICMP 192.168.0.1 udp port 53 unreachable, length 79
        IP (tos 0x0, ttl 128, id 6762, offset 0, flags [none], proto UDP (17), length 71)
    192.168.0.111.59071 > 192.168.0.1.53: 44694+ A? teredo.ipv6.microsoft.com. (43)
16:05:35.615479 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.111 tell 192.168.0.1, length 28
16:05:35.615665 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.111 is-at 00:1f:c6:f4:17:fb, length 46
16:05:35.698061 IP (tos 0x0, ttl 128, id 6763, offset 0, flags [none], proto UDP (17), length 71)
    192.168.0.111.59071 > 192.168.0.1.53: 44694+ A? teredo.ipv6.microsoft.com. (43)
16:05:35.698145 IP (tos 0xc0, ttl 64, id 9704, offset 0, flags [none], proto ICMP (1), length 99)
    192.168.0.1 > 192.168.0.111: ICMP 192.168.0.1 udp port 53 unreachable, length 79
        IP (tos 0x0, ttl 128, id 6763, offset 0, flags [none], proto UDP (17), length 71)
    192.168.0.111.59071 > 192.168.0.1.53: 44694+ A? teredo.ipv6.microsoft.com. (43)
16:05:37.710792 IP (tos 0x0, ttl 128, id 6764, offset 0, flags [none], proto UDP (17), length 71)
    192.168.0.111.59071 > 192.168.0.1.53: 44694+ A? teredo.ipv6.microsoft.com. (43)
16:05:37.710887 IP (tos 0xc0, ttl 64, id 9917, offset 0, flags [none], proto ICMP (1), length 99)
    192.168.0.1 > 192.168.0.111: ICMP 192.168.0.1 udp port 53 unreachable, length 79
        IP (tos 0x0, ttl 128, id 6764, offset 0, flags [none], proto UDP (17), length 71)
    192.168.0.111.59071 > 192.168.0.1.53: 44694+ A? teredo.ipv6.microsoft.com. (43)
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel

Hmmm, podrobnosti mi nevyzradily, kdo to vlastně na ten ping odpovídá, když se to neděje na požadovaném portu 192.168.43.196.

Aby se mi tam nepletly jiné věci, tak jen icmp:

tcpdump -n -i any icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:21:25.208005 IP 192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 156, length 40
16:21:25.208107 IP 192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 156, length 40
16:21:26.213631 IP 192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 157, length 40
16:21:26.213714 IP 192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 157, length 40
16:21:27.227495 IP 192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 158, length 40
16:21:27.227584 IP 192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 158, length 40
16:21:28.241494 IP 192.168.0.111 > 192.168.43.196: ICMP echo request, id 1, seq 159, length 40
16:21:28.241527 IP 192.168.43.196 > 192.168.0.111: ICMP echo reply, id 1, seq 159, length 40
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel

Pingám na mobil, nic se nevrací:

 tcpdump -n -i any icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:26:29.015576 IP 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 168, length 40
16:26:29.015644 IP 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 168, length 40
16:26:33.742693 IP 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 169, length 40
16:26:33.742755 IP 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 169, length 40
16:26:38.734983 IP 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 170, length 40
16:26:38.735027 IP 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 170, length 40
16:26:43.742527 IP 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 171, length 40
16:26:43.742594 IP 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 171, length 40
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel

Jak poznám, ze kterého portu mi to leze? Když dám přepínač -i all, proč se mi pak nikde nezobrazuje, o jaký port se jedná? Ani v man tcpdump to nemůžu najít.

Ale to bylo to asi z obou portů, protože každý paket vidím dvakrát. Tak přidám přepínač -e

tcpdump icmp -n -e -i any
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:34:07.965223  In 00:1f:c6:f4:17:fb ethertype IPv4 (0x0800), length 76: 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 184, length 40
16:34:07.965300 Out 00:16:ea:ee:fc:f2 ethertype IPv4 (0x0800), length 76: 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 184, length 40
16:34:12.749900  In 00:1f:c6:f4:17:fb ethertype IPv4 (0x0800), length 76: 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 185, length 40
16:34:12.749944 Out 00:16:ea:ee:fc:f2 ethertype IPv4 (0x0800), length 76: 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 185, length 40
16:34:17.742043  In 00:1f:c6:f4:17:fb ethertype IPv4 (0x0800), length 76: 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 186, length 40
16:34:17.742107 Out 00:16:ea:ee:fc:f2 ethertype IPv4 (0x0800), length 76: 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 186, length 40
16:34:22.749506  In 00:1f:c6:f4:17:fb ethertype IPv4 (0x0800), length 76: 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 187, length 40
16:34:22.749575 Out 00:16:ea:ee:fc:f2 ethertype IPv4 (0x0800), length 76: 192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 187, length 40
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel

Ještě nikde nevidím TTL. Tak musím přidat -v

tcpdump icmp -n -v -e -i any
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:37:17.693061  In 00:1f:c6:f4:17:fb ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 128, id 7153, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 192, length 40
16:37:17.693118 Out 00:16:ea:ee:fc:f2 ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 127, id 7153, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 192, length 40
16:37:22.244470  In 00:1f:c6:f4:17:fb ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 128, id 7154, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 193, length 40
16:37:22.244506 Out 00:16:ea:ee:fc:f2 ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 127, id 7154, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 193, length 40
16:37:24.944514 Out 00:24:81:b1:bf:48 ethertype IPv4 (0x0800), length 115: (tos 0xc0, ttl 64, id 22448, offset 0, flags [none], proto ICMP (1), length 99)
    192.168.0.1 > 192.168.0.111: ICMP 192.168.0.1 udp port 53 unreachable, length 79
        (tos 0x0, ttl 128, id 7155, offset 0, flags [none], proto UDP (17), length 71)
    192.168.0.111.63584 > 192.168.0.1.53: 20535+ A? teredo.ipv6.microsoft.com. (43)
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel

A když to omezím jen na Wi-Fi port, tak ho vidím jen jednou:

tcpdump -n -e -v -i wlp3s0 icmp
tcpdump: listening on wlp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:42:48.591887 00:16:ea:ee:fc:f2 > 02:40:1b:4f:33:3a, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 7197, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 200, length 40
16:42:53.249252 00:16:ea:ee:fc:f2 > 02:40:1b:4f:33:3a, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 7198, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 201, length 40
16:42:58.241332 00:16:ea:ee:fc:f2 > 02:40:1b:4f:33:3a, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 7199, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.0.111 > 192.168.43.1: ICMP echo request, id 1, seq 202, length 40
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

Tak to přece jenom vypadá, že to na ten Wi-Fi port doleze, ale už se ten ping přes něj nevrátí zpátky.

Ale přitom, když pingám ze svého ubuntího stroje, tak se mi ty pakety z mobilu vrací O.K. Tak kde bude problém?

tcpdump -n -e -v -i wlp3s0 icmp
tcpdump: listening on wlp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:47:09.804960 00:16:ea:ee:fc:f2 > 02:40:1b:4f:33:3a, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 5350, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.43.196 > 192.168.43.1: ICMP echo request, id 14454, seq 1, length 64
16:47:09.808139 02:40:1b:4f:33:3a > 00:16:ea:ee:fc:f2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 19638, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.43.1 > 192.168.43.196: ICMP echo reply, id 14454, seq 1, length 64
16:47:10.806676 00:16:ea:ee:fc:f2 > 02:40:1b:4f:33:3a, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 5505, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.43.196 > 192.168.43.1: ICMP echo request, id 14454, seq 2, length 64
16:47:10.809695 02:40:1b:4f:33:3a > 00:16:ea:ee:fc:f2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 19699, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.43.1 > 192.168.43.196: ICMP echo reply, id 14454, seq 2, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

Chyba v routování?

Ještě googlím

tcpdump net.ipv4.ip_forward WiFI a nacházím:
- microhowto.info: Enable forwarding of IPv4 network packets

S tím tcpdump už jsem to zkoušel, tak teď vyzkouším ještě to routování:

Odchozí pakety:

ip route get to 195.113.0.1 from 192.168.0.111 iif enp0s25
195.113.0.1 from 192.168.0.111 via 192.168.43.1 dev wlp3s0 
    cache  iif enp0s25

Tak to vypadá snad v pořádku.

A příchozí pakety:

ip route get to 192.168.0.111 from 195.113.0.1 iif wlp3s0
192.168.0.111 from 195.113.0.1 dev enp0s25 
    cache  iif wlp3s0

Tak to vypadá taky v pořádku, snad.

Ještě výpis aktuální routovací tabulky:

route
Směrovací tabulka v jádru pro IP
Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
default         192.168.43.1    0.0.0.0         UG    600    0        0 wlp3s0
link-local      *               255.255.0.0     U     1000   0        0 wlp3s0
192.168.0.0     *               255.255.255.0   U     0      0        0 enp0s25
192.168.43.0    *               255.255.255.0   U     600    0        0 wlp3s0

route -n
Směrovací tabulka v jádru pro IP
Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
0.0.0.0         192.168.43.1    0.0.0.0         UG    600    0        0 wlp3s0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlp3s0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp0s25
192.168.43.0    0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0

Také vypadá O.K.

Firewall

Zkouška: Necháme si vylistovat (přepínač -L jako List) tabulky:

filter:

iptables -t filter -L FORWARD -n

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

nat:

iptables -t nat -L -n

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

mangle:

iptables -t mangle -L -n

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Tak když je všude (policy ACCEPT), tak je to snad O.K.?

Ještě zkusím počítat ty pakety.

Nejdřív zkusím ping z mé mašiny

194.228.78.240 je nejbližší věc od O2, na kterou se dá pingat (asi utopená ve Vltavě).

iptables -t filter -Z FORWARD

ping -c 3 194.228.78.240
PING 194.228.78.240 (194.228.78.240) 56(84) bytes of data.
64 bytes from 194.228.78.240: icmp_seq=1 ttl=250 time=49.5 ms
64 bytes from 194.228.78.240: icmp_seq=2 ttl=250 time=44.3 ms
64 bytes from 194.228.78.240: icmp_seq=3 ttl=250 time=41.7 ms
--- 194.228.78.240 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 41.764/45.215/49.578/3.259 ms

iptables -t filter -L FORWARD -nv
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Tak a teď zkusím stejný experiment s pingáním z Widlí:

Poté, co Widle 4x neúspěšně pingly, tak fakticky narostly čítače:

iptables -t filter -L FORWARD -nv
Chain FORWARD (policy ACCEPT 4 packets, 240 bytes)
 pkts bytes target     prot opt in     out     source               destination

Tak to bude asi to ono, ta chybka?

Maškaráda

Nedávno jsem si zpíval tu písničku od Suchého&Šlitra o té obnošené vestě. Už jsem si málem lehal na koleje a najednou zjevil se mi přítel, respektive mail od něho, z něhož si dovoluji citovat:

ďábel je skryt v detailu

echo "1" >  /proc/sys/net/ipv4/conf/enp0s25/ip_forward
iptables -A POSTROUTING -t nat -o wlp3s0 -j MASQUERADE

Další rady:

root.cz (2003-05-26): Připojujeme domácí síť – 15 let starý, ale stále +- aktuální článek Johanky Drahomíry Spoustové, kdysi šéfredaktorky Roota
Google DNAT – pokud by (náhodou) bylo jest třeba zpřístupnit něco ze služeb strojů na vnitřní síti

No jo, já tušil toho smradlavého psa v té maškarádě a nat tabulkách, jenže ty já hrozně nerad a snažil jsem se tomu pořád nějak vyhnout. Už jsem to předtím dogůglil tady, jenže on to psal na apríla a tak jsem to raději přeskočil, aby to nebyl zase nějaký blbý vtip:

opensourceforu.com (Mandar Shinde 2015-04-01): How to Configure Ubuntu as a Router

O.K., tak tedy dle Jkl ověříme:

cat /proc/sys/net/ipv4/conf/enp0s25/ip_forward
cat: /proc/sys/net/ipv4/conf/enp0s25/ip_forward: Adresář nebo soubor neexistuje

Skutečně, taková věc tam není.

Co to udělá, když zkusím zapsat do něčeho, co ještě není? Jak se dalo očekávat:

echo "1" >  /proc/sys/net/ipv4/conf/enp0s25/ip_forward
bash: /proc/sys/net/ipv4/conf/enp0s25/ip_forward: Adresář nebo soubor neexistuje

No tak si ho zkusíme vytvořit:

touch  /proc/sys/net/ipv4/conf/enp0s25/ip_forward
touch: nelze se dotknout (provést příkaz „touch“) '/proc/sys/net/ipv4/conf/enp0s25/ip_forward': Adresář nebo soubor neexistuje

No jo, ani emacs to nezvládne – Buffer is read-only: #<buffer ip_forward> Takže to vypadá, že v /proc se asi žádné další soubory vytvářet nedají, a to ani s právem roota :-(

Takže googlím: ubuntu /proc/sys/net/ipv4/conf/enp0s25/ip_forward:

Bash /proc/sys/net/ipv4/ip_forward: Permission denied

No tam se radí to, co už jsem dávno udělal: net.ipv4.ip_forward = 1

O.k., kašlu na to, jdu na tu maškarádu:

Tak koukám do man iptables, co vlastně ty přepínače dělají. A (add) je jasný,

-o Name of an interface via which a packet is going to be sent (for packets entering the FORWARD, OUTPUT and POSTROUTING chains). When the "!" argument is used before the interface name, the sense is inverted. If the interface name ends in a "+", then any interface which begins with this name will match. If this option is omitted, any interface name will match.
-j This specifies the target of the rule; i.e., what to do if the packet matches it. The target can be a user-defined chain (other than the one this rule is in), one of the special builtin targets which decide the fate of the packet immediately, or an extension (see EXTENSIONS below). If this option is omitted in a rule (and -g is not used), then matching the rule will have no effect on the packet's fate, but the counters on the rule will be incremented.

O.K., tedy zopakujeme, co jsme v té tabulce měli předtím:

iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Nacpeme to tam:

iptables -A POSTROUTING -t nat -o wlp3s0 -j MASQUERADE

a podíváme se na výsledek:

iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0

No tak to jsem zvědavý, jestli to už teď bude routovat!

No heléé, BINGO!, pingáme!

Spíš zatím ale jen malé BINGO!, nějak ještě nechodí DNS :-(

DNS

Takže asi skončíme tím, čím jsme začali – dnsmasq. Ještě asi zřejmě budeme muset nějak dokonfigurovat, aby poslouchal i na tom portu 192.168.0.1, což je gateway pro vnitřní síť.

Basic DNS Setup

Ale jo, koukám, že v /etc/dnsmasq.conf mám

interface=enp0s25

Tak v čem je kurňajs problém?

dig www.wikipedia.org @127.0.0.1 – funguje
dig www.wikipedia.org @@192.168.0.1 – nefunguje :-(

Jakto že na tom portu neposlouchá?? On ani na tom venkovním portu neposlouchá:

dig www.wikipedia.org @203.0.113.1

Tak co s ním?

Nejhorší je, že to DNS na tch Windoze nefunguje ani v případě, kdy jim dám nějaký DNS server natvrdo.

Zkusím tedy přidat další změny tabulek a uložit si je postupně, kdyby to bylo k ničemu:

iptables -A FORWARD -i wlp3s0 -o enp0s25 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables-save > /etc/iptables.rules.003

iptables -A FORWARD -i enp0s25 -o wlp3s0 -j ACCEPT
iptables-save > /etc/iptables.rules.004

Tak nepomohlo :-(

Nejhorší je, že ta DNS na Windozech nefunguje ani v případech, kdy tam k tomu síťovému adaptéru přiřadím např. rektorátní DNS 195.113.0.2 natvrdo

Tak ještě jsem si všimnul:

wiki.archlinux.org: dnsmasq

To use this computer to listen on its LAN IP address for other computers on the network. It is recommended that you use a static LAN IP in this case. E.g.:

listen-address=192.168.1.1

Takže to udělám takhle:

# Repeat the line for more than one interface.
#interface=enp0s25
# Or you can specify which interface _not_ to listen on
#except-interface=
# Or which to listen on by address (remember to include 127.0.0.1 if
# you use this.)
#listen-address=
listen-address=127.0.0.1
listen-address=192.168.0.1

 service dnsmasq restart

A zkusím:

 dig www.wikipedia.org @192.168.0.1

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.wikipedia.org @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13675
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;www.wikipedia.org.             IN      A

;; ANSWER SECTION:
www.wikipedia.org.      435     IN      A       91.198.174.192

;; Query time: 2 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Mon Jul 23 21:23:44 CEST 2018
;; MSG SIZE  rcvd: 62

Voila! Tak to by mohlo snad konečně zabrat!

Tak jsem vrátil zpátky nastavení adapteru na automatické DHCP (včetně DNS) a ono to fakt funguje!