Iekļautais WireGuard: vidējais lēciens nevar atbildēt uz savu ostu

Trīs WireGuard lēcieni sasniedz tīklu bez publiskas adreses, un tad vidējā mašīna pārstāj atbildēt uz ostu, kurā tai bija jāklausās. Tunelis tālāk joprojām darbojas, attālais resursdators joprojām atbild, un tikai pats vidējais serveris ir apklusis no ārpuses. Šī kombinācija mulsina tieši tāpēc, ka tā ir pati radīta: vidējais lēciens pakļaujas savai maršrutēšanas tabulai, un tabula sūta tā atbildes nepareizajā virzienā.

Ķēde, kas darbojas, līdz tu runā ar vidējo kasti

Ņemsim ilustratīvu ķēdi: klients A sasniedz serveri B UDP 500, un B virzās tālāk uz serveri C UDP 500. C pieņem trafiku tikai no savas vienīgās partnera adreses, kas to padara par lapu un saglabā tā uzvedību vienkāršu. B nav lapa, un viss interesantais šajā kļūmē notiek tieši tur.

Šī atšķirība ir svarīga, jo lapas un vidus lomas velk pretējos virzienos. Lapa var sūtīt visu vienā tunelī bez sekām, jo nekas cits no tās nav atkarīgs. Vidējais lēciens vienlaikus ir galapunkts klientiem un klients pret attālo pusi, un šiem diviem darbiem vajadzīga atšķirīga maršrutēšana.

Kāpēc atbilde iziet pa tuneli

Uz B saskarne, kas vērsta pret C, nes AllowedIPs = 0.0.0.0/0 kopā ar atbilstošo noklusējuma maršrutu. Tāpēc katrs B ģenerētais pakets nonāk šajā tunelī, ja vien kaut kas konkrētāks nesaņem priekšroku.

Pakets no A, kas adresēts B, ierodas un tiek pieņemts, jo B ir galamērķis un vietējā piegāde notiek vispirms. Atbilde ir pavisam jauns vietēji ģenerēts pakets, kas vērsts uz A publisko adresi, un šis galamērķis atbilst noklusējuma maršrutam tunelī. C to saņem, nepieder šai adresei un to izmet.

Simptoms lasās kā ugunsmūra problēma vai atslēgu nesakritība, un šeit nav patiess neviens. Uzņemšana tunelī pret C parāda, ka atbildes iet nepareizajā virzienā. Šis viens novērojums ietaupa vairāk laika nekā jebkurš konfigurācijas lasīšanas apjoms, tāpēc pierakstiet to pirms sākat mainīt atslēgas. Ikviens, kas nav redzējis uzņemšanu, pieņems, ka pats tunelis ir bojāts.

Šaurais labojums: politikas noteikumi, kas atbilst avota ostai

Atbildes no B klausīšanās ligzdas iziet ar avota ostu 500. Politikas noteikums var tam atbilst un nosūtīt šos paketus atpakaļ uz parasto tabulu:

ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101

Politikas noteikumi tiek skatīti prioritātes kārtībā, un galvenā tabula atrodas 32766, tāpēc noteikums pie 100 tiek jautāts pirms tuneļa noklusējuma maršruts kaut ko saka. Pievienojiet vienu ierakstu katrai ostai, kurai jāpaliek sasniedzamai no ārpuses, un neko vairāk, lai pārsūtītais trafiks turpinātu izmantot tuneli, kuram tas tika būvēts.

Ziniet šī trika robežu. sport selektors atbilst vietēji ģenerētiem paketiem, kas nosedz tieši atbildes gadījumu un apzināti nenosedz trafiku, ko B tikai pārsūta kādam citam. Pakalpojumam, kas mitināts aiz B, joprojām vajadzīga sava atbilde, un pretējā apgalvošana rada labojumu, kas darbojas pirmajam pakalpojumam un neizdodas otrajam.

Piešķiriet noteikumam saimnieku

Uzvednē ierakstīts noteikums pazūd nākamajā reizē, kad saskarne tiek pārbūvēta. WireGuard iestatījumā ievietojiet to tur, kur saskarne tiek izveidota un noņemta:

PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100

Ja saskarni pārvalda NetworkManager, distribūcijas āķis vai konteinera ieejas punkts, pāris pieder tam saimniekam, nevis ar rokām rediģētam failam. Pārbaudiet spēkā esošos noteikumus pēc atkārtota savienojuma, ne tikai pēc pirmās palaišanas, jo pirmā palaišana ir gadījums, kas vienmēr darbojas.

Salīdziniet alternatīvas godīgi

Avota ostas noteikums ir viens no četriem izejas ceļiem, un tas ir šaurākais no tiem. Tam ir priekšrocība vispār neaizskart tuneļa politiku, tāpēc tas parasti pārdzīvo vēlākas izmaiņas. Šauri labojumi arī skaļi sabrūk, kad pārstāj darboties, turpretī plašs izņēmums turpina klusi darboties vēl ilgi pēc tam, kad iemesls ir pazudis. Šī atšķirība ir svarīgāka par eleganci, kad pēc diviem gadiem kasti pārvalda kāds cits.

Pārbaudiet no abiem galiem, kad esat izvēlējies. No A sāciet savienojumu uz B ostu un kādu laiku turiet to aizņemtu. Uz B lieciet kodolam pamatot atbildes ceļu ar kaut ko līdzīgu ip route get <address-of-A> sport 500, un apstipriniet, ka tas nosauc WAN saskarni, nevis tuneli. Pēc tam pārbaudiet, ka kaut kas aiz C joprojām atbild pa ķēdi, kas pierāda, ka izņēmums palika šaurs, nevis pārvērtās apvedceļā. Visbeidzot, ierakstiet ostas projektēšanas piezīmēs, citādi nākamais operators to atklās no jauna citā pakalpojumā.