Doi peers WireGuard împart un interval: care primește pachetul

Doi peers listează intervale care se ating, iar traficul ajunge la cel greșit. Nimic nu este corupt: WireGuard alege un peer potrivind destinația cu intervalele configurate, iar cea mai specifică potrivire câștigă. Înainte de a lărgi ceva, decideți care peer ar trebui să dețină care prefix.

Cel mai lung prefix câștigă în interiorul WireGuard

Fiecare intrare de peer poartă un set de prefixe de destinație. Când un pachet este rutat către interfață, implementarea caută intrarea cu cel mai specific prefix potrivit — aceeași regulă pe care o aplică un tabel de rutare. De aceea un /24 bate un /16 care îl conține, iar peer-ul mai îngust primește traficul.

Configurațiile road-warrior folosesc acest lucru în mod deliberat. Un peer deține un interval larg pentru un sit, iar gazdele individuale sunt decupate cu intrări /32 care aparțin altor peers. Modelul funcționează pentru că decupajele sunt mai specifice, nu din cauza ordinii.

Notați proprietatea ca un tabel de prefix și peer. Dacă două intrări descriu același prefix, configurația nu mai exprimă o intenție, ci o cursă.

Sistemul de operare alege mai întâi interfața

WireGuard alege doar dintre peers de pe o singură interfață. Ce interfață primește pachetul se decide mai devreme, prin tabelul de rutare al gazdei, iar o a doua rută implicită sau o rută învechită poate trimite traficul unde lista de peers nu îl vede niciodată. De aceea un diagnostic la nivel de peer poate fi corect și totuși să nu explice defecțiunea. Verificați ruta către destinație înainte de a citi configurația peer-ului, pentru că o rută care indică interfața fizică ocolește întreaga întrebare.

Instrumentul instalează de obicei acele rute din intervalele peers, ceea ce înseamnă că o modificare în lista unui peer poate redirecționa în tăcere trafic care aparținea altuia. Editarea unui peer este, prin urmare, o schimbare de rutare deghizată. Examinați ambele deodată, altfel îl reparați pe unul și îl stricați pe celălalt.

Pachetele primite sunt verificate după sursă

Lista de intervale îndeplinește o dublă funcție. Pentru traficul de ieșire alege un peer după destinație, iar pentru traficul de intrare autorizează o adresă de sursă. Un pachet care sosește de la o adresă din afara intervalelor acelui peer este aruncat înainte ca vreun firewall să îl vadă.

Această asimetrie este ușor de ratat când citiți o singură parte a configurației. Un peer care poate ajunge la o subrețea nu este prin aceasta autorizat să trimită din acea subrețea, iar cele două direcții sunt impuse de verificări diferite.

Proprietatea îngustă a sursei transformă acest lucru într-un avantaj. Dați fiecărui peer un /32 pentru propria adresă, iar firewall-ul din aval are o sursă de încredere cu care să se potrivească, în locul unui interval la nivel de grup pe care orice membru l-ar putea revendica.

Intervalele duplicate nu sunt failover

Atribuirea aceluiași prefix la doi peers nu creează un balansator de încărcare sau o cale de rezervă. Nu există verificare a stării și nici afinitate de sesiune: intrarea câștigătoare este decisă de ordinea internă a implementării, ceea ce nu este un contract pe care ar trebui să proiectați. Dacă aveți nevoie de ieșiri alternative, exprimați-le acolo unde selecția este definită. O politică de rutare, o metrică sau o pereche de prefixe distincte cu un proprietar documentat pentru fiecare produc un comportament pe care îl puteți prezice și testa.

Lărgirea unui interval pentru a repara o defecțiune fără legătură este cealaltă greșeală obișnuită. Îndepărtează traficul de peer-ul care funcționa, iar noul simptom apare înainte ca cel vechi să fie înțeles.

Verificați selecția înainte de a edita

Trei comenzi răspund celor trei întrebări în ordine. Prima listează intervalele pe care le revendică fiecare peer. A doua arată ce interfață ar folosi gazda pentru o destinație. A treia arată starea live a peers după ce traficul a circulat.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

Rulați-le înainte și după o modificare și comparați. Dacă ieșirea rutei s-a schimbat, dar traficul ajunge în continuare la peer-ul greșit, listele de prefixe se suprapun într-un mod pe care încă nu l-ați notat. Dacă ieșirea rutei nu s-a schimbat, configurația peer-ului nu a fost niciodată ceea ce era consultat.

Notați în tichet destinația, interfața aleasă și peer-ul ales. Exact acel triplet face o suprapunere verificabilă mai târziu și este mult mai util decât o captură de ecran a configurației.