Како изградити WireGuard тест са два пера који доказује једну путању

WireGuard тест који носи подразумевану руту, LAN префикс, DNS и изузетак у заштитном зиду не може да каже која је од тога покварена. Сведите га на два пера, један пар адреса и једну дозвољену услугу, и квар нема где да се сакрије. Досадна основа је дијагноза. Направите је прво; траје петнаест минута и штеди поподне које бисте иначе провели нагађајући.

Оно што основа доказује уже је него што већина очекује. Доказује да се два идентитета слажу, да UDP стиже до порта за слушање и да једна дозвољена дестинација носи захтев. Прослеђивање, NAT, LAN руте и DNS су одвојене функције које се додају касније, једна по једна.

Кључеви, адресе и једини endpoint

Генеришите пар кључева на сваком систему и пренесите између њих само јавне половине. wg genkey | tee privatekey | wg pubkey > publickey је документована једноредна команда и оставља приватни кључ у датотеци коју затим можете заштитити. Изаберите адресе тунела из опсега који се не појављује ни у једној другој вашој конфигурацији, на пример 10.99.0.1/24 и 10.99.0.2/24. Запишите која адреса припада којој машини, јер свака каснија провера зависи од тог мапирања.

Приватни кључеви никада не путују. Ако тесту треба један копиран на другу страну, тест је већ пошао наопако. Када су два система иза NAT-а, бар једном је потребан доступан UDP порт док други носи Endpoint који показује на њега, а јавна адреса и порт припадају вашим белешкама, а не претпоставкама о 51820.

Преусмеравање порта које мапира други спољни порт ради добро све док му Endpoint одговара. Неподударности овде производе тишину, а не грешке, зато их вреди проверити на папиру пре отклањања грешака на жици.

Поља која припадају wg и она која не

Основни скуп поља је мали: PrivateKey и ListenPort под Interface, PublicKey, AllowedIPs и Endpoint под Peer. Address и DNS припадају wg-quick, а не самом wg, и та разлика уједа оног тренутка када иста конфигурација пређе у други алат.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs носи два посла одједном. Бира које дестинације иду у тунел, и овлашћује пера да користи те изворне адресе по доласку. Због тога огледални унос на другој страни мора тачно да наведе адресу вашег тунела; /32 за погрешног пера чита се као проблем рутирања и понаша се као проблем ауторизације. Брзи почетак WireGuard-а приказује исти облик са два пера са канонском формулацијом ако желите да упоредите називе поља.

Читање руковања уместо иконе

Подигните интерфејс кроз оно што га поседује, затим читајте стање, а не статусну лампицу. wg show исписује последње руковање по перу заједно са бројачима бајтова, а руковање у последњих неколико минута значи да кључеви, endpoint и UDP путања сви раде. Бројач који расте само у једном смеру је сам себи одговор и није исти квар као руковање које се никада не догоди.

Два квара подразумевају различите истраге. Потпуно одсуство руковања указује на неслагање кључева, погрешан Endpoint, блокиран UDP или заштитни зид који одбацује само руковање. Руковање које успева док подаци не иду никуда указује на AllowedIPs, услугу која не слуша на адреси тунела, или заштитни зид хоста који прихвата порт за LAN али не за интерфејс тунела. То су различите половине система, и основа их раздваја пре него што почнете да мењате правила.

Доказивање једне дозвољене услуге, затим обрнуто

Пошаљите захтев на адресу тунела другог пера на услугу која треба да одговори, и изаберите нешто боље од ping-а. Недостајући ICMP одговор може бити филтрирање хоста, а не квар тунела, па тихи ping не доказује ниједан смер. TCP веза ка порту за који знате да је отворен, или захтев који враћа податке, даје вам одговор који можете протумачити.

Покрените обрнути смер као одвојен тест са сопственим резултатом, јер два смера имају одвојене уносе заштитног зида и AllowedIPs и могу независно да не успеју. Ако руковање ради, а захтев не, проблем је у путањи података, а не у тунелу: AllowedIPs, услуга која слуша или заштитни зид хоста. Поправите то пре него што додате прослеђивање, NAT или DNS, иначе ћете провести поподне отклањајући грешке у функцији која никада није била крива.

Одржавање основе као референце

Сачувајте радну топологију и извор профила на месту са којег можете да вратите, и држите их изван сваког директоријума који се синхронизује са јавном услугом. Затим додајте једну функцију по једну, понављајући оригинални захтев после сваке: прослеђивање, NAT, LAN руту и тек онда DNS. Сваки додатак који поквари тест сада је препознатљив, јер се ништа друго није померило.

Основа која само обоји икону зелено није вам рекла ништа о томе који је додатак изазвао следећи квар. Држите једину дозвољену путању у функцији као референцу, и свака каснија промена мери се према њој.