Avota maršrutēšana diviem VPN pūliem: ko jūsu noteikums palaiž garām
from formas noteikums atbilst klienta adresei pirms SNAT to pārraksta, un tests no gateway neatbilst nevienam no tiem. Veiciet meklēšanu katram pūlam un tā vietā lasiet prioritātes.
Divi klientu pūli, viena gateway un plāns šķiet triviāls: viens noteikums izlaiž pirmo pūlu pa ātro augšupceļu, otrs izlaiž otro pūlu pa partnera tuneli. Tad noteikumi ir vietā, un otrais pūls joprojām iziet pa noklusējuma maršrutu. Noteikums nav salauzts. Paketes avots nav tas, ko autors gaidīja meklēšanas brīdī, jo tulkošana un meklēšana notiek dažādos vienas paketes ceļojuma punktos, un secība ir pretēja tai prāta diagrammai, ko zīmē vairums.
Meklēšana notiek pirms avota pārrakstīšanas
Paketei, kas tiek pārsūtīta no VPN klienta, kodols izpilda fiksētu secību. Tā nonāk tuneļa saskarnē, iziet caur prerouting, kur mīt conntrack un DNAT, tad tiek pieņemts maršrutēšanas lēmums, tad pārsūtīšana, tad postrouting, kur SNAT tiek piemērots pēdējais. from formas noteikums tiek apskatīts šī maršrutēšanas lēmuma laikā, tas nozīmē, ka tas redz klienta sākotnējo adresi, nevis tulkoto.
Tātad masquerade noteikuma pievienošana nemaina to, kura politika atbilst izejošajai plūsmai. Mainās tas, ko redz tālais gals, un līdz ar to, kāds atgriešanās ceļš pastāv. Tās ir divas dažādas sekas, un izmaiņu apskati tās nemitīgi jauc. Atdaliet tās, un dizains parasti kļūst skaidrs minūtes laikā.
Tieši atbildes virzienā tulkotā adrese parādās noteikumos. Pakete, kas atgriežas pie gateway, ir adresēta tulkotajai adresei, un, ja jums ir politikas noteikumi pēc galamērķa vai saskarnes, pa kuru tā ienāca, tieši šī vērtība tiks salīdzināta. Tas pats savienojums, katrā virzienā cits patiesības avots.
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
Tātad diviem pūliem ar dažādiem avotiem tiešām vajadzīgas dažādas tabulas, un dizains ir pareizs. To, ko iepriekšējā tabula izslēdz, ir apiešanas ceļš atkļūdot, skatoties, ko saņēma tālā vietne, un no tā izsecinot noteikumu.
Tests no gateway nav pūla tests
Satiksme, ko ģenerē pats gateway, nekad neiziet caur prerouting, jo tā nav ieradusies nevienā saskarnē. Tā tiek maršrutēta izvades ceļā, kā avotu izmantojot paša gateway adresi, un klientu diapazonam piesaistītais from noteikums nesakritīs. Katrs šīs jomas pieteikums, kas saka, ka no kastes strādā, bet no klienta ne, ir tā paša fakta atkārtojums.
Imitējiet klientu, nevis tuviniet to. Maršrutēšanas meklējumam var jautāt tieši, norādot avotu un ieejas saskarni:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201Palaidiet to vienreiz katram pūlam. Ja abas komandas atgriež vienu un to pašu saskarni, noteikumi pūlus neatdala, un iemesls ir vai nu trūkstošs noteikums, vai abiem atbilstošs augstākas prioritātes noteikums. Ja tās atgriež dažādas saskarnes, bet klients joprojām cieš neveiksmi, kļūda ir pēc meklēšanas, un jūs varat pārtraukt skatīties noteikumus.
Prioritāte, nevis vieta failā
Noteikumi tiek vērtēti pieaugošā prioritātes secībā, un svarīgs ir skaitlis, nevis secība, kādā tos ierakstījāt. local tabula atrodas uz prioritātes 0, main tabula uz 32766, bet noklusējuma noteikums uz 32767, tāpēc ar noklusējuma prioritāti pievienots noteikums nonāk saraksta beigās un zaudē gandrīz visam.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201Skaidra prioritāte padara paredzēto secību redzamu failā un apskatā. Tā arī neļauj vēlākam papildinājumam klusi apsteigt esošu noteikumu, un tas ir biežākais iemesls, kāpēc strādājoša politika pārstāj strādāt pēc nesaistītas izmaiņas.
Atbilstošs noteikums, kas norāda uz nepilnīgu tabulu, ir otrs slazds. Ja tabulā 201 ir noklusējuma maršruts, bet nav maršruta uz galamērķi, pakete tiek izmesta vai nosūtīta nepareizā vietā, un noteikums izolācijā izskatās pilnīgi pareizs. Lasiet tabulu, ne tikai noteikumu. Noteikums ir rādītājs, un tukša tabula ir rādītājs uz nekurieni.
Atgriešanās ceļam joprojām jāpastāv
Avota politika izvēlas izeju. Tā nerada atgriešanās ceļu. Ja otrais pūls iziet pa partnera tuneli, partnerim jāzina, kā sasniegt 172.31.8.0/24, vai nu ar atgriešanās maršrutu uz gateway, vai saņemot tulkotas adreses, ko tas jau zina.
Izvēle starp tiem ir dizaina lēmums ar redzamām sekām. Klientu diapazona maršrutēšana atpakaļ saglabā katra klienta identitāti pie partnera un prasa, lai tas pieņemtu jūsu prefiksu. Tulkošana paslēpj pūlu aiz vienas adreses un prasa, lai partneris pieņemtu tikai šo adresi, par cenu, ka jūsu un viņa žurnāli vairs nevar vienoties par to, kurš pieslēdzās.
Lai ko jūs izvēlētos, pierakstiet to blakus pūla definīcijai. Atgriešanās maršruts, kas pastāv tikai kāda atmiņā, ir tieši tas, kas saglabājas, līdz partneris nomaina ugunsmūri, un pēc tam prasa dienu, lai to atjaunotu.
Neķeriet paša gateway tuneli politikā
Noteikumi, ko rakstāt klientiem, attiecas arī uz satiksmi, ko ģenerē gateway, ja vien to neizslēdzat. Plašs noteikums pēc atzīmes vai izvades saskarnes var noķert paša gateway savienojumu ar partneri, un tad tunelis, kas nes politiku, tiek maršrutēts pēc politikas. Tas rada cilpu vai pārtraukumu, kas izskatās pēc pakalpojumu sniedzēja kļūdas.
Ierobežojiet katru noteikumu pēc iespējas šaurāk: avota prefikss, ieejas saskarne un, kur tas tiek atbalstīts, atzīme, ko nes tikai klientu paketes. Pēc tam pēc katras noteikumu izmaiņas pārbaudiet paša gateway savienojamību, jo kļūda ir pašreferenciāla un neparādās klienta testā.
ip-rule rokasgrāmatas lapa dokumentē selektora un prioritātes semantiku. Apvienojiet to ar meklēšanas testu katram pūlam, un dizains kļūst pārbaudāms, un tā ir atšķirība starp politikas maršrutēšanu, kas iztur gadu, un to, ko visi baidās aiztikt.