Stjoer allinnich poarte 25 yn de tunnel, net de host
In poartspesifike regel stjoert allinnich útgeand SMTP troch de tunnel. De tabel, it boarneadres en de weromreis moatte elk oerienkomme, oars wurket neat.
Fjouwer dingen moatte op ien line stean foardat in Linux-host allinnich syn eigen SMTP troch in tunnel stjoert: in rûte yn in eigen tabel, in beliedsregel dy't it ferkear kiest, in boarneadres dat de peer akseptearret, en in weromreis dy't de asymmetry oerlibbet. Elk is in aparte konfiguraasje mei syn eigen falmodus. De folchoarder hjirûnder is dejinge dy't in fal nei it stik wiist dat echt ferkeard is. It is in poartspesifike routingtaak, gjin fersyk om in standertrûte fan VPN.
In poartregel is gjin standertrûte
In regel dy't lokaal makke TCP mei de bestimmingspoarte 25 oerienkomt, stjoert dat ferkear nei in tabel dy't jo neame. De regel makket sels neat: hy kiest, en de tabel moat in rûte hawwe dy't it pakket drage kin. De kombinaasje fan beide dekt allinnich de útgong fan ien protokol, dus trochstjoeren foar oare hosts, ynkommende postferbiningen en IPv6 bliuwe bûten de regeling. It in poartspesifyk belied neame ynstee fan in VPN-standert hâldt dy grins earlik.
Twa wg-quick-ynstellingen binne betingsten, gjin part fan it belied. AllowedIPs = 0.0.0.0/0 lit de peer willekeurige IPv4-bestimmings drage, en Table = off stopet wg-quick om syn eigen standertrûte foar dat foarheaksel te ynstallearjen. Ming dizze ynstruksjes net mei in behearder dy't syn eigen rûtebelied tapast, want de twa sille it net iens wêze oer wa't de haadtabel besit.
Skriuw de rûte, de kiesder en de wacht
Kies in tabelnûmer en in pear prioriteiten dy't neat oars brûkt, en pas dan de rûte, de kiesder en de wacht yn dy folchoarder ta. De nûmers hjirûnder binne foarbylden, gjin reservearre wearden:
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 unreachableiif lo beheint de regel ta ferkear fan lokale oarsprong, en ipproto tcp dport 25 identifisearret de rjochting fan de ferbining; de ip-rule-referinsje dokumintearret beide kiesders. Se besteane yn aktuele kernels en iproute2-útjeften, en op in âlder systeem wurdt de regel folslein wegere, wat in dúdliker fal is as in regel dy't lade wurdt en neat treft.
De unreachable-regel op de folgjende prioriteit is de wacht. Sûnder dy falt in ûntbrekkende rûte yn tabel 51825 troch nei de gewoane standert, en post ferlit de fysike keppeling by in tunnelûnderbrekking, wat krekt it gefal is dat it belied foarkomme moast.
It boarneadres moat oerienkomme
De src-foarkar fan 'e rûte folt allinnich in boarne foar ferbiningen dy't gjin eigen boarne bûn hawwe. It is gjin oersetting, en it oerskriuwt gjin eksplisite bining, dus in daemon bûn oan it fysike adres bliuwt fan dat adres stjoere. As dat is wat jo fine, feroarje dan de ynstelling fan 'e daemon sels of ûntwerp in bewust oersettingsbelied, want in let algemien masquerade is in oare oplossing mei oare gefolgen.
By de gateway moat de peer fan 'e klant de boarne autorisearje dy't er echt ûntfangt, dat is 10.77.0.2/32 ynstee fan in breed bestimmingsfoarheaksel. It 0.0.0.0/0 fan 'e klant yn elke gateway-peer kopiearje ferbjusteret wa't hokker ferkear besit. De gateway hat ek trochstjoeren, in firewallbelied dat de stream tastiet, en in weromreis nedich, ynklusyf útgongsoersetting as de upstream in privee tunneladres net routearje kin.
Kontrolearje de weromreis, dan de persistinsje
Lês de opsochten foardat jo op eat fertrouwe, want se litte sjen hokker tabel en hokker boarne elke rjochting krijt. Ien bestimmingsadres op poarte 25 en itselde bestimming op poarte 443 binne genôch:
ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443De earste opsocht soe wg0 en de bedoelde boarne neame moatte, en de twadde soe de gewoane uplink hâlde moatte. As de applikaasje syn eigen adres bûn hat, foegje from mei dat adres ta oan 'e opsocht. In antwurd-rjochting dy't wg0 berikt en dan lokaal fuortsmiten wurdt, wiist op IPv4 reverse-path-filtering, want in regel allinnich foar útgongspoarte makket net dat de omkearde opsocht de tunnel kiest.
Dêr't asymmetryske routing tastien is, kin in interfaceskoppe losse modus fia net.ipv4.conf.wg0.rp_filter=2 passend wêze, en it is de muoite om earst it effektive maksimum fan 'e all- en interfacewearden te kontrolearjen. Skeakelje falidaasje net globaal út as in koartsluting. Jou dan de tabel, de prioriteiten en de wacht oan wa't de konfiguraasje besit, en iepenje nije ferbiningen nei in werferbining om te befêstigjen dat de seleksje noch hâldt. Tink derom dat antwurden fan in lokale SMTP-harker boarne-poarte 25 drage ynstee fan bestimmingspoarte 25, wat in aparte beliedsfraach is.