Dua situs, satu subnet, satu hub WireGuard: buatlah berfungsi

Kedua situs menggunakan rentang LAN yang sama, dan tumpang tindih bukanlah yang sebenarnya merusak desain. Hub harus memilih situs hanya berdasarkan alamat tujuan, dan dua tujuan yang identik tidak memberinya apa pun untuk memilih. Menomori ulang kantor yang berjalan agar sesuai dengan terowongan biasanya merupakan pertukaran yang lebih buruk daripada memberi setiap layanan yang diterbitkan alamat berbeda yang dapat dibawa terowongan. Desain di bawah menerbitkan satu layanan HTTPS per situs dan tidak ada yang lain.

Mengapa tumpang tindih bukan masalah sebenarnya

WireGuard meneruskan berdasarkan tujuan: AllowedIPs suatu peer menentukan peer mana yang menerima paket. Dua peer tidak dapat sama-sama mengumumkan 10.10.7.0/24 tanpa salah satunya memenangkan setiap pencarian. Itu adalah sifat tabel peer, bukan terowongan, itulah sebabnya solusinya di sini adalah rencana alamat, bukan trik perutean.

Rencananya adalah berhenti mengumumkan LAN sama sekali. Umumkan alias per layanan sebagai gantinya, satu alamat per situs, dan biarkan gateway setiap situs menerjemahkan alias itu ke aplikasi sebenarnya.

Pengguna merutekan dua alamat unik, tidak pernah melihat prefiks yang ambigu, dan tidak ada yang berubah di kedua kantor. Ini juga menyatakan batasnya dengan jujur: Anda menerbitkan satu layanan HTTPS dari setiap situs, bukan menggabungkan dua jaringan. Aturan berikut tetap kecil karena pernyataannya sempit. Pernyataan yang lebih luas akan membutuhkan aturan yang lebih luas, dan begitulah desain seperti ini menjadi rumit.

Beri setiap situs alias yang dapat dirutekan pengguna

Pilih alamat dari rentang yang tidak berbenturan dengan apa pun di mesin pengguna, hub, atau salah satu LAN. Di sini hub adalah 10.66.0.1, pengguna 10.66.0.10, gateway 10.66.0.21 dan 10.66.0.22, dan kedua alias 10.77.1.20 dan 10.77.2.20. Hub menerbitkan setiap alias melalui peer yang memilikinya, sehingga paket keluar yang dialamatkan ke satu alias hanya dapat keluar melalui situs yang cocok:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

Sisi pengguna hanya membutuhkan kedua alias, yang menjaga konfigurasi klien bebas dari kedua prefiks LAN. Tidak ada dalam konfigurasi itu yang menyebut salah satu LAN sebenarnya:

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

Setiap gateway mengumumkan hub dan sumber pengguna, tidak ada yang lain, sehingga suatu situs tidak pernah mempelajari LAN situs lain. Keepalive memelihara pemetaan NAT pada uplink situs; itu tidak mengotorisasi lalu lintas, dan firewall tetap memutuskan apa yang diizinkan. Menyalin konfigurasi satu gateway ke yang lain tidak masalah asalkan kunci privat, alamat antarmuka, dan alias semuanya berubah.

Apa yang harus diizinkan hub antara dua peernya

Hub meneruskan paket antara dua peernya sendiri, yang merupakan keputusan di rantai forward dan bukan keputusan masukan. Aktifkan penerusan IPv4 melalui mekanisme biasa platform, lalu izinkan persis pasangan yang dibutuhkan desain.

Aturan di bawah mengizinkan pengguna ke satu alias dan satu port, serta mengizinkan lalu lintas balik melalui pelacakan koneksi. Aturan itu menjatuhkan semua yang lain di jalur forward, dan itulah intinya:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

Dua detail layak disebut karena menyebabkan kegagalan senyap. Accept di satu rantai dasar tidak menimpa drop di rantai lain, jadi gabungkan ini dengan kebijakan yang ada alih-alih memuatnya di sampingnya. Dan alamat sumber mengidentifikasi perangkat, bukan orang; pisahkan autentikasi aplikasi dari penerimaan jaringan.

Di mana alias menjadi alamat nyata

Situs A menerima permintaan untuk 10.77.1.20, menulis ulang tujuan ke aplikasi sebenarnya, dan menulis ulang sumber ke alamat LAN-nya sendiri agar balasannya dapat kembali tanpa rute ke terowongan. Melakukan kedua terjemahan di satu tempat membuat sisa jaringan tidak tahu tentang alias. Aturan di bawah adalah seluruh mekanismenya:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

Kebijakan forward situs A kemudian harus mengizinkan aliran yang diterjemahkan dari antarmuka terowongan ke antarmuka LAN, ditambah arah balik. Hook forward melihat tujuan setelah terjemahan tujuan dan sebelum penulisan ulang sumber, itulah sebabnya aturan tersebut menyebut alamat aplikasi sebenarnya. Baca kedua hook itu dalam urutan itu setiap kali sebuah aturan tampak tidak cocok dengan apa pun. Aturan forward yang ditulis terhadap alias tidak akan pernah cocok, karena alias tidak lagi ada di hook itu.

Situs B mengulanginya dengan alias dan kuncinya sendiri. Ia tidak boleh menggunakan ulang kunci privat situs A, karena dua peer yang berbagi satu identitas adalah kesalahan konfigurasi yang sulit dilihat dan mudah dibuat dengan menyalin file. Jaga kedua dokumen gateway tetap identik kecuali nilai yang harus berbeda, agar perbedaannya menonjol saat ditinjau. File yang disalin adalah asal biasa dari kesalahan itu.

Penulisan ulang sumber memiliki biaya. Aplikasi melihat gateway sebagai kliennya, sehingga lognya tidak lagi menunjukkan pengguna mana yang terhubung. Pertahankan jejak audit gateway, dan jangan melemahkan login aplikasi untuk mengimbangi identitas jaringan yang dihapus oleh terjemahan.

Cara membuktikan kedua nama yang diterbitkan menjawab

Beri setiap alias nama DNS dan konfigurasikan aplikasi serta sertifikat untuk nama itu, karena terjemahan tidak menulis ulang pengalihan atau URL absolut yang tertanam. Gunakan satu nama per situs agar ketidakcocokan sertifikat tidak pernah disalahartikan sebagai kesalahan perutean.

Uji dari klien sebenarnya, konfirmasikan situs mana yang menjawab, dan uji juga port yang tidak sah. Gunakan koneksi baru setelah setiap perubahan NAT, karena status yang terbentuk mempertahankan pemetaan lama:

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

Alias kosong atau tak terduga pada perintah pertama berarti pemilihan peer salah sebelum aturan firewall mana pun penting. Jika alias benar dan nama tetap gagal, masalahnya telah berpindah ke DNS dan sertifikat. Begitu kedua nama menjawab dan port ketiga tetap tertutup, desain melakukan apa yang diklaimnya: dua layanan yang diterbitkan secara sempit, bukan dua LAN yang digabungkan.