La hejma skatolo malfermas la tunelon kaj atingas la nuban servilon senprobleme. La nuba servilo povas atingi la hejman aplikaĵon dum unu aŭ du minutoj post kiam la hejma skatolo laste sendis ion, kaj tiam ĝi haltas. Nenio aperas en la protokolo de WireGuard, neniu manprema eraro estas raportata, kaj restartigi la tunelon riparas ĝin mallonge. Tiu ŝablono estas mapado kiu eksvalidiĝas, ne rompita tunelo, kaj la gvidilo sube konfirmas tion antaŭ ol ŝanĝi ion ajn.

Konfirmu, ke la ŝablono estas eksvalidiĝo dum senaktiveco

La distinga detalo estas la tempo. Se la inversa konekto funkcias tuj post kiam la hejma samtavolano sendas trafikon kaj malsukcesas post kvieta intervalo, la vojo estas en ordo kaj la stato en la mezo ne estas. Se ĝi neniam funkciis, eĉ tuj post trafiko, tio estas malĝusta diagnozo.

sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transfer

Rulu la unuajn du tuj post kiam la hejma samtavolano sendas ion, atendu kvin minutojn kaj rulu ilin denove. Manprema tempomarko, kiu renoveblas laŭ la horaro sen nova finpunkto, diras al vi, ke la tunelo vivas. Kio ŝanĝiĝis estas la kapablo de nepeticitaj pakaĵoj alveni de ekstere, kio estas eco de la vojo, ne de la tunelo.

Poste faru inversan provon kaj observu la transigajn nombrilojn. Se la nuba flanko sendas bajtojn kaj la hejma flanko ricevas neniom, la pakaĵo forlasis la nubon kaj mortis en aparato, kiu konservas staton, sur la vojo. Tio estas la subskribo, kiun vi serĉas. Se ambaŭ nombriloj moviĝas, la tunelo liveris la pakaĵon kaj la aplikaĵo estas la suspektato.

Metu la keepalive sur la samtavolanon malantaŭ la enkursigilo

Konstantaj keepalive konservas NAT-mapadon kaj ajnan fajroŝirman staton viva per sendo de malgranda aŭtentigita pakaĵo laŭ horaro. La agordo apartenas al la maŝino malantaŭ la enkursigilo, en ĝia enskribo por la fora samtavolano, ĉar tiu estas la flanko, kies elira pakaĵo kreas la staton.

[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25

Kunfandu ĝin en la ekzistantan samtavolanan sekcion. Aldoni duan blokon kun la sama publika ŝlosilo ne estas valida maniero aldoni opciojn, kaj wg-quick ne kunfandos ilin por vi. La dokumentitaj 25 sekundoj estas ekzemplo elektita por esti sub kutimaj UDP-tempolimoj, ne valoro kun iu speciala signifo.

Meti la saman direktivon sur la nuban flankon ne helpas ĉi tiun problemon. La pakaĵoj de tiu samtavolano jam alvenas de publika adreso, do ne estas mapado konservenda en la direkto, kiu gravas. Ĝi aldonas trafikon kaj ŝanĝas nenion.

Legu la tempigilojn anstataŭ diveni intervalon

Keepalive funkcias ĉar ili alvenas pli ofte ol la stato eksvalidiĝas. Tio faras la tempolimon la nombro, kiun vi efektive bezonas, kaj en Linux ĝi estas legebla sur la aparato, kiu faras la tradukon:

sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820

La unua valoro estas la tempolimo por UDP-fluo vidita nur en unu direkto, kaj la dua validas post kiam respondoj estis observitaj. Ambaŭ estas kutime mallongaj, kaj mapado, kiu silentas, sekvos tion, kio validas por via fluo.

Komparu tiun nombron kun via intervalo. Keepalive de 25 sekundoj sub tempolimo de 30 sekundoj funkcias; la sama keepalive sub tempolimo de 15 sekundoj ne funkcias. Neniu kvanto da ripetado ŝanĝas tiun aritmetikon. Iuj konsumantaj enkursigiloj kaj poŝtelefonaj operatoroj uzas multe pli mallongajn valorojn ol la Linux-aprioritato, tial agordo, kiu funkcias en unu reto, malsukcesas en alia.

ObservationWhat it meansReasonable response
Works after traffic, dies when idleMapping or firewall state expiringLower the keepalive interval
Never works, even immediatelyNo return route, listener or firewallStop tuning keepalive
Works for hours, then dies onceCarrier-side translation or address changeCheck the endpoint and logs together

Kontrolu la aŭskultanton kaj la fajroŝirmilon aparte

Viva mapado estas necesa kaj ne sufiĉa. La aplikaĵo sur la hejma skatolo devas aŭskulti je la ĝusta adreso, kaj la gastiga fajroŝirmilo devas permesi la pakaĵon post kiam ĝi estas malĉifrita.

sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/health

Se la ingo estas ligita nur al la adreso de la fizika interfaco kaj ne al la tunela adreso, pakaĵoj alvenantaj sur la tunelo estas forĵetitaj antaŭ ol la fajroŝirmilo eĉ konsultiĝas. Tiu fiasko aspektas de la nuba flanko idente kiel mapada problemo, kaj ĝi postvivas ĉiun keepalive-ĝustigon.

La kontrolo de la permesita listo estas same grava en la alia direkto. La nuba samtavolano devas permesi la hejman tunelan adreson kiel fonton se ĝi respondos, kaj la hejma samtavolano devas permesi la nuban adreson kiel celon. Keepalive-pakaĵoj estas aŭtentigita trafiko kaj aplikas la samajn regulojn, tial keepalive, kiu ŝajnas funkcii, povas kunekzisti kun aplikaĵo, kiu ne funkcias.

Eldonu la ŝanĝon kaj konu ĝiajn limojn

Apliku la agordon, restartigu la interfacon se tio estas via ĝisdatiga metodo, kaj poste ripetu la senaktivecan teston anstataŭ la tujan teston. Atendu pli longe ol la tempolimo, kiun vi legis antaŭe, faru inversan peton kaj konfirmu, ke la nombriloj moviĝis ĉe ambaŭ finoj.

Notu la intervalon kaj la mezuritan tempolimon apud ĝi. Estonta ŝanĝo al la firmvaro de la enkursigilo, aŭ transiro al poŝtelefona konekto, povas ŝanĝi la tempolimon. La noto estas tio, kio ebligas al iu redevenigi la valoron anstataŭ kopii ĝin. Du nombroj en unu linio ŝparas tutan enketon poste.

Konstantaj keepalive protektas staton. Ili ne malfermas pordon, ili ne aldonas enskribon al la permesita listo, kaj ili ne igas aŭskultanton aperi. Kiam la inversa konekto tute ne funkcias, la kulpo estas unu el tiuj tri, kaj la rapida gvidilo de WireGuard priskribas la keepalive-agordon per la samaj mallarĝaj terminoj.

Rilataj artikoloj