WireGuard toant gjin lêste hânskod: wat jo earst kontrolearje moatte

In leech fjild foar de lêste hânskod betsjut meast dat de ynterface sûnt it opkommen gjin hânskod foltôge hat, wat minder oer de konfiguraasje seit as it liket. WireGuard bliuwt stil oant in pakket de ynterface ferlitte moat, dus in idle peer sûnder wat te stjoeren rapportearret krekt dat. Stel fêst oft der echt wat oanbean is foardat jo de kaaien ûndersykje.

De test is in tastien pakket nei in bestimming dy’t de peer drage moat. Al it oare op dat statusskerm beskriuwt bedoeling, net aktiviteit.

In idle ynterface hat neat te rapportearjen

WireGuard docht hânskodden lulk: it earste pakket dat de tunnel nedich hat, begjint de útwikseling, en de ynterface bliuwt oant dan stil. In peer dy’t konfigurearre en nea brûkt is, toant in lege hânskod, nul bytes ûntfongen en in groeiende gat sûnt de lêste. Dy tastân is sûn foar in idle klant en allinnich alarmearjend as jo ferwachte dat ferkear al floeid wie. Kontrolearje ek de oerdrachtstellers, want dy skiede neat-stjoerd fan besocht-en-mislearre.

As de tellers oan beide kanten op nul steane, is it probleem streamop fan de tunnel. Neat berikte de ynterface om wat te begjinnen.

Aktivearje ferkear dat de peer drage mei

Kies in adres binnen de tastiene foarheaksels fan de peer, op de lokale masine, en befêstigje dat de rûtetabel it troch de ynterface stjoere soe. In bestimming bûten dy foarheaksels produsearret in gewoane rûtearre oanfraach sûnder ekstra WireGuard-belmixing. Brûk in tsjinst dy’t fluch antwurdet, lykas in ping of in koarte TCP-ferbining, sadat de poging in sichtber begjin en ein hat. Lês dan de hânskodrige wer yn stee fan it skerm te besjen en te wachtsjen.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

De rûtefraach is wichtiger as de ping. As dy de fysike ynterface neamt, is it pakket nea de tunnel yngien en is de lege hânskod in rûte-antwurd, net in kryptografysk. Reparearje de rûte foardat jo de peer debugge.

Fergelykje it kaaipear en it einpunt

As ferkear echt oanbean wurdt, is identiteit de folgjende kontrôle. De lokale priveekaai moat oerienkomme mei de publike kaai dy’t de oare kant autorisearret, de konfigurearre fiere publike kaai moat de bedoelde peer identifisearje, en in foarôf dielde kaai moat oan beide kanten oerienkomme. Ien tekenferskil yn in base64-kaai produsearret in peer dy’t konfigurearre liket en nea in útwikseling foltôget. Fergelykje mei it foarsjenningsregister yn stee fan kaaien opnij te meitsjen, want in nije kaai makket elke peer ûnjildich dy’t op de âlde fertroude.

It einpunt hat deselde kontrôle nedich: hostnamme, adres, UDP-poarte en de famylje dy’t brûkt wurdt om it te berikken. In ferâldere adres of de ferkearde poarte produsearret stilte yn stee fan in berjocht.

Hâld it bûtenste UDP-paad yn de gaten

De hânskod reizget as UDP nei it einpunt, dus it bûtenste paad moat it drage. De kommando’s hjirûnder kontrolearje oft der in listener is, oft de lokale stack it datagram stjoerd hat, en hokker einpunt konfigurearre is. Rin de opname wylst jo ferkear aktivearje, net derfoar.

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

In opname dy’t de inisjaasje sûnder antwurd toant, wiist bûten de masine, want de fiere kant harket net, is filtere of is ferkeard adressearre. In opname dy’t hielendal neat toant, betsjut dat it pakket nea fuortgien is, wat jo werombringt by de rûte en by elk socket-mark dat yn it spul is. As jo beide kanten beheare, korrelearje de poging dan op tiidstempel mei in smelle opname op de server yn stee fan in algemiene. In TCP-poartest bewiist hjir neat, want it protokol is allinnich UDP.

As der in hânskod ferskynt, test in applikaasje troch de tunnel, want in foltôge útwikseling bewiist identiteit en berikberens, net brûkbere trochfier of krekte DNS. Bewarje de statusútfier fan foar en nei de feroaring, en it ferskil wurdt jo bewiis.