WireGuard PersistentKeepalive: tartsa életben a NAT-leképezést

Az otthoni doboz megnyitja az alagutat, és probléma nélkül eléri a felhőszervert. A felhőszerver egy-két percig eléri az otthoni alkalmazást, miután az otthoni doboz utoljára küldött valamit, aztán leáll. Semmi sem jelenik meg a WireGuard naplójában, nem jelentkezik kézfogáshiba, és az alagút újraindítása rövid időre megjavítja. Ez a minta egy lejáró leképezés, nem törött alagút, és az alábbi útmutató megerősíti ezt, mielőtt bármit változtatnánk.

Erősítse meg, hogy a minta tétlenség miatti lejárás

A megkülönböztető részlet az időzítés. Ha a fordított kapcsolat közvetlenül azután működik, hogy az otthoni peer forgalmat küld, és egy csendes intervallum után meghibásodik, az útvonal rendben van, a középső állapot pedig nem. Ha soha nem működött, még közvetlenül forgalom után sem, akkor ez rossz diagnózis.

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

Futtassa az első kettőt közvetlenül azután, hogy az otthoni peer küldött valamit, várjon öt percet, és futtassa őket újra. Az ütemezés szerint megújuló kézfogás-időbélyeg új végpont nélkül azt mondja, hogy az alagút él. Ami változott, az a nem kért csomagok kívülről érkezésének képessége, ami az útvonal, nem az alagút tulajdonsága.

Ezután tegyen egy fordított kísérletet, és figyelje az átviteli számlálókat. Ha a felhőoldal bájtokat küld, az otthoni oldal pedig egyet sem kap, a csomag elhagyta a felhőt, és útközben egy állapotot tartó eszközben halt meg. Ez az a nyom, amit keres. Ha mindkét számláló mozog, az alagút kézbesítette a csomagot, és az alkalmazás a gyanús.

Tegye a keepalive-ot a router mögötti peerre

Az állandó keepalive-ok ütemezés szerint küldött kis hitelesített csomaggal tartják életben a NAT-leképezést és bármilyen tűzfalállapotot. A beállítás a router mögötti géphez tartozik, annak a távoli peerhez szóló bejegyzésébe, mert az az oldal hozza létre a kimenő csomagjával az állapotot.

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

Olvassza be a meglévő peer szakaszba. Egy második blokk hozzáadása ugyanazzal a nyilvános kulccsal nem érvényes módja a beállítások hozzáadásának, és a wg-quick nem olvasztja össze őket helyetted. A dokumentált 25 másodperc egy példa, amelyet arra választottak, hogy a szokásos UDP-időtúllépések alatt legyen, nem különleges jelentésű érték.

Ugyanannak az utasításnak a felhőoldalra tétele nem segít ezen a problémán. Annak a peernek a csomagjai már nyilvános címről érkeznek, tehát a fontos irányban nincs mit megőrizni. Forgalmat ad hozzá, és semmit sem változtat.

Olvassa le az időzítőket, ne tippeljen intervallumot

A keepalive-ok azért működnek, mert gyakrabban érkeznek, mint ahogy az állapot lejár. Ez teszi az időtúllépést azzá a számmá, amelyre valóban szüksége van, és Linuxon az a készülék olvassa, amelyik a fordítást végzi:

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

Az első érték az egyirányban látott UDP-folyam időtúllépése, a második pedig akkor érvényes, ha már válaszokat is megfigyeltek. Mindkettő általában rövid, és az elhallgató leképezés azt követi, ami az Ön folyamára érvényes.

Hasonlítsa össze ezt a számot az intervallumával. A 25 másodperces keepalive 30 másodperces időtúllépés alatt működik; ugyanaz a keepalive 15 másodperces időtúllépés alatt nem működik. Semmilyen újrapróbálkozás nem változtat ezen az aritmetikán. Egyes fogyasztói routerek és mobilszolgáltatók sokkal rövidebb értékeket használnak a Linux alapértelmezésénél, ezért az egyik hálózaton működő konfiguráció a másikon meghiúsul.

Ellenőrizze a figyelőt és a tűzfalat külön

Az élő leképezés szükséges, de nem elégséges. Az otthoni dobozon futó alkalmazásnak a helyes címen kell figyelnie, és a gazda tűzfalának engedélyeznie kell a csomagot a visszafejtés után.

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

Ha a socket csak a fizikai interfész címéhez van kötve, nem az alagút címéhez, az alagúton érkező csomagok eldobódnak, mielőtt a tűzfalat egyáltalán megkérdeznék. Ez a hiba a felhőoldalról pontosan leképezési problémának látszik, és minden keepalive-módosítást túlél.

Az engedélyezett lista ellenőrzése a másik irányban ugyanolyan fontos. A felhőpeernek forrásként engedélyeznie kell az otthoni alagút címét, ha válaszolni fog, az otthoni peernek pedig célként kell engedélyeznie a felhőcímét. A keepalive csomagok hitelesített forgalom, és ugyanazokat a szabályokat alkalmazzák, ezért egy működőnek tűnő keepalive együtt létezhet egy nem működő alkalmazással.

Vezesse be a változtatást, és ismerje a korlátait

Alkalmazza a beállítást, indítsa újra az interfészt, ha ez az Ön frissítési módja, majd ismételje meg a tétlenségi tesztet az azonnali teszt helyett. Várjon tovább, mint a korábban olvasott időtúllépés, tegyen egy fordított kérést, és erősítse meg, hogy a számlálók mindkét végén mozogtak.

Jegyezze fel az intervallumot és a mért időtúllépést mellé. A router firmware-jének jövőbeli változása vagy a mobilkapcsolatra való áttérés megváltoztathatja az időtúllépést. A feljegyzés az, ami lehetővé teszi, hogy valaki újra levezesse az értéket a másolása helyett. Két szám egy sorban később egy egész vizsgálatot megspórol.

Az állandó keepalive-ok védik az állapotot. Nem nyitnak portot, nem adnak bejegyzést az engedélyezett listához, és nem teszik láthatóvá a figyelőt. Amikor a fordított kapcsolat egyáltalán nem működik, a hiba e három egyike, és a WireGuard gyorsútmutatója ugyanilyen szűk kifejezésekkel írja le a keepalive beállítást.