WireGuard PersistentKeepalive: запазете NAT преобразуването живо

Домашната кутия отваря тунела и достига до облачния сървър без проблем. Облачният сървър може да достигне до домашното приложение за минута-две, след като домашната кутия е изпратила нещо за последно, и след това спира. В журнала на WireGuard не се появява нищо, не се съобщава за грешка при ръкостискането, а рестартирането на тунела го оправя за кратко. Този модел е изтичащо преобразуване, а не счупен тунел, и ръководството по-долу го потвърждава, преди да се промени каквото и да е.

Потвърдете, че моделът е изтичане на преобразуването при бездействие

Отличителната подробност е времето. Ако обратната връзка работи веднага след като домашният партньор изпрати трафик, и се провали след тих интервал, пътят е наред, а състоянието по средата не е. Ако никога не е работила, дори веднага след трафик, това е грешна диагноза.

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

Изпълнете първите две веднага след като домашният партньор изпрати нещо, изчакайте пет минути и ги изпълнете отново. Времева марка за ръкостискане, която се обновява по график без нова крайна точка, ви казва, че тунелът е жив. Променила се е способността на непредизвикани пакети да пристигат отвън, което е свойство на пътя, а не на тунела.

След това направете обратен опит и наблюдавайте броячите за трансфер. Ако облачната страна изпраща байтове, а домашната не получава нищо, пакетът е напуснал облака и е загинал в устройство, което помни състояние, по пътя. Това е подписът, който търсите. Ако и двата брояча се движат, тунелът е доставил пакета и заподозреният е приложението.

Поставете keepalive на партньора зад рутера

Постоянните keepalive поддържат преобразуването на NAT и всяко състояние на защитната стена живо, като изпращат малък удостоверен пакет по график. Настройката принадлежи на машината зад рутера, в нейния запис за отдалечения партньор, защото това е страната, чийто изходящ пакет създава състоянието.

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

Слейте го в съществуващата секция на партньора. Добавянето на втори блок със същия публичен ключ не е валиден начин за добавяне на опции и wg-quick няма да ги слее вместо вас. Документираните 25 секунди са пример, избран да стои под обичайните UDP таймаути, а не стойност със специално значение.

Поставянето на същата директива от облачната страна не помага на този проблем. Пакетите на този партньор вече пристигат от публичен адрес, така че няма преобразуване, което да се пази в важната посока. Добавя трафик и не променя нищо.

Четете таймерите, вместо да гадаете интервал

Keepalive работят, защото пристигат по-често, отколкото състоянието изтича. Това прави таймаута числото, което всъщност ви трябва, и в Linux то се чете на устройството, което прави преобразуването:

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

Първата стойност е таймаутът за UDP поток, виждан само в една посока, а втората важи, след като бъдат забелязани отговори. И двете обикновено са кратки, а преобразуване, което замлъкне, ще следва това, което важи за вашия поток.

Сравнете това число с вашия интервал. Keepalive от 25 секунди при таймаут 30 секунди работи; същият keepalive при таймаут 15 секунди не работи. Никакво повторение не променя тази аритметика. Някои потребителски рутери и мобилни оператори използват много по-кратки стойности от подразбирането на Linux, затова конфигурация, която работи в една мрежа, се проваля в друга.

Проверете слушателя и защитната стена поотделно

Живото преобразуване е необходимо и недостатъчно. Приложението на домашната кутия трябва да слуша на правилния адрес, а защитната стена на хоста трябва да разреши пакета, след като бъде дешифриран.

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

Ако сокетът е свързан само към адреса на физическия интерфейс, а не към адреса на тунела, пакетите, пристигащи по тунела, се изхвърлят, преди да се погледне защитната стена. Този отказ изглежда от облачната страна точно като проблем с преобразуването и оцелява при всяка настройка на keepalive.

Проверката на списъка с разрешени е също толкова важна в другата посока. Облачният партньор трябва да разреши адреса на домашния тунел като източник, ако ще отговаря, а домашният партньор трябва да разреши облачния адрес като дестинация. Пакетите keepalive са удостоверен трафик и прилагат същите правила, затова keepalive, който изглежда работещ, може да съществува заедно с приложение, което не работи.

Пуснете промяната и познавайте границите ѝ

Приложете настройката, рестартирайте интерфейса, ако това е начинът ви за обновяване, и след това повторете теста за бездействие, а не незабавния тест. Изчакайте по-дълго от таймаута, който прочетохте по-рано, направете обратна заявка и потвърдете, че броячите са се движили от двете страни.

Запишете интервала и измерения таймаут до него. Бъдеща промяна на фърмуера на рутера или преминаване към мобилна връзка може да промени таймаута. Бележката позволява на някого да изведе стойността отново, вместо да я копира. Две числа на един ред спестяват цяло разследване по-късно.

Постоянните keepalive защитават състояние. Те не отварят порт, не добавят запис в списъка с разрешени и не карат слушател да се появи. Когато обратната връзка не работи изобщо, вината е в едно от тези три, а бързият старт на WireGuard описва настройката keepalive в същите тесни условия.