WireGuard pilns tunelis: AllowedIPs 0.0.0.0/0 nav pietiekami

Ierakstīt 0.0.0.0/0, ::/0 partnera AllowedIPs ir solis, ko visi atceras, un tas nosaka tikai to, kādu datplūsmu partnerim ir atļauts pārnēsāt. Šie prefiksi neveido maršrutus, neko nepārsūta otrā pusē un atstāj katras lietotnes risinātāju tieši tur, kur tas bija. Četrām atsevišķām lietām jābūt patiesām vienlaikus, lai pilns tunelis būtu pilnīgs, un tās vislabāk pārbaudīt zemāk norādītajā secībā, jo vēlāka pārbaude nevar glābt agrāku. Katra zemākā pārbaude ir fakts, ko var nolasīt no mašīnas, nevis iestatījums, par kura piemērošanu jūs cerat.

Ko partnera prefikss izvēlas un ko ne

AllowedIPs ir gan atlasītājs, gan atļauja. Tas vietējai pusei norāda, uz kuriem galamērķiem drīkst sūtīt šim partnerim, un saņēmējai pusei – kādas avota adreses šis partneris drīkst uzrādīt. Tas ir viss darbs. Nekas šajā aprakstā neveido maršrutu uz resursdatora, neieslēdz pārsūtīšanu attālajā pusē un neaizskar nosaukumu atrisināšanu.

Tāpēc konfigurācija var izskatīties pilnīga un uzvesties kā sadalīts tunelis. Prefikss saka, ka partneris pieņemtu visu; resursdatora maršrutu tabula nosaka, kas tur tiešām nonāk, un vārteja nosaka, vai kaut kas iziet. Neviens no šiem trim lēmumiem nedzīvo partnera sadaļā.

Maršrutēt klientu, ne tikai partneru sarakstu

Pārvaldnieki, piemēram, wg-quick programmē resursdatora maršrutu tabulu jūsu vietā, tāpēc divi identiski konfigurācijas faili uzvedas atšķirīgi atkarībā no tā, kā saskarne tika pacelta. Minimālais profils ir pietiekami īss, lai to izlasītu vienā piegājienā:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Darbu nes divas detaļas. Lauks Address ir viens resursdatora prefikss, nevis apakštīkls, ko klients uzskata par savu, un tieši pārvaldnieks pārvērš noklusējuma AllowedIPs faktiskā noklusējuma maršrutā. Paceliet to pašu failu ar ip link un wg setconf un neparādīsies neviens maršruts, kas izskatās pēc salauzta tuneļa, bet patiesībā ir vesels tunelis ar izlaistu maršrutēšanas soli. wg-quick rokasgrāmata dokumentē maršrutēšanu un Table uzvedību, ko šie pārvaldnieki pievieno.

Lasiet rezultātu, nevis failu: ip route get 1.1.1.1 vajadzētu nosaukt tuneļa saskarni, un wg show vajadzētu ziņot par nesen notikušu rokasspiedienu ar kustīgu pārsūtīšanas skaitītāju. Rokasspiediens bez maršruta nozīmē, ka pārvaldnieks nekad nav palaists, un profila atkārtota rediģēšana to nelabos. Palaidiet saskarni tā, kā to palaidīs lietotājs, citādi tests mēra jūsu čaulu, nevis izvietošanu.

Turēt galapunktu ārpus tuneļa

Pilns tunelis uztver katru galamērķi, tostarp to, ar kuru tam jāsarunājas, lai pastāvētu. Pārvaldnieki to risina, pievienojot resursdatora maršrutu galapunktam caur sākotnējo vārteju, tāpēc pareizā konfigurācijā gandrīz vienmēr ir viens apzināts izņēmums. Pusi konfigurācijas piemērot ar pārvaldnieku un otru pusi ar rokām ir ierastais veids, kā šis izņēmums pazūd.

Ja galapunkts ir resursdatora nosaukums, kas atrisinās uz vairākām adresēm vai uz saimi, kuru jūs nepārnēsājat, izņēmums slikti noveco un tunelis var neizdoties pēc parasta šķietama atkārtota savienojuma. Piespraudiet galapunktu adresei, kuru kontrolējat, vai apstipriniet, ka pārvaldnieks to pārvērtē, un pēc katras tīkla izmaiņas vēlreiz izlasiet resursdatora maršrutu.

Tas pats mehānisms izskaidro, kāpēc pilns tunelis un gūsta portāls strīdas. Portāls gaida, ka pārtvers datplūsmu, ko jūsu tunelis tagad uztver, tāpēc viesnīcu un lidostu tīklos tuneli paceļat pēc portāla pieteikšanās, nekad pirms tam.

Pārsūtīšana un atgriešanās ceļš vārtejā

Vārtejā ieslēdziet pārsūtīšanu saimei, kuru pārnēsājat, atļaujiet forward ķēdi abos virzienos, kad tulkojat, un apstipriniet atgriešanās ceļu ar avotam specifisku meklēšanu. Nekas no tā neizriet no veiksmīga rokasspiediena, jo rokasspiediens tikai pierāda, ka divi partneri var apmainīties ar UDP. Tas neko nesaka par to, kas pēc tam notiek ar dekapsulēto paketi.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Meklēšana notiek vārtejā, nevis klientā, citādi jūs lasīsiet citu maršrutu tabulu. Ja tā nosauc nepareizo saskarni vai ziņo, ka maršruta nav, tad neviena klienta puses izmaiņa neradīs izeju internetā. Kad vārteja tulko klientu adreses izejot, atbilde ir atkarīga no šī tulkošanas stāvokļa, tāpēc noteikumam jāpastāv abiem plūsmas virzieniem, ne tikai izejošajam.

DNS un kļūmes stāvoklis, pārbaudīti atsevišķi

Pats protokols nekonfigurē nevienas lietotnes risinātāju. wg-quick piemēro rindu DNS caur distribūcijas risinātāja integrāciju, konteineri un pārlūki ar saviem stekiem to var ignorēt, un tāpēc nosaukums var neizdoties, kamēr tunelis pārnēsā paketes nevainojami. Pārbaudiet ar resursdatora nosaukumu, nevis adresi, un pierakstiet, kurš serveris atbildēja, tā vietā lai pieņemtu, ka to darīja profilā esošais.

Adrešu saimes ir atsevišķs tests ar atsevišķu atbildi. Noklusējuma v4 maršruts neko nesaka par to, ko darīs lietotnes v6 savienojums, un tunelis, kas klusi noplūdina otro saimi, ir sliktāks par to, kas skaļi neizdodas. Jautājiet nosaukumu pa katru saimi, lasiet saskarni, ko izmantoja katrs pieprasījums, un pārbaudiet tulkošanas skaitītājus pirms un pēc, jo noteikums, kas neatbilst nekam, izskatās tieši tāpat kā trūkstošs noteikums.

Visbeidzot, pārbaudiet stāvokli, kuru vēlaties, kad tunelis apstājas. Pilnam tunelim vajadzētu neizdoties slēgti attiecībā uz datplūsmu, ko tas apgalvo: ja saskarne nokrīt un lietotnes klusi turpina pa fizisko saiti, dizains ir sadalīts tunelis ar papildu soļiem. Pierakstiet paredzēto kļūmes uzvedību, apzināti to pārbaudiet un pabeidziet, reģistrējot četras atbildes — kurš pārvaldnieks paceļ saskarni, kurš maršruts nes noklusējuma, kas pārsūta un tulko vārtejā, un kurš risinātājs atbild.