Ohjaa tunneliin vain portti 25, ei isäntää

Neljän asian on oltava linjassa ennen kuin Linux-isäntä lähettää vain oman SMTP:nsä tunnelin kautta: reitti omassa taulussa, liikenteen valitseva käytäntösääntö, lähdeosoite, jonka peer hyväksyy, ja paluupolku, joka kestää epäsymmetrian. Jokainen on erillinen kokoonpano omalla vikatilallaan. Alla oleva järjestys on se, joka saa vian osoittamaan osaan, joka todella on väärin. Kyse on porttikohtaisesta reititystehtävästä, ei VPN:n oletusreitin pyynnöstä.

Porttisääntö ei ole oletusreitti

Sääntö, joka sovittaa paikallisesti luodun TCP:n kohdeporttiin 25, lähettää liikenteen tauluun, jonka nimeät. Sääntö ei itsessään luo mitään: se valitsee, ja taulussa on oltava reitti, joka pystyy kuljettamaan paketin. Kahden yhdistelmä kattaa vain yhden protokollan lähtevän suunnan, joten edelleenlähetys muille isännille, saapuvat postiyhteydet ja IPv6 jäävät järjestelyn ulkopuolelle. Sen kutsuminen porttikohtaiseksi käytännöksi VPN:n oletuksen sijaan pitää rajan rehellisenä.

Kaksi wg-quick-asetusta ovat edellytyksiä, eivät osa käytäntöä. AllowedIPs = 0.0.0.0/0 sallii peerin kuljettaa mielivaltaisia IPv4-kohteita, ja Table = off estää wg-quickia asentamasta omaa oletusreittiään tuolle etuliitteelle. Älä sekoita näitä ohjeita hallintaan, joka soveltaa omaa reittikäytäntöään, sillä ne kaksi ovat eri mieltä siitä, kuka omistaa päätaulun.

Kirjoita reitti, valitsin ja vartija

Valitse taulun numero ja prioriteettipari, jota mikään muu ei käytä, ja sovella sitten reitti, valitsin ja vartija tässä järjestyksessä. Alla olevat numerot ovat esimerkkejä, eivät varattuja arvoja:

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 rajaa säännön paikallisesti syntyvään liikenteeseen, ja ipproto tcp dport 25 tunnistaa yhteyden suunnan; ip-rule-viite dokumentoi molemmat valitsimet. Ne ovat olemassa nykyisissä ytimissä ja iproute2-julkaisuissa, ja vanhemmassa järjestelmässä sääntö hylätään kokonaan, mikä on selvempi vika kuin sääntö, joka latautuu eikä vastaa mitään.

Seuraavan prioriteetin unreachable-sääntö on vartija. Ilman sitä taulusta 51825 puuttuva reitti putoaa tavalliseen oletukseen, ja posti lähtee fyysisen linkin kautta tunnelin katkoksen aikana, mikä on täsmälleen se tapaus, jonka estämiseksi käytäntö rakennettiin.

Lähdeosoitteen on sovittava

Reitin src-asetus täyttää lähteen vain yhteyksille, jotka eivät ole sitoneet omaansa. Se ei ole käännös eikä ohita nimenomaista sidontaa, joten fyysiseen osoitteeseen sidottu taustapalvelu lähettää edelleen siitä osoitteesta. Jos löydät juuri tämän, muuta taustapalvelun omaa asetusta tai suunnittele tarkoituksellinen käännöskäytäntö, sillä myöhäinen yleinen masquerade on toinen ratkaisu eri seurauksin.

Yhdyskäytävällä asiakkaan peerin on valtuutettava lähde, jonka se todella vastaanottaa, eli 10.77.0.2/32 eikä laaja kohde-etuliite. Asiakkaan 0.0.0.0/0:n kopioiminen jokaiseen yhdyskäytävän peeriin hämärtää, kuka omistaa mitä liikennettä. Yhdyskäytävä tarvitsee myös edelleenlähetyksen, liikenteen sallivan palomuurikäytännön ja paluupolun, mukaan lukien lähtevän käännöksen, kun ylävirta ei voi reitittää yksityistä tunneliosoitetta.

Tarkista paluupolku ja sitten pysyvyys

Lue haut ennen kuin luotat mihinkään, sillä ne näyttävät, minkä taulun ja minkä lähteen kukin suunta saa. Yksi kohde portissa 25 ja sama kohde portissa 443 riittävät:

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

Ensimmäisen haun pitäisi nimetä wg0 ja aiottu lähde, ja toisen pitäisi säilyttää tavallinen ylälinkki. Kun sovellus sitoo oman osoitteensa, lisää from kyseisellä osoitteella hakuun. Vastaussuunta, joka saavuttaa wg0:n ja pudotetaan sitten paikallisesti, viittaa IPv4:n käänteisen polun suodatukseen, sillä vain lähtevän portin sääntö ei saa käänteistä hakua valitsemaan tunnelia.

Kun epäsymmetrinen reititys on sallittu, käyttöliittymäkohtainen löyhä tila net.ipv4.conf.wg0.rp_filter=2:n kautta voi olla sopiva, ja kannattaa ensin tarkistaa all- ja käyttöliittymäarvojen tehollinen enimmäisarvo. Älä poista validointia käytöstä maailmanlaajuisesti oikotienä. Anna sitten taulu, prioriteetit ja vartija sille, joka omistaa kokoonpanon, ja avaa uudet yhteydet uudelleenyhdistämisen jälkeen varmistaaksesi, että valinta pitää edelleen. Muista, että paikallisen SMTP-kuuntelijan vastaukset kantavat lähdeporttia 25 eivätkä kohdeporttia 25, mikä on erillinen käytäntökysymys.