Kā plānot atbilstošu VPN klientu adrešu pūlu

Sāciet pūla laukā VPN serverī, nevis izklājlapā. Tas, ko tur ievadāt, kļūst par iekšējo adrešu telpu katram klientam, kas pievienojas pēc tam, un tai jāsadzīvo ar LAN, ko sasniedz šie klienti, aiz tās esošajām maršrutētajām vietnēm un jebkuru adresi, kas klientam jau ir mājās. Pievienojiet vienu klientu tiklīdz pūls ir saglabāts, jo šis pirmais savienojums pasaka, vai vērtība darbojas praksē. No turienes apskats virzās uz āru: adrese, ko klients saņēma, ceļš, ko atbilde iet, un ieraksts, ko atstājat.

Sāciet pūla laukā, pirms pievienojas jebkurš klients

Katrs produkts to parāda citādi, tāpēc atrodiet objektu, kas patiešām piešķir adreses. OpenVPN ir servera puses pūla direktīva, kas izdod nākamo brīvo adresi, IKEv2 vārtejai ir pūla sadaļa, kas saistīta ar partnera konfigurāciju, un WireGuard nav neviena, jo katrs partneris savu adresi nes savā konfigurācijas failā. Pūla direktīva un atsevišķa partnera adrese nav savstarpēji aizvietojamas, un nepareizās rediģēšana izšķērdē pārējo apskatu.

Kad lauks ir iegūts, uzskaitiet diapazonus, kas jau pastāv: biroja LAN, katru maršrutēto vietni, mākoņa VPC un jebkuru citu pūlu, kas vēl ir ekspluatācijā. Pārklāšanos nosaka prefiksa aritmētika, nevis tas, vai resursdatoru numuri šķiet pazīstami, tāpēc salīdziniet agregātu ar katru no šiem diapazoniem. Divi diapazoni, kas abi izskatās kā 10.x, ir nekaitīgi, ja to agregāti nekrustojas, un atbalsta incidents, ja krustojas.

Pēc tam izlemiet, vai adrese ir funkcija no tā, kas pievienojas, vai no tā, kad viņi pievienojas. Dinamiskā piešķiršana izdod to, kas ir brīvs, kamēr piešķiršana pēc identitātes piesaista fiksētu adresi akreditācijas datiem. Pierakstiet izvēli, jo tā maina to, kā vēlāk jāizskatās atkārtotai pievienošanai.

Nolasiet adresi, ko klients faktiski saņēma

Pievienojiet vienu klientu un lasiet, ko ziņo tunelis, nevis ko solīja pūls. Klients rāda savu iekšējo adresi savienojuma statusā, un Linux sistēmā saskarne to nes tieši.

Salīdziniet šo adresi ar diapazonu, ko saglabājāt. Ja tā ir ārpus diapazona, jūs redzat citu piešķiršanas ceļu nekā to, ko rediģējāt. Pārbaudiet arī prefiksa garumu, jo klientam ar /32 nav partnera saitē un tas sūta katru galamērķi pa savu noklusējuma maršrutu.

ip -4 addr show tun0
ip route get 192.168.50.20

Klients, kas pievienojas no mājas maršrutētāja ar to pašu diapazonu, pievienosies un pēc tam sasniegs gandrīz neko. Klients saglabā savu vietējo maršrutu šim prefiksam, tāpēc tuneļa adrese saduras ar tīklu aiz tā un trafiks iziet pa nepareizo saskarni. Šo gadījumu serverī nevar salabot; dokumentētais līdzeklis ir pārnumurēt mājas tīklu vai izvēlēties pietiekami tālu pūla diapazonu, lai sadursmes paliktu retas. Pierakstiet gan kļūmi, gan līdzekli, jo atbalsta dienests ar to saskarsies vēlreiz.

Pievienojiet to pašu klientu vēlreiz un vērojiet adresi. Dinamiskais pūls var atgriezt to pašu vai citu vērtību, un abas ir pareizas, kamēr pūls pēc identitātes, kas maina adresi, neievēro saistību. Šī pārbaude aizņem sekundes un izlemj, vai režīms, ko pierakstījāt pirmajā sadaļā, ir spēkā esošais režīms.

Izsekojiet atbildei atpakaļ no pakalpojuma

Pūls darbojas tikai tad, kad atbildes var ceļot atpakaļ uz to. Pakalpojums LAN tīklā atbild uz iekšējo adresi, tāpēc tā vārtejai vajag maršrutu pūlam vai tulkojumu pakalpojuma priekšā. Kad pieprasījums nāk pa tuneli un atbilde iziet pa citu ceļu, stāvokļa ugunsmūris vai apgrieztā ceļa pārbaude to nomet, un klients redz pakalpojumu, kas pievienojas un tad karājas. Ievietojiet pūlu maršrutēšanas projektā kā vienu apkopojamu bloku, nevis pievienojiet maršrutus katram resursdatoram.

Tulkošana maina to, ko redz pārējā sistēma. Kad avots tiek pārrakstīts, adrese resursdatora ugunsmūrī un lietojumprogrammas žurnālā ir tulkotā, tāpēc noteikums, kas rakstīts pret pūla adresi, neatbilst nekam, un žurnāla rindu nevar izsekot līdz klientam. strongSwan pāradresācijas dokumentācija aptver servera puses pusi no šī ceļa IKEv2 vārtejai. DNS nes to pašu ierobežojumu, jo vārds, kas atrisinās uz adresi, kuru klients nevar sasniegt, neizdodas vēlāk un citur.

Divi klienti, pēc tam viens atsaukums

Pievienojiet divus klientus vienlaikus un nolasiet abas adreses. Tām jābūt atšķirīgām, lietojamām un pūla iekšpusē, un katrai jāsasniedz pakalpojums, kam tā paredzēta. Pūls, kas izdod dublētas adreses, parasti parādās šeit, nevis pirmajā viena klienta testā.

Atsauciet vienus akreditācijas datus, kamēr otrs klients paliek pievienots, pēc tam izmēģiniet pakalpojumu no izdzīvojušā klienta. Atsaukums, kas traucē otru sesiju, norāda uz kopīgu stāvokli, visbiežāk vieniem akreditācijas datiem vai vienai adresei, kas atkārtoti izmantota starp ierīcēm. Pievienojiet atsaukto klientu vēlreiz un apstipriniet, ka tam atsaka, nevis piešķir atbrīvoto adresi.

Beidziet ar galamērķi, kam būtu jāatsaka. Klients, kas sasniedz visu, ir pievienots, nevis pārbaudīts.

Pierakstiet četras vērtības tur, kur tās atradīs nākamā izmaiņa

Ieraksts ir īss: pūla diapazons un prefikss, piešķiršanas režīms, atgriešanās ceļš vai izmantotā tulkošana un DNS tvērums, kas atbild par šiem galamērķiem. Novietojiet to blakus servera konfigurācijai, nevis biļetē, un datējiet to. Ikviens, kas vēlāk maina vienu no četriem, pieprasa pārējos trīs acu priekšā, jo pūla lieluma maiņa salauž maršrutu, bet maršruta maiņa salauž DNS atbildi.

Turiet tam līdzi īpašumtiesību piezīmi: tuneļa diapazons pieder VPN serverim, un rezervācija, kas veikta LAN DHCP tvērumā neko nerezervē klientam tuneļa iekšpusē. Šī vienīgā rinda novērš visbiežāk sastopamo pārstrādi, kad kāds pievieno rezervāciju un gaida, ka tuneļa adrese tai sekos.