WireGuard hanya berfungsi selepas pelayan menghantar: pengetahuan titik hujung

Terowong kelihatan berfungsi hanya selepas pelayan menghantar sesuatu dahulu. Mulakan dari klien dan tiada apa berlaku, tunggu beberapa saat, cuba lagi dan ia berjaya. Diagnosis biasa ialah NAT yang rosak, dan diagnosis biasa itu salah. Apa yang berubah ialah satu rakan mengetahui di mana rakan yang lain berada.

Pengetahuan titik hujung, bukan kebolehcapaian

Rakan WireGuard tidak akan memulakan jabat tangan sehingga ia tahu ke mana hendak menghantarnya. Konfigurasi menyediakannya sebagai titik hujung alamat dan port, dan keadaan berjalan menjejaki titik hujung yang dipercayainya sekarang.

wg show mencetak kedua-dua belah gambaran itu, dan rakan tanpa titik hujung dalam output tidak boleh memulakan apa-apa, walau seberapa betul kunci awam dan awalan yang dibenarkannya. Bandingkan pandangan klien dengan pandangan pelayan sebelum menukar mana-mana peraturan, kerana kedua-duanya sering tidak bersetuju tentang siapa tahu apa.

Bagaimana rakan mempelajari titik hujung

WireGuard sengaja senyap. Apabila paket yang disahkan dengan betul tiba dari alamat yang tidak dijangka oleh rakan, pelaksanaan mengemas kini titik hujung rakan itu kepada sumber baharu, dan begitulah perayauan berfungsi pada komputer riba yang bertukar rangkaian. Tingkah laku itu menjelaskan kebergantungan arah: jika pelayan menghantar dahulu dan paketnya sampai kepada klien, klien mempelajari alamat semasa pelayan dan boleh menjawab. Sehingga itu ia tiada tempat untuk menghantar. Mekanisme ini ialah perayauan yang disahkan dan bukan jalan pintas percaya pada penggunaan pertama, kerana paket itu perlu sah sebelum titik hujung bergerak.

Dokumentasi alat untuk wg menerangkan kemas kini itu, dan ia berbaloi dibaca sekali jika anda akan mereka bentuk di sekitarnya.

Terjemahan berkeadaan menambah arahnya sendiri

Di mana UDP melalui get laluan yang menterjemah, get laluan mencipta keadaan untuk paket pertama yang dilihatnya. RFC 4787 menerangkan tingkah laku itu dan had masa yang akhirnya membuang pemetaan. Pemetaan terbiar akan tamat tempoh, dan paket masuk dari sebelah jauh kemudian digugurkan oleh get laluan sebelum sampai ke hos. Terowong yang berfungsi sepanjang pagi berhenti menjawab pada petang semata-mata kerana sebab ini.

Ini ialah mekanisme kedua dan bebas yang menghasilkan gejala arah yang sama. Pengetahuan titik hujung dan keadaan terjemahan kedua-duanya mesti betul, dan membaiki satu tidak membaiki yang lain.

Konfigurasikan arah yang sebenarnya anda mahu

Untuk klien yang mesti memulakan sambungan, letakkan titik hujung pelayan dalam bahagian rakan klien dan biarkan ia di situ. Bergantung pada pelayan menghantar dahulu bermaksud bergantung pada kebetulan dalam susunan trafik yang akan berubah pada rangkaian yang tenang. Konfigurasi sepatutnya menyatakan arah yang dimaksudkan, bukan menemukannya.

Untuk rakan di belakang terjemahan yang mesti kekal boleh dicapai, dayakan keepalive berterusan di sebelah itu. Keepalive setiap 25 saat ialah nilai permulaan biasa, dan tujuannya adalah untuk mengekalkan pemetaan terbuka bukan menguji terowong. Pilih satu sebelah untuk membawanya, kerana mendayakannya pada kedua-dua belah menggandakan trafik dan bunyi log tanpa memperbaiki hasilnya.

Bandingkan keadaan sebelum dan selepas pencetus

Tangkap kedua-dua pandangan pada saat ia gagal, kemudian sekali lagi selepas pelayan menghantar. Perintah pertama menunjukkan titik hujung dan usia jabat tangan. Yang kedua menunjukkan sama ada entri terjemahan wujud untuk port itu. Tangkapan itu menunjukkan arah mana yang benar-benar melintasi wayar, dan pemeriksaan laluan mengesahkan klien tidak menghantar trafik itu ke tempat lain sama sekali.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Catat lajur titik hujung dan entri terjemahan bersama-sama. Rakan tanpa titik hujung dan get laluan tanpa pemetaan ialah dua kerosakan berbeza. Hanya satu daripadanya dibaiki oleh keepalive.