Како испланирати базен адреса VPN клијената који одговара
Изаберите базен у пољу сервера, затим прочитајте адресу коју клијент заиста добија, пратите одговор назад и запишите распон, режим, руту и обим DNS-а.
Почните у пољу базена на VPN серверу, а не у табели. Оно што тамо унесете постаје унутрашњи адресни простор за сваког клијента који се повеже касније, и мора да коегзистира са LAN-ом до којег ти клијенти долазе, са рутираним локацијама иза њега и са било којом адресом коју клијент већ има код куће. Повежите једног клијента одмах након што се базен сачува, јер та прва веза говори да ли вредност ради у пракси. Одатле се обилазак креће ка споља: адреса коју је клијент добио, пут којим одговор иде и запис који остављате за собом.
Почните у пољу базена, пре него што се повеже било који клијент
Сваки производ то излаже другачије, зато пронађите објекат који заиста додељује адресе. OpenVPN има серверску директиву базена која дели следећу слободну адресу, IKEv2 гејтвеј има одељак базена везан за конфигурацију партнера, а WireGuard нема ниједно јер сваки партнер носи сопствену адресу у својој конфигурационој датотеци. Директива базена и адреса појединачног партнера нису заменљиве, а уређивање погрешне троши остатак обиласка.
Кад добијете поље, попишите распоне који већ постоје: канцеларијски LAN, сваку рутирану локацију, cloud VPC и сваки други базен који је још у употреби. Преклапање се одлучује аритметиком префикса, а не тиме да ли бројеви домаћина изгледају познато, зато упоредите агрегат са сваким од тих распона. Два распона која оба изгледају као 10.x безопасна су када се њихови агрегати не секу и инцидент за подршку када се секу.
Затим одлучите да ли је адреса функција онога ко се повезује или онога када се повезује. Динамичка додела даје оно што је слободно, док додела по идентитету везује фиксну адресу за акредитив. Запишите избор, јер он мења како поновно повезивање треба да изгледа касније.
Прочитајте адресу коју је клијент заиста добио
Повежите један клијент и читајте шта тунел пријављује, а не шта је базен обећао. Клијент приказује своју унутрашњу адресу у статусу везе, а на Linux-у је интерфејс носи директно.
Упоредите ту адресу са распоном који сте сачували. Ако је изван распона, гледате други пут доделе од онога који сте уређивали. Проверите и дужину префикса, јер клијент са /32 нема партнера на вези и шаље свако одредиште кроз своју подразумевану руту.
ip -4 addr show tun0
ip route get 192.168.50.20
Клијент који се повезује са кућног рутера који користи исти распон повезаће се и затим стићи готово нигде. Клијент задржава своју локалну руту за тај префикс, па се адреса тунела судара са мрежом иза њега и саобраћај излази кроз погрешан интерфејс. Тај случај се не може поправити на серверу; документовано решење је пренумерација кућне мреже или избор довољно удаљеног распона базена да судари остану ретки. Забележите и квар и решење, јер ће служба подршке поново наићи на то.
Поново повежите исти клијент и гледајте адресу. Динамички базен може вратити исту вредност или другу и обе су тачне, док базен по идентитету који мења адресу не поштује везивање. Та провера траје секунде и одлучује да ли је режим који сте записали у првом одељку режим на снази.
Пратите одговор назад од услуге
Базен ради само када одговори могу да путују назад до њега. Услуга на LAN-у одговара на унутрашњу адресу, па њен гејтвеј треба руту за базен или превод испред услуге. Када захтев стигне кроз тунел а одговор изађе другим путем, stateful firewall или провера обрнутог пута га одбацује, и клијент види услугу која се повеже и затим виси. Ставите базен у дизајн рутирања као један блок који може да се сумира, уместо да додајете руте по домаћину.
Превод мења оно што види остатак система. Када се извор препише, адреса у firewall-у домаћина и у дневнику апликације је преведена, па правило написано према адреси базена не одговара ничему и линија дневника не може да се прати до клијента. strongSwan документација о прослеђивању покрива серверску половину тог пута за IKEv2 гејтвеј. DNS носи исто ограничење, јер име које се разрешава у адресу коју клијент не може да достигне пада касније и на другом месту.
Два клијента, затим једно опозивање
Повежите два клијента истовремено и прочитајте обе адресе. Морају бити различите, употребљиве и унутар базена, и свака мора да достигне услугу којој је намењена. Базен који дели дупликате адреса обично се покаже овде, а не у првом тесту са једним клијентом.
Опозовите један акредитив док други клијент остаје повезан, затим пробајте услугу са клијента који је преживео. Опозив који ремети другу сесију упућује на дељено стање, најчешће један акредитив или једну адресу поново употребљену између уређаја. Поново повежите опозвани клијент и потврдите да му се одбија приступ, а не да добија ослобођену адресу.
Завршите одредиштем које треба да буде одбијено. Клијент који достигне све је повезан, а не тестиран.
Запишите четири вредности тамо где ће их следећа промена наћи
Запис је кратак: распон и префикс базена, режим доделе, повратни пут или превод у употреби и обим DNS-а који одговара за та одредишта. Ставите га поред конфигурације сервера, а не у тикет, и датирајте га. Свакоме ко касније промени један од четири требају остала три пред њим, јер промена величине базена ломи руту, а промена руте ломи DNS одговор.
Држите уз њега напомену о власништву: распон тунела припада VPN серверу, а резервација направљена у DHCP обиму LAN-а не резервише ништа за клијента унутар тунела. Тај један ред спречава најчешћи поновни рад, када неко дода резервацију и очекује да адреса тунела иде за њом.