LAN NAT caur tun0 OpenBSD VPN vārtejā

Divi inženieri ar vienu un to pašu OpenBSD vārteju bieži dos jums divus dažādus kārtulu kopumus, lai sasniegtu attālo tīklu, un abus var aizstāvēt. Izvēle starp avota tulkošanu un atgriešanās maršrutu nemaz nav sintakses jautājums. Viss atkarīgs no tā, ko otrā puse jau zina par 192.168.88.0/24, un no tā, kas jāsaglabā žurnālos. Kļūdieties šeit, un nat-to rinda izskatīsies pilnīgi pareiza, kamēr atbildes pazudīs attālajā noklusējuma vārtejā.

Maršrutēšana un pārrakstīšana atbild uz atšķirīgiem jautājumiem

Maršrutēšanas tabula nolemj, ka 172.20.0.0/16 ir sasniedzams caur tun0, un šis lēmums tiek pieņemts pirms jebkādas pf tulkošanas konsultēšanas. Pēc tam avota tulkošana maina paketes galveni, lai attālais gals redzētu vārtejas tuneļa adresi, nevis LAN saimnieku. Neviens mehānisms neaizstāj otru: nat kārtula nevar radīt maršrutu, un maršruts nevar pārliecināt attālo maršrutētāju, kas nekad nav dzirdējis par jūsu privāto apakštīklu. Ja otrai pusei trūkst atgriešanās ceļa, atbildes tiek izmestas vai pārvirzītas uz tās noklusējuma vārteju, un nekāda kārtulu pielāgošana to nelabo.

Vienkārši sakot, pārsūtīšana atbild, kur trafiks iet, bet tulkošana – no kurienes tas šķiet nākam. Turiet tos atsevišķās domāšanas kastītēs, kamēr projektējat kārtulu kopumu.

Trīs nosacījumi, kas izšķir

Uzdodiet trīs jautājumus pēc kārtas, un dizains parasti izvēlas pats. Vai attālajam tīklam ir statisks maršruts uz tuneļa adresi 192.168.88.0/24 vajadzībām, vai arī tā administrators kontrolē maršrutētājus šajā ceļā? Ja jā, ļaujiet LAN adresēm ceļot nemainītām un pilnībā izlaidiet tulkošanu. Vai jums ir vajadzīga redzamība katram klientam otrā pusē – piekļuves politikai vai audita pēdām? Ja jā, avota saglabāšana ir tā vērta. Vai tuneļa adrese ir pietiekami stabila, lai to ierakstītu attālā maršrutā, vai tā mainās starp savienojumiem?

Ja kāda atbilde ir nē vai nav zināma, nat-to ir pragmatiskā izvēle, un tā ir arī atgriežama. Tulkošanas kārtula tiek izņemta vienā rindā, tiklīdz otrā puse pievieno pienācīgu maršrutu. Atgriešanās maršruts, kas nekad netika instalēts, katru reizi, kad kāds jautā, kāpēc tunelis darbojas tikai vienā virzienā, izmaksā vienu atbalsta sarunu.

Novietojiet fragmentu tā, lai pf to tiešām novērtētu

Tālāk esošais fragments pieņem, ka LAN ir 192.168.88.0/24, attālais tīkls ir 172.20.0.0/16 un tuneļa interfeiss ir tun0. Tajā nekas neizvēlas nākamo lēcienu. Tas tikai pārraksta avotu paketēs, kas jau iziet caur tuneli.

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

Divi pirmās rindas sīkumi nes lielāko svaru. Iekavas ap tun0 liek pf katru reizi, kad tas veido stāvokļa ierakstu, nolasīt interfeisa adresi, un tas ir svarīgi, kad pēc atkārtota savienojuma tunelis tiek pārnumurēts. Vārds match nozīmē, ka kārtula pārraksta un pēc tam nokrīt tālāk, tāpēc atsevišķai pass kārtulai joprojām ir jāielaiž plūsma. Match rindā nosauktajam interfeisam jābūt arī tam, ko izvēlas maršrutēšanas tabula, citādi pf novērtēs kārtulu citā izejas ceļā nekā tas, pa kuru pakete patiešām iet.

Neaizmirstiet kodola pusi. IPv4 pārsūtīšanai jābūt iespējotai, un tuneļa un LAN stāvokļa pass kārtulām jābūt pirms tam, kad tas viss iegūst jēgu. OpenBSD BUJ sadaļa PF NAT ir pareizā atsauce uz atslēgvārdu secību šeit.

Pārbaudiet kārtulu kopumu, pirms uzticaties trafikam

Vispirms pārbaudiet sintaksi ar pfctl -nf /etc/pf.conf, kas failu parsē, to neielādējot. Pēc tam ielādējiet politiku un nolasiet, ko kodols patiešām tur, jo kārtula, kas tika tīri parsēta, joprojām var būt aizēnota vai piesaistīta nepareizam interfeisam. pfctl -sn izdrukā tulkošanas kārtulas to ielādētajā formā, un pfctl -sr izdrukā filtra kārtulas novērtēšanas secībā.

Tālāk vērojiet vadu. Uz vārtejas tcpdump -ni tun0 'host 172.20.0.10' parāda, vai avota adrese, kas iziet no tuneļa, ir tuneļa adrese vai LAN saimnieks. Ātrs netstat -rn -f inet apstiprina, uz kuru interfeisu mērķis tiek atrisināts. Kad trafiks sāk plūst, pfctl -ss uzskaita stāvokļa ierakstus; ja plūsma nav radījusi stāvokli, pakete nekad nav saskārusies ar kārtulu, kas to radītu.

Ja tuneļa puse izskatās pareiza un atbildes tomēr nenāk, pārtrauciet rediģēt pf. Atlikušais bojājums ir attālajā maršrutētājā, kur atbilde tiek sūtīta uz privātu adresi, ko šī puse nevar sasniegt.

Kad tulkošana izmaksā vairāk, nekā ietaupa

Tulkošana slēpj klientus, un dažkārt tas ir tieši nepareizais darījums. Pārklājošie apakštīkli ir viens gadījums: ja otrā puse iekšēji arī izmanto 192.168.88.0/24, LAN saimnieku parādīšana kā vārteja sadursmi padara sliktāku, nevis labāku. IPsec politikas, kas atlasa trafiku pēc adrešu pāra, ir otrs gadījums, jo drošības politikas datubāze tiek saskaņota pirms tulkošanas un nekad neredz pārrakstīto paketi. Jebkurš izvietojums, kas aprēķina, ierobežo vai audita lietotāju līmenī, arī zaudē identitāti, kas tam vajadzīga tajā mirklī, kad avots sabrūk līdz vienai adresei.

Pārnēsājamie pf atvasinājumi ir atsevišķas lamatas. Produkti, kas paši ģenerē kārtulu failus, sagaida, ka NAT tiks konfigurēts caur to interfeisu, un ar roku rediģēti fragmenti tiek pārrakstīti nākamajā ielādē. Kārtulu kopumi, kas nokopēti no rokasgrāmatām, kas rakstītas pirms atslēgvārda match parādīšanās, netiks ielādēti pašreizējā kodolā, tāpēc pārnesiet sintaksi un lasiet kļūdu, nevis miniet.

Lēmuma kārtula, kas pārdzīvo saskari ar reāliem tīkliem, ir īsa: instalējiet atgriešanās maršrutu, kad varat, tulkojiet, kad nevarat, un pierakstiet, kurš no trim nosacījumiem lika jums tā izvēlēties. Šī piezīme ietaupa nākamajam cilvēkam pēcpusdienu.