Планиране на частен достъп през двустеков IKEv2 със strongSwan

Двустековият тунел не е едно решение, а три и на тях може да се отговори по различен начин. През кое семейство работи външният тунел, кои семейства клиентът получава отвътре и на кои семейства действително отговарят защитените услуги. Дизайн, който ги третира като един избор, или носи IPv6, който никога не е бил нужен, или раздава адреси, които нищо не може да маршрутизира обратно. Разделете трите и останалата част от конфигурацията става почти механична.

Три вида адреси, решени поотделно

Външният адрес е как двата шлюза се достигат един друг и той може да бъде IPv4, докато вътрешният трафик носи и двете семейства. Вътрешният виртуален адрес е идентичността на клиента вътре в тунела и всяко семейство се нуждае от свой пул. Защитените префикси са това, което клиентът може да достигне, и те принадлежат на услугите, а не на тунела. Объркването на третото с второто причинява повечето грешки при планиране, защото и двете изглеждат като частни диапазони.

Външен транспорт само по IPv4 с двустеков вътрешен трафик е нормална и добре поддържана подредба.

Решете всяко едно изрично и запишете решенията. Ако външният път е само IPv4, кажете го и спрете да се тревожите за достижимостта на крайните точки по IPv6. Ако семейство е зададено отвътре, но нищо не отговаря на него, или го премахнете от плана, или направете тези услуги наистина двустекови.

Отделете виртуален адрес във всяко семейство

В конфигурация на swanctl клиентът иска виртуални адреси и заместващ знак във всяко семейство кара отговарящия да назначи по един от всяко. Отговарящият ги черпи от пулове, а пуловете са отделни обекти от мрежите зад шлюза. Дръжте ги отделни и в плана, защото пул, който се застъпва с префикс на услуга, създава маршрутизация, която изглежда правилна до момента, в който трафикът попадне някъде неволно.

Искайте и двете семейства, когато ви трябват и двете, и едно, когато не ви трябва, защото неизползван адрес е повърхност за политики без полза. Конкретната заявка е заявка, а не резервация, и отговарящият може да върне различна стойност според собствената си политика. Тази подробност има значение навсякъде, където адресът е твърдо записан в правило на защитна стена или в проверка за наблюдение. Позовавайте се на пуловете по име във връзката и дръжте мрежите на услугите извън тях.

vips = 0.0.0.0, ::

Създайте свой собствен уникален локален префикс за пула IPv6, вместо да приемате кратка примерна стойност. Примерът показва формата на настройката, а не стойност по подразбиране за наследяване.

Опишете дестинациите отделно от пуловете

Селекторите на трафик описват какво очаква да обменя всяка страна, затова локалните селектори на шлюза трябва да назовават защитени префикси на услуги, а не клиентски пулове. Отдалечените селектори на клиента отразяват това намерение. Когато двата списъка описват различни обекти, тунелът може да се вдигне и пак да не носи нищо полезно.

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

Тук частният план за IPv6 престава да бъде достатъчен. Уникалната локална адресация дава частна достижимост и не създава публичен изход IPv6, така че дизайн, който предполага, че неномерираното семейство просто ще следва правилата за маскиране на IPv4, ще разочарова потребителите си. Ако публичният достъп до IPv6 е част от изискването, той се нуждае от маршрутизиран план и от възходящ поток, който се съгласява с него. Иначе кажете направо, че страната IPv6 е само частна, което е честна граница, а не ограничение, което да се крие.

Направете DNS и обратните пътища умишлени

Разрешаването на имена не следва транспорта. Резолверът може да върне записи A и AAAA през тунел само с IPv4 и тогава клиентът ще опита семейство, което никога не сте планирали. Решете кои имена на услуги трябва да носят използваеми двустекови отговори и направете и двата пътя умишлени. Име, което се разрешава до семейство без работещ път, предизвиква застой, а не чиста грешка, а застоите са много по-трудни за диагностициране.

Документирайте достижимостта на външната крайна точка отделно, включително дали участва преминаване през NAT и кое семейство използва.

След това запишете плана в шест реда: външна крайна точка, пул IPv4, пул IPv6, префикс на услуга IPv4, префикс на услуга IPv6 и маршрутизаторът, който притежава отговорите за всяко. План в тази форма отговаря на въпросите, които операторът наистина задава в три часа през нощта. Всичко по-кратко оставя двустека като втори адрес, прикрепен към политика само за IPv4, и така обикновено той свършва като наполовина работещ.