NAT LAN-a kroz tun0 na OpenBSD VPN pristupniku

Dva inženjera s istim OpenBSD pristupnikom često će ti dati dva različita skupa pravila za dosezanje udaljene mreže, a oba se mogu braniti. Izbor između prevođenja izvora i povratne rute nije uopće pitanje sintakse. Sve se svodi na to što suprotna strana već zna o 192.168.88.0/24 i što trebaš zadržati u svojim zapisima. Pogriješiš li u tome, nat-to linija izgledat će savršeno ispravno dok odgovori nestaju u udaljenom zadanom pristupniku.

Usmjeravanje i prepisivanje odgovaraju na različita pitanja

Tablica usmjeravanja odlučuje da je 172.20.0.0/16 dostupan preko tun0, i ta se odluka donosi prije nego što se konzultira bilo kakvo pf prevođenje. Prevođenje izvora zatim mijenja zaglavlje paketa tako da udaljeni kraj vidi adresu tunela pristupnika umjesto računala na LAN-u. Nijedan mehanizam ne zamjenjuje drugi: nat pravilo ne može stvoriti rutu, a ruta ne može uvjeriti udaljeni usmjerivač koji nikad nije čuo za tvoju privatnu podmrežu. Kad udaljenoj strani nedostaje povratni put, odgovori se odbacuju ili prosljeđuju njezinu zadanom pristupniku, i nikakvo podešavanje pravila to ne ispravlja.

Jednostavno rečeno, prosljeđivanje odgovara kamo promet ide, a prevođenje odgovara odakle izgleda da dolazi. Drži ih u odvojenim mentalnim kutijama dok osmišljavaš skup pravila.

Tri uvjeta koja odlučuju

Postavi tri pitanja po redu i dizajn se obično sam odabere. Ima li udaljena mreža statičku rutu koja pokazuje na adresu tunela za 192.168.88.0/24, ili njezin administrator kontrolira usmjerivače na tom putu? Ako da, pusti LAN adrese da putuju nepromijenjene i potpuno preskoči prevođenje. Trebaš li vidljivost po klijentu na suprotnoj strani, bilo za pravila pristupa bilo za revizijski trag? Ako da, čuvanje izvora vrijedi truda oko usmjeravanja. Je li adresa tunela dovoljno stabilna da se upiše u udaljenu rutu, ili se mijenja između ponovnih spajanja?

Ako je bilo koji odgovor ne ili nepoznat, nat-to je pragmatična opcija, a ujedno i povratna. Pravilo prevođenja uklanja se jednim retkom kad udaljena strana doda ispravnu rutu. Povratna ruta koja nikad nije ugrađena stoji te jedne niti podrške svaki put kad netko pita zašto tunel radi samo u jednom smjeru.

Smještanje ulomka tako da ga pf doista vrednuje

Ulomak u nastavku pretpostavlja da je LAN 192.168.88.0/24, udaljena mreža 172.20.0.0/16, a sučelje tunela tun0. Ništa u njemu ne bira sljedeći skok. On samo prepisuje izvor na paketima koji već izlaze kroz tunel.

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

Dva detalja u tom prvom retku nose najveći teret. Zagrade oko tun0 govore pf-u da pročita adresu sučelja svaki put kad gradi zapis stanja, što je važno kad se tunel ponovno numerira nakon ponovnog spajanja. Riječ match znači da pravilo prepisuje i zatim propada dalje, pa zasebno pass pravilo još mora pustiti tok. Sučelje navedeno u match retku također mora biti ono koje odabire tablica usmjeravanja, inače pf vrednuje pravilo na drugom izlaznom putu od onoga kojim paket stvarno ide.

Ne zaboravi stranu jezgre. IPv4 prosljeđivanje mora biti omogućeno, a stateful pass pravila za tunel i LAN moraju postojati prije nego išta od ovoga ima smisla. Odjeljak PF NAT u OpenBSD FAQ-u pravi je izvor za redoslijed ključnih riječi ovdje.

Provjeri skup pravila prije nego što povjeruješ prometu

Najprije provjeri sintaksu s pfctl -nf /etc/pf.conf, koji analizira datoteku bez učitavanja. Zatim učitaj pravila i pročitaj što jezgra stvarno drži, jer pravilo koje se čisto analiziralo može ipak biti zasjenjeno ili pridruženo pogrešnom sučelju. pfctl -sn ispisuje pravila prevođenja u njihovu učitanom obliku, a pfctl -sr ispisuje pravila filtriranja redoslijedom vrednovanja.

Zatim promatraj žicu. Na pristupniku tcpdump -ni tun0 'host 172.20.0.10' pokazuje je li izvorna adresa koja izlazi iz tunela adresa tunela ili LAN računala. Brzi netstat -rn -f inet potvrđuje na koje se sučelje odredište razrješava. Kad promet poteče, pfctl -ss ispisuje zapise stanja; ako tok nije stvorio stanje, paket nikad nije pogodio pravilo koje ga stvara.

Ako strana tunela izgleda ispravno, a odgovori još ne dolaze, prestani uređivati pf. Preostali kvar je na udaljenom usmjerivaču, gdje se odgovor šalje prema privatnoj adresi koju ta strana ne može dosegnuti.

Kad prevođenje košta više nego što štedi

Prevođenje skriva klijente, a ponekad je to upravo pogrešna razmjena. Preklapajuće podmreže jedan su slučaj: ako udaljena strana interno također koristi 192.168.88.0/24, predstavljanje LAN računala kao pristupnika pogoršava sudar umjesto da ga poboljša. IPsec pravila koja odabiru promet po paru adresa drugi su slučaj, jer se baza sigurnosnih pravila uspoređuje prije prevođenja i nikad ne vidi tvoj prepisani paket. Svako postavljanje koje naplaćuje, ograničava ili revidira po korisniku također gubi identitet koji mu treba u trenutku kad se izvor svede na jednu adresu.

Prenosivi pf derivati zasebna su zamka. Proizvodi koji sami generiraju datoteke pravila očekuju da se NAT konfigurira kroz njihovo sučelje, a ručno uređeni ulomci bivaju prepisani pri sljedećem učitavanju. Skupovi pravila prepisani iz vodiča napisanih prije nego što je ključna riječ match postojala neće se učitati na trenutačnoj jezgri, pa prenesi sintaksu i pročitaj pogrešku umjesto da nagađaš.

Pravilo odlučivanja koje preživi susret s pravim mrežama kratko je: ugradi povratnu rutu kad možeš, prevedi kad ne možeš, i zapiši koji od tri uvjeta te je naveo na taj izbor. Ta bilješka štedi sljedećoj osobi cijelo poslijepodne.