NAT za LAN kroz tun0 na OpenBSD VPN mrežnom prolazu

Dva inženjera koja dobiju isti OpenBSD mrežni prolaz često će vam 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 udaljena strana već zna o 192.168.88.0/24 i što trebate zadržati u svojim zapisima. Pogriješite li to, nat-to redak izgledat će savršeno ispravno dok odgovori nestaju u udaljenom zadanom prolazu.

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 se konzultira bilo koje pf prevođenje. Prevođenje izvora zatim mijenja zaglavlje paketa tako da udaljena strana vidi adresu tunela mrežnog prolaza umjesto LAN računala. Nijedan mehanizam ne zamjenjuje drugi: nat pravilo ne može stvoriti rutu ni iz čega, a ruta ne može uvjeriti udaljeni usmjerivač koji nikada nije čuo za vašu privatnu podmrežu. Kada udaljenoj strani nedostaje povratna putanja, odgovori se odbacuju ili prosljeđuju njezinu zadanom prolazu, i nikakvo podešavanje pravila to ne ispravlja.

Jednostavno rečeno, prosljeđivanje odgovara kamo promet ide, a prevođenje odgovara od koga se čini da dolazi. Držite ih u odvojenim misaonim kutijama dok osmišljavate skup pravila.

Tri uvjeta koja odlučuju

Postavite 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, pustite LAN adrese da putuju nepromijenjene i potpuno preskočite prevođenje. Trebate li vidljivost po klijentu na udaljenoj strani, bilo za politiku 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 je i reverzibilna. Pravilo prevođenja uklanja se u jednom retku nakon što udaljena strana doda ispravnu rutu. Povratna ruta koja nikada nije instalirana stoji vas nit podrške svaki put kad netko pita zašto tunel radi samo u jednom smjeru.

Smjestite fragment tako da ga pf doista ocjenjuje

Fragment 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 odabire 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 većinu težine. Zagrade oko tun0 kažu pf-u da pročita adresu sučelja svaki put kad gradi zapis stanja, što je važno kad se tunel prenumerira nakon ponovnog spajanja. Riječ match znači da pravilo prepisuje i zatim propada dalje, pa zasebno pass pravilo ipak mora propustiti tok. Sučelje navedeno u match retku također mora biti ono koje odabire tablica usmjeravanja, inače pf ocjenjuje pravilo na drukčijoj izlaznoj putanji od one kojom paket stvarno ide.

Ne zaboravite stranu jezgre. Prosljeđivanje IPv4 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.

Provjerite skup pravila prije nego povjerujete prometu

Najprije provjerite sintaksu s pfctl -nf /etc/pf.conf, koji raščlanjuje datoteku bez učitavanja. Zatim učitajte politiku i pročitajte što jezgra doista drži, jer pravilo koje se čisto raščlanilo ipak može biti zasjenjeno ili priključeno na pogrešno sučelje. pfctl -sn ispisuje pravila prevođenja u učitanom obliku, a pfctl -sr ispisuje pravila filtriranja redoslijedom ocjenjivanja.

Zatim gledajte žicu. Na mrežnom prolazu tcpdump -ni tun0 'host 172.20.0.10' pokazuje je li izvorna adresa koja napušta tunel adresa tunela ili LAN računalo. Brzi netstat -rn -f inet potvrđuje na koje se sučelje odredište razrješava. Kad promet poteče, pfctl -ss izlistava zapise stanja; ako tok nije stvorio stanje, paket nikada nije odgovarao pravilu koje ga stvara.

Ako strana tunela izgleda ispravno, a odgovori ipak nikada ne stignu, prestanite uređivati pf. Preostali kvar je na udaljenom usmjerivaču, gdje se odgovor šalje prema privatnoj adresi do koje ta strana ne može doći.

Kada 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 također interno koristi 192.168.88.0/24, predstavljanje LAN računala kao mrežnog prolaza čini sudar gorim, a ne boljim. IPsec politike koje odabiru promet po paru adresa druga su, jer se baza podataka sigurnosne politike podudara prije prevođenja i nikada ne vidi vaš prepisani paket. Svaka implementacija koja naplaćuje, ograničava ili revidira po korisniku također gubi identitet koji joj je potreban 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 fragmenti bivaju prepisani pri sljedećem ponovnom učitavanju. Skupovi pravila kopirani iz vodiča napisanih prije postojanja ključne riječi match neće se učitati na trenutačnoj jezgri, pa prenesite sintaksu i pročitajte pogrešku umjesto da nagađate.

Pravilo odluke koje preživi susret sa stvarnim mrežama kratko je: instalirajte povratnu rutu kad možete, prevodite kad ne možete, i zapišite koji od tri uvjeta vas je naveo na odabir. Ta bilješka štedi sljedećoj osobi jedno poslijepodne.