Cara membina ujian WireGuard dua rakan yang membuktikan satu laluan

Ujian WireGuard yang membawa laluan lalai, awalan LAN, DNS dan pengecualian firewall tidak dapat memberitahu anda yang mana satu rosak. Kurangkan kepada dua rakan, satu pasangan alamat dan satu perkhidmatan yang dibenarkan, dan kegagalan tidak mempunyai tempat bersembunyi. Asas yang membosankan itulah diagnosis. Bina dahulu; ia mengambil masa lima belas minit dan menjimatkan petang yang sebaliknya anda habiskan untuk meneka.

Apa yang dibuktikan oleh asas lebih sempit daripada jangkaan kebanyakan orang. Ia membuktikan bahawa dua identiti bersetuju, bahawa UDP sampai ke port mendengar dan bahawa satu destinasi yang dibenarkan membawa permintaan. Penghantaran, NAT, laluan LAN dan DNS ialah ciri berasingan yang ditambah kemudian, satu demi satu.

Kunci, alamat dan satu-satunya endpoint

Jana pasangan kunci pada setiap sistem dan pindahkan hanya separuh awam di antara mereka. wg genkey | tee privatekey | wg pubkey > publickey ialah arahan satu baris yang didokumenkan, dan ia meninggalkan kunci peribadi dalam fail yang kemudian boleh anda lindungi. Pilih alamat terowong daripada julat yang tidak muncul dalam mana-mana konfigurasi lain milik anda, seperti 10.99.0.1/24 dan 10.99.0.2/24. Catat alamat mana milik mesin mana, kerana setiap pemeriksaan kemudian bergantung pada pemetaan itu.

Kunci peribadi tidak pernah bergerak. Jika ujian perlu menyalin satu ke sisi lain, ujian itu sudah salah. Apabila kedua-dua sistem berada di belakang NAT, sekurang-kurangnya satu memerlukan port UDP yang boleh dicapai manakala yang lain membawa Endpoint yang menunjuk kepadanya, dan alamat serta port awam tergolong dalam nota anda, bukan dalam andaian anda tentang 51820.

Pemajuan port yang memetakan port luaran berbeza berfungsi dengan baik selagi Endpoint sepadan dengannya. Ketidakpadanan di sini menghasilkan kesenyapan bukan ralat, sebab itu ia wajar diperiksa di atas kertas sebelum menyahpepijat pada wayar.

Medan yang tergolong dalam wg dan yang tidak

Set medan terasnya kecil: PrivateKey dan ListenPort di bawah Interface, PublicKey, AllowedIPs dan Endpoint di bawah Peer. Address dan DNS tergolong dalam wg-quick bukan wg itu sendiri, dan perbezaan itu menggigit sebaik sahaja konfigurasi yang sama berpindah 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 serentak. Ia memilih destinasi mana yang masuk ke terowong, dan ia memberi kuasa kepada rakan untuk menggunakan alamat sumber itu apabila tiba. Sebab itu entri cermin di sisi lain mesti menamakan alamat terowong anda dengan tepat; /32 untuk rakan yang salah dibaca sebagai masalah penghalaan dan berkelakuan seperti masalah kebenaran. Mula pantas WireGuard menunjukkan bentuk dua rakan yang sama dengan perumusan kanonik jika anda mahu membandingkan nama medan.

Membaca handshake dan bukannya ikon

Naikkan antara muka melalui apa sahaja yang memilikinya, kemudian baca keadaan dan bukannya lampu status. wg show mencetak handshake terakhir setiap rakan bersama pengira bait, dan handshake dalam beberapa minit terakhir bermakna kunci, endpoint dan laluan UDP semuanya berfungsi. Pengira yang hanya naik dalam satu arah ialah jawapannya sendiri, dan ia bukan kegagalan yang sama seperti handshake yang tidak pernah berlaku.

Dua kegagalan itu membayangkan siasatan berbeza. Tiada handshake langsung menunjukkan ketidakpadanan kunci, Endpoint salah, UDP disekat atau firewall yang menjatuhkan handshake itu sendiri. Handshake yang berjaya tetapi data tidak ke mana-mana menunjukkan AllowedIPs, perkhidmatan yang tidak mendengar pada alamat terowong, atau firewall hos yang menerima port untuk LAN tetapi bukan untuk antara muka terowong. Itu dua bahagian sistem yang berbeza, dan asas memisahkannya sebelum anda mula menukar peraturan.

Membuktikan satu perkhidmatan yang dibenarkan, kemudian sebaliknya

Hantar permintaan ke alamat terowong rakan lain pada perkhidmatan yang sepatutnya menjawab, dan pilih sesuatu yang lebih baik daripada ping. Balasan ICMP yang tiada boleh jadi penapisan hos dan bukan kerosakan terowong, jadi ping senyap tidak membuktikan mana-mana arah. Sambungan TCP ke port yang anda tahu terbuka, atau permintaan yang memulangkan data, memberi anda jawapan yang boleh ditafsirkan.

Jalankan arah sebaliknya sebagai ujian berasingan dengan hasilnya sendiri, kerana kedua-dua arah mempunyai entri firewall dan AllowedIPs berasingan dan boleh gagal secara bebas. Jika handshake berfungsi tetapi permintaan tidak, masalahnya pada laluan data bukan terowong: AllowedIPs, perkhidmatan yang mendengar atau firewall hos. Betulkan itu sebelum menambah penghantaran, NAT atau DNS, jika tidak anda akan menghabiskan petang menyahpepijat ciri yang tidak pernah menjadi punca.

Menjaga asas sebagai rujukan

Simpan topologi yang berfungsi dan sumber profil di tempat yang boleh anda pulihkan, dan jauhkan daripada mana-mana direktori yang menyegerak dengan perkhidmatan awam. Kemudian tambah satu ciri pada satu masa, mengulangi permintaan asal selepas setiap satu: penghantaran, NAT, laluan LAN dan hanya kemudian DNS. Setiap penambahan yang memecahkan ujian kini boleh dikenal pasti, kerana tiada yang lain bergerak.

Asas yang hanya menjadikan ikon hijau tidak memberitahu anda apa-apa tentang penambahan mana yang menyebabkan kegagalan seterusnya. Kekalkan satu-satunya laluan yang dibenarkan berfungsi sebagai rujukan, dan setiap perubahan kemudian diukur terhadapnya.