Fonta itinerigado por du VPN-basenoj: kion via regulo maltrafas

Du klientaj basenoj, unu kluzo, kaj la plano aspektas bagatela: unu regulo sendas la unuan basenon tra la rapida suprenligo, alia sendas la duan basenon tra partnera tunelo. Poste la reguloj estas en loko kaj la dua baseno ankoraŭ eliras tra la apriora itinero. La regulo ne estas rompita. La fonto de la pakaĵo ne estas tio, kion la aŭtoro atendis en la momento de la serĉo, ĉar tradukado kaj serĉado okazas en malsamaj punktoj de la vojaĝo de la sama pakaĵo, kaj la ordo estas la malo de la mensa diagramo, kiun plej multaj homoj desegnas.

La serĉo okazas antaŭ ol la fonto estas reskribita

Por pakaĵo plusendata de VPN-kliento, la kerno plenumas fiksan sinsekvon. Ĝi alvenas sur la tunela interfaco, trapasas prerouting, kie loĝas conntrack kaj DNAT, poste oni faras la itineran decidon, poste plusendadon, poste postrouting, kie SNAT aplikiĝas laste. Regulo de la formo from estas konsultata dum tiu itinerdecido, do ĝi vidas la originan adreson de la kliento, ne la tradukitan.

Do aldoni masquerade-regulon ne ŝanĝas, kiu politiko kongruas kun la elira fluo. Ĝi ŝanĝas, kion vidas la malproksima flanko, kaj sekve kiun revenan vojon ekzistas. Tiuj estas du malsamaj sekvoj, kaj revizioj de ŝanĝoj konstante konfuzas ilin. Apartigu ilin kaj la dezajno kutime klariĝas ene de minuto.

En la responda direkto la tradukita adreso aperas en la reguloj. Pakaĵo revenanta al la kluzo estas adresita al la tradukita adreso, kaj se vi havas politikajn regulojn bazitajn sur la celo aŭ sur la interfaco, per kiu ĝi alvenis, tiu estas la valoro, kiun vi kongruos. Sama konekto, malsama fonto de vero en ĉiu direkto.

Do du basenoj kun malsamaj fontoj ja bezonas malsamajn tabelojn, kaj la dezajno estas sana. Kion la supra tabelo forigas estas la fuĝvojo sencimigi rigardante, kion ricevis la malproksima loko, kaj dedukti la regulon el tio.

Testo el la kluzo ne estas testo de la baseno

Trafiko, kiun la kluzo mem generas, neniam trapasas prerouting, ĉar ĝi ne alvenis sur interfacon. Ĝi estas itinerigita en la elira vojo, kun la propra adreso de la kluzo kiel fonto, kaj regulo from bazita sur klienta gamo ne kongruos. Ĉiu bileto en ĉi tiu kampo, kiu diras, ke ĝi funkcias el la maŝino sed ne el la kliento, estas tiu sama fakto ripetita.

Simulu la klienton anstataŭ proksimumigi ĝin. La itinera serĉo povas esti demandata rekte, kun fonto kaj enira interfaco:

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 201

Rulu ĝin unufoje por baseno. Se la du komandoj redonas la saman interfacon, la reguloj ne apartigas la basenojn, kaj la kialo estas aŭ mankanta regulo aŭ regulo kun pli alta prioritato, kiu kongruas kun ambaŭ. Se ili redonas malsamajn interfacojn sed la kliento ankoraŭ malsukcesas, la fuŝo estas post la serĉo kaj vi povas ĉesi rigardi regulojn.

Prioritato, ne pozicio en la dosiero

Reguloj estas taksataj en kreskanta prioritata ordo, kaj la nombro gravas, ne la ordo, en kiu vi tajpis ilin. La tabelo local staras ĉe prioritato 0, la tabelo main ĉe 32766 kaj la apriora regulo ĉe 32767, tial regulo aldonita kun la apriora prioritato finiĝas proksime al la fino de la listo kaj perdas kontraŭ preskaŭ ĉio.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

Eksplicita prioritato faras la celatan ordon videbla en la dosiero kaj en revizio. Ĝi ankaŭ malhelpas postan aldonon silente salti antaŭ ekzistantan regulon, kio estas la plej ofta kaŭzo, ke funkcianta politiko ĉesas funkcii post nerilata ŝanĝo.

Kongrua regulo montranta al nekompleta tabelo estas la alia kaptilo. Se tabelo 201 enhavas aproan itineron sed neniun itineron al la celo, la pakaĵo estas forĵetata aŭ sendata al la malĝusta loko, kaj la regulo aspektas tute ĝusta izolite. Legu la tabelon, ne nur la regulon. Regulo estas montrilo, kaj malplena tabelo estas montrilo en nenien.

La reena vojo ankoraŭ devas ekzisti

Fonta politiko elektas eliron. Ĝi ne kreas reenan vojon. Se la dua baseno eliras tra partnera tunelo, la partnero devas scii, kiel atingi 172.31.8.0/24, aŭ per itinero reen al la kluzo aŭ ricevante tradukitajn adresojn, kiujn ĝi jam konas.

Elekti inter tiuj estas dezajna decido kun videblaj sekvoj. Itinerigi la klientan gamon reen konservas la identecon de ĉiu kliento ĉe la partnero kaj postulas, ke ĝi akceptu vian prefikson. Tradukado kaŝas la basenon malantaŭ unu adreso kaj postulas, ke la partnero akceptu nur tiun adreson, je la kosto, ke viaj kaj ĝiaj protokoloj ne plu kongruas pri tio, kiu konektiĝis.

Kion ajn vi elektos, skribu ĝin apud la difino de la baseno. Reena itinero, kiu ekzistas nur en ies memoro, estas ĝuste tia afero, kiu postvivas ĝis la partnero ŝanĝos fajroŝirmilon, kaj poste bezonas tagon por rekonstrui.

Ne kaptu la propran tunelon de la kluzo en la politiko

La reguloj, kiujn vi skribas por klientoj, validas ankaŭ por trafiko, kiun la kluzo generas, se vi ne ekskludas ĝin. Larĝa regulo bazita sur marko aŭ sur la elira interfaco povas kapti la propran konekton de la kluzo al la partnero, kaj tiam la tunelo, kiu portas la politikon, estas itinerigata de la politiko. Tio produktas buklon aŭ interrompon, kiu aspektas kiel provizanta fuŝo.

Limigu ĉiun regulon tiom mallarĝe, kiom la dezajno permesas: fonta prefikso, enira interfaco kaj, kie subtenate, marko, kiun portas nur klientaj pakaĵoj. Poste testu la propran konekteblon de la kluzo post ĉiu regula ŝanĝo, ĉar la fuŝo estas memreferenca kaj ne aperas en klienta testo.

La manlibra paĝo de ip-rule dokumentas la semantikon de la selektilo kaj de la prioritato. Kombinu ĝin kun serĉa testo por ĉiu baseno kaj la dezajno fariĝas kontrolebla, kio estas la diferenco inter politika itinerigado, kiu eltenas jaron, kaj tiu, kiun ĉiuj timas tuŝi.