Cara membangun uji WireGuard dua peer yang membuktikan satu jalur

Uji WireGuard yang membawa rute default, prefiks LAN, DNS, dan pengecualian firewall tidak dapat memberi tahu Anda bagian mana yang rusak. Sederhanakan menjadi dua peer, satu pasangan alamat, dan satu layanan yang diizinkan, dan kegagalan tidak punya tempat bersembunyi. Basis yang membosankan itulah diagnosisnya. Bangun dulu; perlu lima belas menit dan menghemat sore hari yang jika tidak akan Anda habiskan untuk menduga-duga.

Yang dibuktikan basis lebih sempit dari yang diduga kebanyakan orang. Ia membuktikan bahwa dua identitas sepakat, bahwa UDP mencapai port pendengar, dan bahwa satu tujuan yang diizinkan membawa permintaan. Forwarding, NAT, rute LAN, dan DNS adalah fitur terpisah yang ditambahkan belakangan, satu per satu.

Kunci, alamat, dan satu-satunya endpoint

Buat pasangan kunci di setiap sistem dan pindahkan hanya bagian publik di antara keduanya. wg genkey | tee privatekey | wg pubkey > publickey adalah perintah satu baris yang didokumentasikan, dan ia meninggalkan kunci privat di berkas yang kemudian dapat Anda lindungi. Pilih alamat terowongan dari rentang yang tidak muncul di konfigurasi lain milik Anda, seperti 10.99.0.1/24 dan 10.99.0.2/24. Catat alamat mana milik mesin mana, karena setiap pemeriksaan berikutnya bergantung pada pemetaan itu.

Kunci privat tidak pernah berpindah. Jika sebuah uji perlu menyalinnya ke sisi lain, uji itu sudah salah. Bila kedua sistem berada di belakang NAT, setidaknya satu memerlukan port UDP yang dapat dijangkau sementara yang lain membawa Endpoint yang menunjuk ke sana, dan alamat serta port publik berada di catatan Anda, bukan dalam asumsi Anda tentang 51820.

Penerusan port yang memetakan port eksternal berbeda tetap bekerja selama Endpoint cocok dengannya. Ketidakcocokan di sini menghasilkan kesunyian alih-alih galat, karena itu layak diperiksa di atas kertas sebelum men-debug di kabel.

Bidang yang termasuk wg dan yang tidak

Himpunan bidang intinya kecil: PrivateKey dan ListenPort di bawah Interface, PublicKey, AllowedIPs, dan Endpoint di bawah Peer. Address dan DNS milik wg-quick, bukan wg itu sendiri, dan perbedaan itu menggigit begitu konfigurasi yang sama pindah ke alat lain.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs membawa dua tugas sekaligus. Ia memilih tujuan mana yang masuk terowongan, dan ia memberi wewenang kepada peer untuk memakai alamat sumber itu saat tiba. Karena itu entri cermin di sisi lain harus menyebut alamat terowongan Anda dengan tepat; /32 untuk peer yang salah terbaca sebagai masalah perutean dan berperilaku seperti masalah otorisasi. Mulai cepat WireGuard menunjukkan bentuk dua peer yang sama dengan perumusan kanonis jika Anda ingin membandingkan nama bidang.

Membaca handshake alih-alih ikon

Naikkan antarmuka melalui apa pun yang memilikinya, lalu baca keadaan alih-alih lampu status. wg show mencetak handshake terakhir per peer bersama penghitung bita, dan handshake dalam beberapa menit terakhir berarti kunci, endpoint, dan jalur UDP semuanya bekerja. Penghitung yang hanya naik satu arah adalah jawabannya sendiri, dan itu bukan kegagalan yang sama dengan handshake yang tidak pernah terjadi.

Dua kegagalan itu menyiratkan penyelidikan berbeda. Tidak ada handshake sama sekali menunjuk pada ketidakcocokan kunci, Endpoint salah, UDP diblokir, atau firewall yang menjatuhkan handshake itu sendiri. Handshake yang berhasil tetapi data tidak ke mana-mana menunjuk pada AllowedIPs, layanan yang tidak mendengarkan di alamat terowongan, atau firewall host yang menerima port untuk LAN tetapi tidak untuk antarmuka terowongan. Itu dua bagian sistem yang berbeda, dan basis memisahkannya sebelum Anda mulai mengubah aturan.

Membuktikan satu layanan yang diizinkan, lalu kebalikannya

Kirim permintaan ke alamat terowongan peer lain pada layanan yang seharusnya menjawab, dan pilih sesuatu yang lebih baik daripada ping. Jawaban ICMP yang hilang bisa jadi penyaringan host, bukan gangguan terowongan, sehingga ping yang senyap tidak membuktikan arah mana pun. Koneksi TCP ke port yang Anda tahu terbuka, atau permintaan yang mengembalikan data, memberi Anda jawaban yang dapat ditafsirkan.

Jalankan arah sebaliknya sebagai uji terpisah dengan hasilnya sendiri, karena kedua arah punya entri firewall dan AllowedIPs terpisah dan bisa gagal secara mandiri. Jika handshake bekerja tetapi permintaan tidak, masalahnya ada di jalur data, bukan di terowongan: AllowedIPs, layanan yang mendengarkan, atau firewall host. Perbaiki itu sebelum menambahkan forwarding, NAT, atau DNS, atau Anda akan menghabiskan sore hari men-debug fitur yang tidak pernah menjadi biang keladi.

Menjaga basis sebagai acuan

Simpan topologi yang bekerja dan sumber profil di tempat yang bisa Anda pulihkan, dan jauhkan dari direktori apa pun yang tersinkron ke layanan publik. Lalu tambahkan satu fitur setiap kali, mengulangi permintaan awal setelah masing-masing: forwarding, NAT, rute LAN, dan baru kemudian DNS. Setiap penambahan yang mematahkan uji kini dapat diidentifikasi, karena tidak ada yang lain bergerak.

Basis yang hanya membuat ikon hijau tidak memberi tahu Anda penambahan mana yang menyebabkan kegagalan berikutnya. Jaga satu-satunya jalur yang diizinkan tetap bekerja sebagai acuan, dan setiap perubahan berikutnya diukur terhadapnya.