Како да планирате адресен базен за VPN клиенти што одговара

Започнете во полето за базен на VPN серверот, не во табела. Она што ќе го внесете таму станува внатрешен адресен простор за секој клиент што ќе се поврзе потоа, и мора да коегзистира со LAN-от до кој тие клиенти стигнуваат, со рутираните локации зад него и со секоја адреса што клиентот веќе ја има дома. Поврзете еден клиент веднаш штом базенот е зачуван, бидејќи таа прва врска ви кажува дали вредноста работи во пракса. Оттаму прошетката се движи нанадвор: адресата што клиентот ја доби, патеката што ја поминува одговорот и записот што го оставате.

Започнете во полето за базен, пред да се поврзе кој било клиент

Секој производ го изложува ова поинаку, затоа најдете го објектот што навистина доделува адреси. OpenVPN има серверска директива за базен што ја дава следната слободна адреса, IKEv2 порта има дел за базен врзан со конфигурацијата на партнерот, а WireGuard нема ниту едно, бидејќи секој партнер ја носи сопствената адреса во својата конфигурациска датотека. Директивата за базен и адресата по партнер не се заменливи, а уредувањето на погрешната го троши остатокот од прошетката.

Кога ќе го добиете полето, наведете ги опсезите што веќе постојат: канцеларискиот LAN, секоја рутирана локација, облачниот 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-от не резервира ништо за клиент во тунелот. Таа една линија го спречува најчестото преправување, кога некој додава резервација и очекува адресата на тунелот да ја следи.