Uzņēmuma VPN programmā WireGuard: kurš slānis ir pirmais?

Izstrādātāja portatīvajā datorā tuneļu ieguldīšanai vienu otrā ir divi pamatoti iemesli. Vai nu uzņēmuma klientam ir jāizskatās tā, it kā tas nāktu no noteiktas valsts, vai arī diviem privātiem tīkliem jābūt sasniedzamiem vienlaikus. Abos gadījumos ārējam tunelim ir jāpārvadā paša iekšējā klienta savienojums.

Divu klientu palaišana jebkurā secībā to nedod. To dod maršrutēšana.

Salīdziniet abas iespējamās secības

Par ārējo slāni izvēlieties tuneli, kura galapunkts ir sasniedzams no publiskā interneta. Iekšējais slānis ir tunelis, kura serveris atbild tikai caur šo izeju. Programmā Windows praktiskais sadalījums ir WireGuard ārpusē un uzņēmuma klients iekšpusē. Izšķirošais faktors ir kontrole.

Oficiālais WireGuard klients piemēro pilnu konfigurācijas failu, tostarp maršrutus un DNS. Komerciālie uzņēmuma klienti parasti slēpj abus. Ievietojot paslēptu klientu ārpusē, jums nāksies minēt, kāds ceļš ir zem tā.

Apgrieztā secība nav neiespējama. Vienkārši par to ir grūtāk domāt, jo ārējais klients pārraksta maršrutus pēc grafika, kuru jūs nekad neredzat.

Ļaujiet AllowedIPs nosaukt tikai uzņēmuma diapazonu

AllowedIPs uzskaita galamērķus, kurus WireGuard novirza tunelī. Iegulšanai tam vajadzīga tikai iekšējā servera adrese un uzņēmuma prefiksi. Viss pārējais paliek vietējā tīklā, tostarp printeri un hipervizors. Tas ir pēc konstrukcijas sadalīts tunelis, un tas pilnībā izvairās no izslēgšanas problēmas.

Ārējam slānim ar pilnu tuneli ir vajadzīgs 0.0.0.0/0 atņemot vietējos diapazonus. Formāts nevar izteikt izslēgšanu, tāpēc papildinājums ir jāaprēķina un jāielīmē.

[Interface]
PrivateKey = ...
Address = 10.99.4.2/32

[Peer]
PublicKey = ...
Endpoint = 198.51.100.44:51820
AllowedIPs = 198.51.100.44/32, 10.20.0.0/16, 10.21.0.0/16

Kad iekšējais klients neinstalē savus maršrutus, uzskaitiet uzņēmuma prefiksus paši. Šajā rindā izlaists prefikss ir galamērķis, ko ārējais tunelis nekad nepārvadā. Novecojusi saraksta kopija ir sliktāka par neesošu, jo tā joprojām izskatās pareiza.

Secība, metrikas un otrais adapteris

Vispirms pievienojiet ārējo tuneli, pēc tam palaidiet uzņēmuma klientu. Tad tā galapunkta savienojums iziet caur WireGuard, nevis caur vietējo vārteju. Piešķiriet uzņēmuma saskarnei zemāku metriku, lai tās prefiksi uzvarētu tai piederošajās adresēs.

# which interface currently claims the corporate prefix?
Find-NetRoute -RemoteIPAddress 10.20.10.5 | Select-Object -First 1

# prefer the corporate interface for its own prefixes
Set-NetIPInterface -InterfaceAlias 'Corp VPN' -InterfaceMetric 3
Set-NetIPInterface -InterfaceAlias 'wg-personal' -InterfaceMetric 40

wg show interfaces

Metrikas ir solis, ko cilvēki izlaiž. Bez secības pārklājošajam prefiksam uzvar pēdējais instalētais maršruts. Tas mainās starp palaišanām, tāpēc problēma šķiet periodiska.

Klienti, kas veidoti uz OpenVPN 2.6, pievieno savus slazdus. Kad datu kanāla atvieglināšanas adapteris jau ir aizņemts, otrā instance vienkārši atsakās startēt. Pievienojot disable-dco profilam, notiek atgriešanās pie vecākā TAP ceļa, un tad abi darbojas blakus.

Kur lūzt iegultais ceļš

Atvienojot ārējo tuneli, iet bojā iekšējais. Atkārtoti pievienojot tikai iekšējo klientu, tas bieži nonāk tieši internetā un klusi noņem iegulšanu. Katru reizi pārbaudiet secību no nulles, abiem tuneļiem apturētiem.

Gaidiet mazāku lietderīgo MTU. Katrs slānis pievieno papildu izmaksas, tāpēc sākuma pāris ap 1420 un 1400 ir vieta, ar ko sākt. Pārsūtīšana, kas iestrēgst pie lieliem paketēm, kamēr mazie pieprasījumi izdodas, ir ierastā pazīme. Uzņēmuma politika ir otra robeža, jo klients, kas pieprasa pārvaldītu ierīci, iegultu ceļu var uzskatīt par pārkāpumu.

Kad abi gali ir fiksēti tīkli, vietnes-uz-vietni tunelis starp vārtejām novērš secības problēmu, nevis pārvalda to. Vienā portatīvajā datorā divi tuneļi pastāv līdzās tikai tad, kad katram ir sava saskarne un noteikums, kas izvēlas galamērķus pēc prefiksa.