Viesa VPN un resursdatora VPN: kura maršruta faktiski uzvar

Divi klienti darbojas vienlaikus, katrs pārliecināts, ka tam pieder noklusējuma maršruts, un simptoms parādās kā kaut kas dīvains: viena viesa lietotne darbojas, otra tiek atrisināta nepareizajā vietā. VPN viesa iekšienē un VPN resursdatorā var pastāvēt līdzās, bet tikai tad, kad ārējais ceļš un iekšējā politika vienojas par to, kas ko nes. Abu palaišana pati par sevi ķēdi neveido. Vispirms pierakstiet pieslēguma veidu, pēc tam mainiet vienu lietu vienlaikus.

Vispirms pierakstiet viesa pieslēguma veidu

Viesis sasniedz savu VPN serveri pa to ceļu, kuru tam deva hipervizors: NAT aiz resursdatora, tilts uz fizisko segmentu vai tīkls tikai resursdatoram ar virsū pievienotu maršrutēšanu. Katrs pieslēguma veids maina to, ko viesis var redzēt un ko resursdators var darīt ar tā plūsmu. NAT apakšā viesa paketes izskatās nākam no resursdatora, tāpēc paša resursdatora tunelis var tās nest, viesim par to neko nezinot. Tilta apakšā viesim ir sava klātbūtne segmentā un sava noklusējuma vārteja.

Pierakstiet pieslēguma veidu pirms jebkuras konfigurācijas aizskaršanas, kopā ar to, kuram klientam jānes kura lietotne. Šis teikums atrisina lielāko daļu šādu gadījumu, jo abi klienti parasti ir būvēti uz atšķirīgiem pieņēmumiem. Viesim, kuram jāizmanto resursdatora tunelis, nedrīkst būt arī savs konkurējošs noklusējuma maršruts.

Izsekojiet viesa galapunktu uz āru

Viesa VPN ir vajadzīgs lietojams ceļš uz savu serveri, pirms kaut kas cits var strādāt. Kad resursdatora tunelis ir augšā un viesis sēž aiz NAT, viesa rokasspiediens iziet caur resursdatora tuneli, kas ir vai nu dizains, vai negadījums, ko neviens nav dokumentējis. Kad resursdatora tunelis krīt un viesis no tā bija atkarīgs, viesis zaudē savienojumu bez nevienas izmaiņas savā pusē. Galapunkta izsekošana uz āru pasaka, kurš no šiem diviem gadījumiem jums patiešām ir.

Plašs maršruts jebkurā kontekstā noķer plūsmu, kuru gaidīja otrs klients. 0.0.0.0/0 maršruts viesa iekšienē un pilna tuneļa resursdatora klients abi pretendē uz visu, un uzvar tas, kas tiek piemērots pēdējais. Viesa virtuālo tīklu, vietējā LAN un attālo tīklu pārklāšanās rada tādu pašu efektu privātiem prefiksiem, un kļūmes atgādina autentifikācijas problēmas; adrešu tulkošanas uzvedība ir tā pati, kas aprakstīta konteineru tīkliem.

Salīdziniet ierakstu pirms un pēc

Paņemiet bāzes līniju ar izslēgtu resursdatora tuneli vai jebkurā kontrolētā stāvoklī, ko pieļauj jūsu politika, un pierakstiet viesa maršrutu un atrisinātāju. Pēc tam piemērojiet apvienoto konfigurāciju un salīdziniet abus ierakstus, saglabājot privātuma prasības. Ja tieša bāzes līnija nav piemērota, ierakstiet šo ierobežojumu ierakstā, nevis izlaidiet salīdzinājumu.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

Maršruta vaicājums nosauc saskarni un avota adresi, kas nestu konkrētu galamērķi, un tā ir visnoderīgākā rinda šajā izmeklēšanā. Noteikumu saraksts parāda, vai politikas maršrutēšana sūta dažus galamērķus caur otru tabulu. Atrisinātāja izvade parāda, vai DNS sekoja viesa tunelim vai palika resursdatora ceļā. Palaidiet tās pašas trīs komandas pirms un pēc izmaiņām, un starpība nosauks vainīgo.

Saglabājiet īpašumtiesības skaidras starp pārstartēšanām

Resursdatora klienta vietējās piekļuves ierobežojums var bloķēt plūsmu uz virtuālu NAT vai tiltu, un šis ierobežojums bieži tiek sajaukts ar viesa akreditācijas datu problēmu. Lasiet klienta dokumentēto uzvedību, nevis izslēdziet ierobežojumu, lai tests izietu. Pēc atbalstīta labojuma vēlreiz pārbaudiet viesa lietotni un nepieciešamo kļūmes politiku. Resursdators, kas veiksmīgi atkārtoti pieslēdzas, neko nepierāda par viesa maršrutu vai atrisinātāju.

Izlemiet, kura puse pārvalda noklusējuma maršrutu, un ierakstiet to ekspluatācijas rokasgrāmatā. Viesa pārstartēšana vai tīkla pārslēgšana resursdatorā, kas klusi apgriež īpašumtiesības, rada kļūdas ziņojumu par VPN, kas nekad nav bijis vainīgs. Sakārtojumam vajadzētu pārdzīvot pārstartēšanu, nevienam neatceroties, kāpēc tas strādāja.