VPN базени со двоен стек: адресирање на двете фамилии во strongSwan

Внатрешните IPv4 и IPv6 базени, заштитените префикси и фамилијата на надворешниот тунел се три одделни одлуки. Планирајте ја секоја пред да го наречете двоен стек.

Порта може да му даде на патувачкиот корисник и IPv4 и IPv6 виртуелна адреса, додека надворешниот тунел сѐ уште минува преку IPv4. Тоа се независни одлуки, и токму нивното третирање како една е местото каде што плановите со двоен стек обично се распаѓаат. Внатрешните фамилии на клиентот, заштитените префикси до кои може да стигне и транспортот што ја носи инкапсулацијата се три одделни избори.

Повеќето конфузија доаѓа од тоа што зборот двоен стек се применува на дизајн што е двоен стек само на едно место. Услугата може да биде двоен стек внатрешно, единечен стек на својата надворешна адреса, и сепак сосема добро да работи за клиентите. Она што не може е да работи случајно.

Две фамилии внатре, една патека надвор

Надворешната врска е IKE врз UDP и ѝ треба една достапна фамилија адреси од местото каде што е клиентот. Внатрешната IPv6 адреса не бара давател со IPv6, бидејќи внатрешниот пакет е полезен товар внатре во надворешниот. Многу работни имплементации пренесуваат IPv6 префикси низ врска нагоре што има само IPv4.

Она што надворешната патека навистина го ограничува е достапноста и минувањето низ NAT. Ако портата објавува само IPv4 адреса, клиент во мрежа само со IPv6 не може воопшто да се поврзе, без оглед на тоа какви базени сте конфигурирале. Одлучете ја надворешната фамилија според вашата клиентска популација, а не според внатрешниот план за адреси.

Дајте му на клиентот адреса во секоја фамилија

Барањето на двете фамилии е еден ред на страната на клиентот, под услов портата да има што да подели. Именуваните базени ги држат изворите одвоени од услужните мрежи, и токму тоа својство ги прави правилата на огнениот ѕид читливи и шест месеци подоцна.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Вредноста vips бара адреса од секоја фамилија, а списокот на базени одлучува од каде доаѓаат тие адреси. Документацијата на strongSwan за виртуелните IP адреси опфаќа повеќе барања и доделување базени, вклучително и тоа што клиентот што бара конкретна адреса изразува само преференција што одговорната страна може да ја надмине. Не градете правило за пристап што претпоставува дека клиентот секогаш ја добива истата вредност.

Генерирајте свој единствен локален префикс наместо да го копирате примерот. Две организации што и двете fd42::/16 го воведат ќе го откријат судирот при првото меѓусебно поврзување, а неговото дијагностицирање не е пријатно.

Селекторите опишуваат одредишта, а не извори

Локалните селектори на сообраќај на детето SA кажуваат кои заштитени мрежи стојат зад портата, а далечните селектори опишуваат што клиентот смее да користи како извор. Адресата на виртуелен базен припаѓа на изворната страна на таа политика; нејзиното ставање во списокот одредишта е често погрешно читање на конфигурацијата.

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

Држете ги базените и услужните префикси во одделни блокови од вашиот план за адреси. Кога ќе се преклопат, маршрута што треба да стигне до заштитен домаќин може да се совпадне со адреса на базен и да исчезне во тунелот.

DNS и патеката на одговорот одлучуваат дали изгледа завршено

Одговорите на резолверот се независни од транспортот што се користи за да се стигне до него. Името може да врати A запис, AAAA запис или и двете, а клиентот избира според сопствените правила за преференција. Ако внатрешна услуга објавува AAAA запис, но ништо не рутира тој префикс, клиентите во мрежи со двоен стек прво ќе ја пробаат IPv6 патеката и ќе останат таму додека не пропадне. Ништо во конфигурацијата на тунелот не изгледа погрешно додека тоа се случува.

Затоа одлучете за секое име кои фамилии треба да бидат употребливи, потоа проверете дека соодветниот префикс е во селекторот и има повратна маршрута. Тоа е одлука за секоја услуга одделно. Објавувањето на двата типа записи без разлика е начинот на кој работна услуга само со IPv4 почнува да истекува време за половината од своите корисници.

Проверете ги двете фамилии пред да го наречете готово

Конфигурацијата што се вчитува не е конфигурација што работи. Прочитајте ја состојбата што ја пријавува демонот, потврдете ги доделувањата на базените, потоа погледнете ги маршрутите што клиентот навистина ги инсталирал.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Првите две наредби ги прикажуваат воспоставените дете SA и кои базени сѐ уште имаат слободни адреси, така што планот што работи за првиот клиент, а пропаѓа за десеттиот, станува видлив. Последните две покажуваат дали клиентот добил глобална IPv6 адреса од базенот и каде сообраќајот до заштитен префикс навистина би одел. Споредете ја доделената адреса со базенот што сте го конфигурирале, а не со адресата на која сте се надевале. Ако одговорната страна избрала друга вредност според својата политика, маршрутите и правилата на огнениот ѕид мора да одговараат на нејзиниот избор.

Потоа тестирајте по еден заштитен домаќин за секоја фамилија и име што се разрешува во двете. Тестот на една фамилија не ви кажува ништо за половината од планот што не сте ја вежбале, а токму таму обично живее маршрутата што недостига.

Поврзани статии