WireGuardi käepigistus töötab, kuid kontori alamsuud ei vasta

Käepigistus lõpeb, wg show teatab hiljutisest ülekandest ja serveri tunneliaadress vastab pingile. Serveri LAN-is olev host aga mitte. Kolm tingimust peavad kehtima korraga: klient peab suunama LAN-i prefiksi tunnelisse, server peab paketid edasi saatma ja vastus vajab tagasiteed. Kui üks kolmest puudub, on sümptom identne.

AllowedIPs on nii juurdepääsuloend kui ka marsruutimistabel

Kliendis otsustab loend AllowedIPs nii selle, mida tohib sellele partnerile saata, kui ka selle, millised marsruudid WireGuard paigaldab. Partnerikirje, mis loetleb ainult serveri tunneliaadressi, paigaldab ühe hosti marsruudi, nii et LAN-i sihtkohad ei satu kunagi tunnelisse. LAN-i prefiksi lisamine on esimene asi, mida kontrollida, ja see on ka muudatus, mis pärast kopeeritud konfiguratsiooni kõige sagedamini puudub. Vaikimisi marsruudiks laiendatud partner on teistsugune lahendus ja liigutab ka kliendi internetiliiklust.

Hoidke hosti marsruut ja LAN-i prefiks eraldi kirjetena. Kui kontoril on kaks alamsuuda, kuuluvad mõlemad loendisse, ja puuduv teine prefiks tekitab tõrke, mis tundub valikuline, mitte täielik.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Edastamine ja tõlkimine kuuluvad serverisse

Server vajab lubatud IP-edastust, edastusreeglit, mis võtab vastu tunnelist saabuvat liiklust, ja tõlkereeglit tema LAN-liidese suunas. Just tõlkimine paneb lahenduse toimima ilma kontori võrgu iga hosti puutumata. Siis naasevad vastused serverisse, mitte aadressile, millest LAN pole kunagi kuulnud. Ilma selleta vajab iga host tunnelialamsuuda marsruuti ja seda lubavat tulemüürireeglit, mis on harva vastuvõetav võrgus, mida haldab keegi teine.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Käsitsi lisatud reeglid kaovad taaskäivitamisel, seega siduge need liidesega serveri konfiguratsiooni hook-käskude abil. Reeglistik, mis elab oma liidesest kauem, on viis, kuidas masin hakkab lõpuks tõlkima liiklust tunnelile, mida enam ei ole.

Kui LAN kolis ja reegel mitte

Ruuteri vahetamine, mis kontori alamsuuda ümber nummerdab, on selle tõrke klassikaline versioon. Tunnel jääb püsti, käepigistus jääb värskeks ja midagi serveri taga ei vasta, sest tõlkereegel nimetab endiselt vana aadressi. Paigaldusskriptid kirjutavad serveri LAN-aadressi sageli POSTROUTING-reeglisse, ja pärast ümbernummerdamist ei ole seda aadressi üheski liideses. Seejärel kirjutatakse paketid ümber sihtkohta, mis ei suuda vastata.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Võrrelge kahte väljundit. Tõlkesisu, mis liideste loendis ei esine, on viga, ja selle parandamine on ühe rea muudatus, kui olete selle kord näinud. Reegel võib elada genereeritud üksuses, mitte WireGuardi konfiguratsioonis, seega laadige see üksus pärast muutmist uuesti ja veenduge, et järgmine alglaadimine teie muudatust üle ei kirjuta.

Kaks NAT-i taga olevat kohta vajavad kohtumispaika

Kui kumbki pool sissetulevaid ühendusi vastu ei võta, on praktiline vastus väike host avaliku aadressi ja kahe WireGuardi liidesega. Iga koht ühendub väljapoole, keskmine host loetleb iga partneri LAN-i omaenda AllowedIPs, ja edastamine kannab pakette kahe tunneli vahel. Kummagi koha tulemüüris ei pea midagi muutuma, mistõttu see lahendus levib kergesti.

Kohtade vaheline marsruutimine säilitab algse lähteaadressid ja hoiab seega hostipõhise logimise mõttekana. Keskmises hostis tõlkimine on lihtsam, kui kaks LAN-i kattuvad, kuid selle hinnaks on lähteidentiteedi kaotamine logides. Otsustage, milline omadus on oluline, enne kui valite.

Eraldage kihid nelja kontrolliga

Tehke üks kontroll kihi kohta, selle asemel et muuta kolme asja ja loota. Esimene näitab käepigistuse vanust ja loendureid iga partneri kohta. Teine näitab, kas klient tõesti suunab selle sihtkoha tunnelisse. Kolmas ja neljas ütlevad, kas päring jõudis kohale ja kas mõni poliitika selle pärast saabumist kõrvaldas.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Päring, mis jõuab kohale ja ei tekita vastust, osutab vastuse teele või LAN-i hostile. Päring, mis ei jõua kunagi kohale, osutab AllowedIPs või kliendi marsruudile. Need kaks tulemust vajavad erinevaid parandusi ja just salvestus eristab neid.