Како да изградите 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. Секој додаток што го крши тестот сега е препознатлив, бидејќи ништо друго не се помести.

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