Apa yang mencegah klien DHCP dari mendapatkan rute gateway default?

Raspberry PI terhubung ke server OpenVPN melalui koneksi TAP. Ketuk PI dijembatani dengan antarmuka ethernet PI.

Ketika klien yang dimaksud terhubung ke port ethernet pi, isc-dhcp-server pada server OpenVPN segera mendapat polling dan memberikan alamat IP. Klien mengambil alamat IP tanpa masalah. Namun, ia sama sekali tidak memiliki 'gateway default via ...' di tabel rutenya. Jika saya menambahkan rute secara manual dengan memasukkan:

ip route add default via 10.70.0.1 def eth0

Kemudian klien bekerja dengan sempurna.

Perlu diingat bahwa ini bukan koneksi TUN VPN tradisional. Ini adalah koneksi TAP dan klien VPN adalah Raspberry PI yang berada di antara klien dan server. Jadi, tidak ada rute yang mendorong atau gateway yang mendorong oleh OpenVPN memainkan semua ini sama sekali.

PI ketika terhubung ke Server OpenVPN:

root@pi-test:~# ip addr show br0
5: br0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 96:d5:0f:08:f3:30 brd ff:ff:ff:ff:ff:ff
    inet 10.70.0.201/24 brd 10.70.0.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 2600:xxxx:xxxx:xxxx:94d5:fff:fe08:f330/64 scope global mngtmpaddr dynamic 
       valid_lft 86200sec preferred_lft 14200sec
    inet6 fe80::94d5:fff:fe08:f330/64 scope link 
       valid_lft forever preferred_lft forever

root@pi-test:~# brctl show
bridge name bridge id          STP enabled  interfaces
       br0  8000.96d50f08f330  no           eth0
                                            tap0

Klien saat terhubung ke PI:

me@client:~$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:12:3f:82:92:38 brd ff:ff:ff:ff:ff:ff
    inet 10.70.0.105/24 brd 10.70.0.255 scope global dynamic noprefixroute eth0
       valid_lft 31065sec preferred_lft 31065sec
    inet6 2600:xxxx:xxxx:xxxx:c040:ebd3:1619:57b1/64 scope global temporary dynamic 
       valid_lft 86066sec preferred_lft 14066sec
    inet6 2600:xxxx:xxxx:xxxx:d7f9:41bf:a910:9b43/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 86066sec preferred_lft 14066sec
    inet6 fe80::cfce:6b01:c5d4:ced6/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

me@client:~$ ip route
default via 10.70.0.1 dev eth0 (this line is missing)
10.70.0.0/24 dev eth0 proto kernel scope link src 10.70.0.105 metric 100

Perhatikan juga bahwa RA's for IPv6 bekerja dengan sempurna (begitu juga peruteannya). Hanya melempar ini ke sana sebagai bukti lebih lanjut bahwa jembatan bekerja seperti yang diharapkan. Alamat IPv6 itu semua adalah bagian dari blok IPv6 yang dirutekan Server. Alamat 8723 di bawah ini adalah alamat IPv6 LL server seperti yang diharapkan.

me@client:~$ ip -6 route
2600:xxxx:xxxx:xxxx::/64 dev eth0 proto ra metric 100 pref medium
fe80::/64 dev eth0 proto kernel metric 100 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::d8ae:1bff:fe1f:8723 dev eth0 proto ra metric 100 pref medium

Klien berfungsi seperti yang diharapkan ketika dicolokkan ke router lain. Ia mendapatkan alamat IP-nya DAN 'default via'. Harapan saya adalah bahwa begitu jembatan telah dibangun antara Server dan Klien, bahwa itu harus berperilaku seolah-olah semuanya terhubung secara fisik. Dan, hampir seperti itu. Tidak ada perutean yang berperan dalam persamaan ini, tetapi jika ada yang bertanya, iptables berada dalam mode Terima Semua sampai saya mengetahui hal ini.

Server DHCP (Saya telah menggunakan konfigurasi yang sama ini berkali-kali tanpa masalah):

root@server:~# cat /etc/dhcp/dhcpd.conf
option domain-name "local.net";
option domain-name-servers 10.70.0.1;
ddns-update-style none;
subnet 10.70.0.0 netmask 255.255.255.0 {
        range 10.70.0.100 10.70.0.199;
        option routers 10.70.0.1;
}

host pi-router1 {
        hardware ethernet 96:d5:0f:08:f3:30;
        fixed-address 10.70.0.201;
}

Masalahnya berasal dari Linux yang tampaknya menghapus gateway ["(4) Routers" di dhcpdump] dalam respons DHCP. OpenVPN mendokumentasikan ini sebagai berikut:

Jika --server-bridge digunakan tanpa parameter apa pun, itu akan mengaktifkan mode DHCP-proxy, di mana menghubungkan klien OpenVPN akan menerima alamat IP untuk adaptor TAP mereka dari server DHCP yang berjalan pada LAN sisi server OpenVPN. Perhatikan bahwa hanya klien yang mendukung pengikatan klien DHCP dengan adaptor TAP (seperti Windows) yang dapat mendukung mode ini . Bendera nogw opsional (lanjutan) menunjukkan bahwa informasi gateway tidak boleh didorong ke klien.

Jadi, menggunakan nogw tampaknya tidak mempengaruhi pi - seperti yang diharapkan karena itu adalah Linux. Tetapi ketika saya menghubungkan komputer (segala jenis klien: Linux atau Windows) ke port Ethernet pi, maka sebenarnya sudah mendapatkan gateway. Dengan kata lain, respons DHCP dari server TAP'd membuat jalannya tidak diedit ke klien di sisi lain pi, hanya saja bukan pi itu sendiri. Bagian terakhir ini baik-baik saja karena memiliki skrip konfigurasi sendiri dan seterusnya.

Intinya dan hasilnya adalah: klien generik apa pun dapat terhubung ke pi sebagai router yang terhubung dengan aman ke server VPN dan mereka semua akan diberi alamat IP (baik v4 dan v6) dari server VPN di ujung lain dari TAP tanpa masalah.