Maršrutējiet starp privātiem LAN, pirms pievienojat vēl vienu NAT

Divi iekšējie ugunsmūri, viens privāts tranzīta segments un lūgums ļaut dažiem hostiem katrā LAN sazināties ar otras LAN hostiem. Ierastā reakcija ir uzcelt VPN vai pievienot otru NAT slāni, un abas reakcijas maksā vairāk, nekā problēma ir pelnījusi. Parasta maršrutēšana ir pietiekama, ja izpildās trīs nosacījumi: adrešu diapazoni nepārklājas, abas puses var nosūtīt trafiku atpakaļ uz otru LAN, un tranzīta segments datiem jau ir pietiekami uzticams. Pārbaudiet šos trīs, pirms kaut ko projektējat, jo katrs no tiem maina atbildi.

Trīs nosacījumi, kas nosaka dizainu

Pirmais nosacījums ir adrešu telpa. Ja abi LAN izmanto vienu un to pašu RFC 1918 bloku, maršrutēšana tos nevar atšķirt, un tulkošana kļūst neizbēgama, nevis izvēles. Otrais ir atgriezes ceļš: maršruts no A uz B ir bezjēdzīgs, ja B arī nezina, kā sasniegt A LAN, un asimetriskas zināšanas ir visbiežākais iemesls, kāpēc maršrutēts dizains klusi izmet atbildes.

Trešais ir uzticēšanās. Maršrutēšana pārvieto paketes; tā tās neaizsargā. Privāts tranzīta segments vienā ēkā ir kas cits nekā nodošana pakalpojumu sniedzējam vai saite, kas šķērso kopīgu kampusa maģistrāli. Ja segmentam neuzticas, atbilde ir tunelis starp abiem ugunsmūriem, un zemāk dotais maršrutēšanas plāns tajā joprojām ir spēkā.

Vienkāršais dizains uzvar tikai tad, kad visi trīs rāda vienā virzienā. Ja kāds no tiem neizdodas, izlabojiet tieši šo nosacījumu, nevis maskējiet to ar tulkošanu, jo NAT slēpj kļūmi, nevis to atrisina.

Veidojiet maršrutu plānu tranzīta tīklā

Piešķiriet katram ugunsmūrim adresi kopīgajā segmentā un pievienojiet vienu konkrētu maršrutu katram attālajam LAN. Nekas cits esošajā konfigurācijā nav jāpārvieto, un jo īpaši interneta noklusējuma maršrutam jāpaliek tieši tur, kur tas ir. Noklusējuma maršruta aizstāšana ar partnera ugunsmūri nosūtītu katru nesaistīto galamērķi caur tranzītu, kas ir daudz lielāka izmaiņa nekā pieprasītā. pfSense statiskās maršrutēšanas dokumentācija apraksta to pašu maršruta-plus-vārtejas modeli šai platformai, un līdzvērtīgs vadīkls pastāv jebkurā ugunsmūrī, ko jūs faktiski lietojat.

Ugunsmūris A apkalpo 10.30.0.0/24, bet ugunsmūris B apkalpo 10.40.0.0/24, un abas tranzīta adreses ir 192.0.2.0/24. Katrs LAN hosts patur savu vietējo ugunsmūri kā vārteju, tāpēc vienīgais jaunais stāvoklis ir viens maršruts katrā pusē. Uz Linux bāzētā ugunsmūrī tas pats plāns izskatās šādi, un pāradresācijai jābūt iespējotai, citādi maršruts tiks atrisināts, bet pakete tiks nomesta.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Turiet filtrēšanu atsevišķi no tulkošanas

Maršrutēšana un politika ir dažādas vadīklas, un tieši otrajā lielākā daļa maršrutēto dizainu patiešām cieš neveiksmi. Atļaujiet konkrētus avotus, galamērķus un pakalpojumus ievades robežā, ko paketes patiešām šķērso, un atcerieties, ka saskarnes marķējums, piemēram, WAN, ir nosaukums, nevis apgalvojums par uzticēšanos. Tranzīta portā, kas pārvadā privātu trafiku, joprojām var būt iespējota privāto adrešu bloķēšana pēc noklusējuma.

Pēc tam apskatiet izejošo tulkošanu, pirms secināt, ka NAT nenotiek. Automātiski izejošie noteikumi var pārrakstīt trafiku, kas nekad nav bijis paredzēts tulkošanai, un tas iznīcina avota adreses, kas otrai pusei vajadzīgas tās politikai un žurnāliem. Apstipriniet, ka atlasītās plūsmas saglabā sākotnējās adreses, un atstājiet interneta tulkošanas noteikumus mierā trafikam, kam tie vēl vajadzīgi.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

Kad NAT ir godīgā atbilde

Tulkošana pelna savu vietu, kad adrešu diapazoni patiešām pārklājas un pārnumurēšana nav pieejama, vai kad politika pieprasa, lai viena puse redz vienu adresi, nevis apakštīklu. Šādos gadījumos apzināta viens-pret-vienu vai portiem ierobežota kartēšana ir dizaina lēmums ar zināmām sekām, nevis apiešanas risinājums.

Sekas, kas jāsaka skaļi, ir tādas, ka otra puse vairs nevar redzēt vai filtrēt atsevišķus avotus. Žurnāli sakļaujas līdz tulkojošajai adresei, politika katram hostam pārstāj darboties, un problēmu novēršana pārvēršas medībās pēc tā, kuram iekšējam hostam konkrētā brīdī bija plūsma. Ja nekas no tā nav svarīgi attiecīgajam trafikam, NAT ir kārtībā.

Kad pats tranzīts ir nepareizais pieņēmums

Ja kopīgais segments šķērso pakalpojumu sniedzēju, kopīgu komutācijas audumu vai jebkuru ceļu, kur cita puse varētu lasīt trafiku, tikai maršrutēšana nav pilnīga atbilde. Tunelis starp abiem ugunsmūriem dod konfidencialitāti un partnera autentifikāciju, un maršrutu tabula tajā ir tā pati tabula, ko jūs būtu rakstījuši tranzītā.

Izlemiet to pēc uzticēšanās jautājuma pirmajā sadaļā, nevis pēc ieraduma, ka VPN ir drošāki. Tunelis virs jau privāta segmenta pievieno ekspluatācijas izmaksas un vēl vienu kļūmes režīmu bez ieguvuma, savukārt maršrutēšana virs neuzticama segmenta apmaina konfidencialitāti pret vienkāršību, ko nevarat atļauties. Pierakstiet, kurš no trim nosacījumiem noteica izvēli, un nākamajam inženierim tas nebūs jāpārspriež no jauna.