Eniru nur pordon 25 en la tunelon, ne la gastiganton

Kvar aferoj devas kongrui antaŭ ol Linux-gastiganto sendas nur sian propran SMTP tra tunelo: itinero en dediĉita tabelo, politika regulo kiu elektas la trafikon, fonta adreso kiun la peer akceptos, kaj revena vojo kiu eltenas la malsimetrion. Ĉiu estas aparta agordo kun sia propra fiaska maniero. La ordo sube estas tiu, kiu igas fiaskon montri al la parto kiu efektive malĝustas. Ĝi estas pordospecifa itiniga tasko, ne peto pri defaŭlta VPN-itinero.

Porda regulo ne estas defaŭlta itinero

Regulo kiu kongruigas loke generitan TCP kun cella pordo 25 sendas tiun trafikon al tabelo kiun vi nomas. La regulo mem kreas nenion: ĝi elektas, kaj la tabelo devas teni itinero kiu povas porti la paketon. Kombini la du kovras nur la eliran direkton de unu protokolo, do plusendo por aliaj gastigantoj, alvenantaj poŝtaj konektoj kaj IPv6 restas ekster la aranĝo. Nomante ĝin pordospecifa politiko anstataŭ VPN-defaŭlto konservas tiun limon honesta.

Du agordoj de wg-quick estas antaŭkondiĉoj, ne parto de la politiko. AllowedIPs = 0.0.0.0/0 permesas al la peer porti arbitrajn IPv4-celojn, kaj Table = off malhelpas al wg-quick instali sian propran defaŭltan itinero por tiu prefikso. Ne miksu ĉi tiujn instrukciojn kun administrilo kiu aplikas sian propran itinpolitikon, ĉar la du malkonsentos pri kiu posedas la ĉefan tabelon.

Skribu la itinero, la selektilo kaj la gardo

Elektu tabelnumeron kaj paron da prioritatoj kiujn nenio alia uzas, poste apliku la itinero, la selektilo kaj la gardo en tiu ordo. La nombroj sube estas ekzemploj, ne rezervitaj valoroj:

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo limigas la regulon al loke originita trafiko, kaj ipproto tcp dport 25 identigas la direkton de la konekto; la referenco pri ip-rule dokumentas ambaŭ selektilojn. Ili ekzistas en nunaj kernoj kaj iproute2-eldonoj, kaj sur pli malnova sistemo la regulo estas tute malakceptita, kio estas pli klara fiasko ol regulo kiu ŝarĝiĝas kaj kongruas kun nenio.

La regulo unreachable ĉe la sekva prioritato estas la gardo. Sen ĝi, mankanta itinero en tabelo 51825 falas al la ordinara defaŭlto, kaj poŝto eliras tra la fizika ligo dum tunela paneo, kio estas ĝuste la kazo kiun la politiko estis konstruita por malhelpi.

La fonta adreso devas kongrui

La src-prefero de la itinero nur plenigas fonton por konektoj kiuj ne ligis sian propran. Ĝi ne estas traduko, kaj ĝi ne superregas eksplicitan ligon, do demono ligita al la fizika adreso daŭre sendas de tiu adreso. Se tio estas kion vi trovas, ŝanĝu la propran agordon de la demono aŭ desegnu intencan tradukan politikon, ĉar malfrua ĝenerala masquerade estas alia solvo kun aliaj sekvoj.

Ĉe la enirejo, la peer de la kliento devas rajtigi la fonton kiun ĝi efektive ricevas, nome 10.77.0.2/32 anstataŭ vasta cella prefikso. Kopii la 0.0.0.0/0 de la kliento en ĉiun enirejan peer konfuzas kiu peer posedas kiun trafikon. La enirejo ankaŭ bezonas plusendadon, fajroŝirma politiko kiu permesas la fluon, kaj revenan vojon, inkluzive eliran tradukon kiam la supraĵo ne povas itinigi privatan tunelan adreson.

Kontrolu la revenan vojon, poste la persistecon

Legu la serĉojn antaŭ ol fidi ion ajn, ĉar ili montras kiun tabelon kaj kiun fonton ĉiu direkto ricevas. Unu celo ĉe pordo 25 kaj la sama celo ĉe pordo 443 sufiĉas:

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

La unua serĉo devus nomi wg0 kaj la celatan fonton, kaj la dua devus konservi la ordinaran suprenligon. Kiam la aplikaĵo ligas sian propran adreson, aldonu from kun tiu adreso al la serĉo. Responda direkto kiu atingas wg0 kaj poste estas loke forĵetita montras al IPv4 inversa-voja filtrado, ĉar regulo nur por elira pordo ne igas la inversan serĉon elekti la tunelon.

Kie malsimetria itinigo estas rajtigita, interfac-limigita malstrikta reĝimo per net.ipv4.conf.wg0.rp_filter=2 povas esti taŭga, kaj indas unue kontroli la efektivan maksimumon de la valoroj all kaj de la interfaco. Ne malŝaltu validigon tutmonde kiel fuĝvojon. Poste transdonu la tabelon, la prioritatojn kaj la gardon al tio, kio posedas la agordon, kaj malfermu novajn konektojn post rekonekto por konfirmi ke la elekto ankoraŭ teniĝas. Memoru ke respondoj de loka SMTP-aŭskultanto portas fontan pordon 25 anstataŭ cellan pordon 25, kio estas aparta politika demando.