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 правила која бирају саобраћај по пару адреса други су случај, јер се база сигурносних правила упоређује пре превођења и никада не види твој препиcани пакет. Свако постављање које наплаћује, ограничава или ревидира по кориснику такође губи идентитет који му треба у тренутку кад се извор сведе на једну адресу.

Преносиви pf деривати засебна су замка. Производи који сами генеришу датотеке правила очекују да се NAT конфигурише кроз њихов интерфејс, а ручно уређени уломци бивају препиcани при следећем учитавању. Скупови правила препиcани из водича написаних пре него што је кључна реч match постојала неће се учитати на тренутном језгру, па пренеси синтаксу и прочитај грешку уместо да нагађаш.

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