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 препраќањето мора да биде овозможено, а stateful 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 нема да се вчитаат на тековното јадро, затоа пренеси ја синтаксата и прочитај ја грешката наместо да погодуваш.

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