Dua tapak, satu subnet, satu hab WireGuard: buat ia berfungsi

Kedua-dua tapak menggunakan julat LAN yang sama, dan pertindihan bukanlah perkara yang sebenarnya merosakkan reka bentuk. Hab mesti memilih tapak menggunakan alamat destinasi sahaja, dan dua destinasi yang serupa tidak memberinya apa-apa untuk dipilih. Menomborkan semula pejabat yang berfungsi untuk memenuhi terowong biasanya merupakan pertukaran yang lebih buruk daripada memberi setiap perkhidmatan yang diterbitkan alamat berbeza yang boleh dibawa oleh terowong. Reka bentuk di bawah menerbitkan satu perkhidmatan HTTPS setiap tapak dan tiada yang lain.

Mengapa pertindihan bukan masalah sebenar

WireGuard memajukan mengikut destinasi: AllowedIPs sesuatu peer menentukan peer mana yang menerima paket. Dua peer tidak boleh kedua-duanya mengumumkan 10.10.7.0/24 tanpa salah satu daripada mereka memenangi setiap carian. Itu sifat jadual peer, bukan terowong, sebab itu penyelesaian di sini ialah pelan alamat, bukan helah penghalaan.

Pelannya ialah berhenti mengumumkan LAN sama sekali. Umumkan alias bagi setiap perkhidmatan sebagai gantinya, satu alamat setiap tapak, dan biarkan get laluan setiap tapak menterjemah alias itu kepada aplikasi sebenarnya.

Pengguna menghala dua alamat unik, tidak pernah melihat awalan yang kabur, dan tiada apa-apa berubah di kedua-dua pejabat. Ini juga menyatakan sempadan dengan jujur: anda menerbitkan satu perkhidmatan HTTPS dari setiap tapak, bukan menggabungkan dua rangkaian. Peraturan berikut kekal kecil kerana pernyataannya sempit. Pernyataan yang lebih luas memerlukan peraturan yang lebih luas, dan begitulah reka bentuk ini menjadi rumit.

Berikan setiap tapak alias yang boleh dihala oleh pengguna

Pilih alamat daripada julat yang tidak berkonflik dengan apa-apa pada mesin pengguna, hab atau mana-mana satu daripada dua LAN. Di sini hab ialah 10.66.0.1, pengguna ialah 10.66.0.10, get laluan ialah 10.66.0.21 dan 10.66.0.22, dan dua alias ialah 10.77.1.20 dan 10.77.2.20. Hab menerbitkan setiap alias melalui peer yang memilikinya, jadi paket keluar yang dialamatkan kepada satu alias hanya boleh keluar melalui tapak yang sepadan:

[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

Bahagian pengguna hanya memerlukan dua alias, yang mengekalkan konfigurasi klien bebas daripada kedua-dua awalan LAN. Tiada apa-apa dalam konfigurasi itu menyebut mana-mana LAN sebenar:

[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 get laluan mengumumkan hab dan sumber pengguna, tiada yang lain, jadi satu tapak tidak pernah mengetahui LAN tapak yang lain. Keepalive mengekalkan pemetaan NAT pada pautan atas tapak; ia tidak memberi kuasa kepada trafik, dan tembok api masih menentukan apa yang diterima. Menyalin konfigurasi satu get laluan ke yang lain adalah wajar asalkan kunci peribadi, alamat antara muka dan alias semuanya berubah.

Apa yang hab mesti benarkan antara dua peernya

Hab memajukan paket antara dua peernya sendiri, yang merupakan keputusan dalam rantaian forward dan bukan keputusan input. Dayakan pemajuan IPv4 melalui mekanisme biasa platform, kemudian benarkan tepat pasangan yang diperlukan oleh reka bentuk.

Peraturan di bawah membenarkan pengguna ke satu alias dan satu port, dan membenarkan trafik balik melalui penjejakan sambungan. Ia menggugurkan segala yang lain pada laluan 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 butiran wajar dinyatakan kerana ia menyebabkan kegagalan senyap. Accept dalam satu rantaian asas tidak mengatasi drop dalam rantaian lain, jadi cantumkan ini dengan dasar sedia ada dan bukan memuatkannya di sebelahnya. Dan alamat sumber mengenal pasti peranti, bukan orang; asingkan pengesahan aplikasi daripada kemasukan rangkaian.

Di mana alias menjadi alamat sebenar

Tapak A menerima permintaan untuk 10.77.1.20, menulis semula destinasi kepada aplikasi sebenar, dan menulis semula sumber kepada alamat LAN sendiri supaya balasan boleh kembali tanpa laluan ke terowong. Melakukan kedua-dua terjemahan di satu tempat mengekalkan seluruh rangkaian tidak mengetahui tentang alias. Peraturan di bawah ialah keseluruhan mekanisme:

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

Dasar forward tapak A kemudian mesti menerima aliran yang diterjemahkan daripada antara muka terowong ke antara muka LAN, ditambah arah balik. Cangkuk forward melihat destinasi selepas terjemahan destinasi dan sebelum penulisan semula sumber, sebab itu peraturan itu menamakan alamat aplikasi sebenar. Baca kedua-dua cangkuk itu dalam urutan itu setiap kali sesuatu peraturan kelihatan tidak sepadan dengan apa-apa. Peraturan forward yang ditulis terhadap alias tidak boleh sepadan, kerana alias itu tidak lagi wujud pada cangkuk itu.

Tapak B mengulangi ini dengan alias dan kuncinya sendiri. Ia tidak boleh menggunakan semula kunci peribadi tapak A, kerana dua peer yang berkongsi satu identiti ialah kesilapan konfigurasi yang sukar dilihat dan mudah dicipta dengan menyalin fail. Kekalkan kedua-dua dokumen get laluan sama kecuali nilai yang mesti berbeza, supaya perbezaannya menonjol semasa semakan. Fail yang disalin ialah asal biasa kesilapan itu.

Penulisan semula sumber mempunyai kos. Aplikasi melihat get laluan sebagai kliennya, jadi lognya tidak lagi menunjukkan pengguna mana yang bersambung. Kekalkan jejak audit get laluan, dan jangan melemahkan log masuk aplikasi untuk mengimbangi identiti rangkaian yang telah dibuang oleh terjemahan.

Cara membuktikan kedua-dua nama yang diterbitkan menjawab

Berikan setiap alias nama DNS dan konfigurasikan aplikasi serta sijil untuk nama itu, kerana terjemahan tidak menulis semula ubah hala atau URL mutlak terbenam. Gunakan satu nama setiap tapak supaya ketidakpadanan sijil tidak pernah disalah anggap sebagai kerosakan penghalaan.

Uji daripada klien sebenar, sahkan tapak mana yang menjawab, dan uji juga port yang tidak dibenarkan. Gunakan sambungan baharu selepas apa-apa perubahan NAT, kerana keadaan yang terjalin mengekalkan 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 tidak dijangka dalam arahan pertama bermakna pemilihan peer salah sebelum mana-mana peraturan tembok api penting. Jika alias betul dan nama itu masih gagal, masalahnya telah berpindah ke DNS dan sijil. Sebaik sahaja kedua-dua nama menjawab dan port ketiga kekal tertutup, reka bentuk melakukan apa yang didakwanya: dua perkhidmatan yang diterbitkan secara sempit, bukan dua LAN yang digabungkan.