NAT на LAN през tun0 на OpenBSD VPN шлюз

Двама инженери, на които е даден един и същ OpenBSD шлюз, често ще ви предложат два различни набора от правила за достигане до отдалечена мрежа и двата могат да бъдат защитени. Изборът между транслация на източника и обратен маршрут изобщо не е въпрос на синтаксис. Всичко опира до това какво отдалечената страна вече знае за 192.168.88.0/24 и какво трябва да запазите в логовете си. Сбъркайте това и редът nat-to ще изглежда напълно правилен, докато отговорите изчезват в отдалечения шлюз по подразбиране.

Маршрутирането и пренаписването отговарят на различни въпроси

Таблицата за маршрутизация решава, че 172.20.0.0/16 е достъпен през tun0, и това решение се взема, преди да бъде консултирана каквато и да е pf транслация. След това транслацията на източника променя заглавката на пакета, така че отдалечената страна да види тунелния адрес на шлюза вместо LAN хост. Нито един механизъм не замества другия: правило nat не може да създаде маршрут от нищото, а маршрут не може да убеди отдалечен рутер, който никога не е чувал за вашата частна подмрежа. Когато отдалечената страна няма обратен път, отговорите се изхвърлят или препращат към нейния шлюз по подразбиране и никакво настройване на правила не поправя това.

Казано просто, препращането отговаря накъде отива трафикът, а транслацията — от кого изглежда, че идва. Дръжте ги в отделни мисловни кутии, докато проектирате набора от правила.

Три условия, които решават въпроса

Задайте три въпроса по ред и дизайнът обикновено се избира сам. Има ли отдалечената мрежа статичен маршрут, сочещ към тунелния адрес за 192.168.88.0/24, или нейният администратор контролира рутерите по този път? Ако да, оставете LAN адресите да пътуват непроменени и пропуснете транслацията напълно. Нуждаете ли се от видимост за всеки клиент от отдалечената страна — за политика за достъп или за одиторска следа? Ако да, запазването на източника си струва работата по маршрутизацията. Достатъчно стабилен ли е тунелният адрес, за да го запишете в отдалечен маршрут, или той се променя между повторните свързвания?

Ако който и да е отговор е не или неизвестен, nat-to е прагматичният вариант и той също е обратимият. Правилото за транслация се премахва с един ред, след като отдалечената страна добави подходящ маршрут. Обратен маршрут, който така и не е бил инсталиран, ви струва тема в поддръжката всеки път, когато някой попита защо тунелът работи само в една посока.

Поставете фрагмента там, където pf наистина ще го оцени

Фрагментът по-долу предполага, че LAN е 192.168.88.0/24, отдалечената мрежа е 172.20.0.0/16, а тунелният интерфейс е tun0. Нищо в него не избира следващ хоп. Той само пренаписва източника на пакети, които вече напускат през тунела.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Две подробности в първия ред носят по-голямата част от тежестта. Скобите около tun0 казват на pf да чете адреса на интерфейса всеки път, когато изгражда запис за състояние, което е важно, когато тунелът бъде преномериран след повторно свързване. Думата match означава, че правилото пренаписва и след това пропада надолу, така че отделно правило pass все още трябва да допусне потока. Интерфейсът, посочен в реда match, също трябва да е този, който таблицата за маршрутизация избира, иначе pf оценява правилото на различен изходящ път от този, който пакетът действително поема.

Не забравяйте страната на ядрото. Препращането на IPv4 трябва да е включено и правилата pass със състояние за тунела и LAN трябва да съществуват, преди всичко това да има смисъл. Разделът PF NAT в OpenBSD FAQ е правилната справка за реда на ключовите думи тук.

Проверете набора от правила, преди да се доверите на трафика

Първо проверете синтаксиса с pfctl -nf /etc/pf.conf, който анализира файла, без да го зарежда. След това заредете политиката и прочетете какво действително държи ядрото, защото правило, което се е анализирало чисто, все още може да бъде засенчено или прикачено към грешния интерфейс. pfctl -sn отпечатва правилата за транслация в заредения им вид, а pfctl -sr отпечатва правилата за филтриране в реда на оценяване.

След това наблюдавайте кабела. На шлюза tcpdump -ni tun0 'host 172.20.0.10' показва дали адресът на източника, напускащ тунела, е тунелният адрес или LAN хостът. Бърз netstat -rn -f inet потвърждава към кой интерфейс се разрешава дестинацията. Щом трафикът потече, pfctl -ss изброява записите за състояние; ако поток не е създал състояние, пакетът никога не е съвпаднал с правило, което го създава.

Ако тунелната страна изглежда наред, а отговорите все още не пристигат, спрете да редактирате pf. Останалата повреда е на отдалечения рутер, където отговорът се изпраща към частен адрес, който тази страна не може да достигне.

Когато транслацията струва повече, отколкото спестява

Транслацията скрива клиентите и понякога това е точно грешната сделка. Припокриващите се подмрежи са един случай: ако отдалечената страна също използва 192.168.88.0/24 вътрешно, представянето на LAN хостовете като шлюз прави сблъсъка по-лош, а не по-добър. IPsec политиките, които избират трафик по двойка адреси, са друг, защото базата данни с политики за сигурност се съпоставя преди транслацията и никога не вижда пренаписания ви пакет. Всяко внедряване, което таксува, ограничава или одитира за всеки потребител, също губи самоличността, от която се нуждае, в момента, в който източникът се свие до един адрес.

Преносимите производни на pf са отделен капан. Продуктите, които генерират собствени файлове с правила, очакват NAT да се конфигурира през техния интерфейс, а ръчно редактираните фрагменти се презаписват при следващото презареждане. Набори от правила, копирани от ръководства, написани преди съществуването на ключовата дума match, няма да се заредят на текущо ядро, затова пренесете синтаксиса и прочетете грешката, вместо да гадаете.

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