Двустекови пулове 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 адрес от пула и накъде всъщност ще отиде трафикът към защитен префикс. Сравнете зададения адрес с пула, който сте конфигурирали, а не с адреса, на който сте се надявали. Ако отговарящата страна е избрала различна стойност по своята политика, маршрутите и правилата на защитната стена трябва да съответстват на нейния избор.

След това тествайте по един защитен хост за всяка фамилия и име, което се разрешава и до двете. Тест само на една фамилия не ви казва нищо за половината от плана, която не сте упражнили, а именно там обикновено живее липсващият маршрут.

Подобни статии