Csak a 25-es portot irányítsa az alagútba, ne a gazdagépet

Négy dolognak kell összhangban lennie, mielőtt egy Linux-gazdagép csak a saját SMTP-jét küldi ki egy alagúton: egy útvonal egy dedikált táblában, a forgalmat kiválasztó házirend-szabály, egy forrás-cím, amelyet a peer elfogad, és egy visszaút, amely kibírja az aszimmetriát. Mindegyik külön konfiguráció a saját hibaüzemmódjával. Az alábbi sorrend az, amely a hibát arra a részre mutatja, amely valóban rossz. Ez portra jellemző útválasztási feladat, nem VPN-alapértelmezett útvonal iránti kérés.

A portszabály nem alapértelmezett útvonal

Egy szabály, amely a helyben létrehozott TCP-t a 25 célporthoz illeszti, a forgalmat egy általad megnevezett táblába küldi. A szabály önmagában semmit nem hoz létre: kiválaszt, és a táblának tartalmaznia kell egy útvonalat, amely el tudja vinni a csomagot. A kettő együtt csak egy protokoll kimenő irányát fedi le, ezért a más gazdagépek felé történő továbbítás, a bejövő levélkapcsolatok és az IPv6 ezen elrendezésen kívül maradnak. Portra jellemző házirendnek nevezni VPN-alapértelmezés helyett becsületben tartja ezt a határt.

Két wg-quick-beállítás előfeltétel, nem a házirend része. Az AllowedIPs = 0.0.0.0/0 engedi, hogy a peer tetszőleges IPv4-célokat vigyen, a Table = off pedig megakadályozza, hogy a wg-quick saját alapértelmezett útvonalat telepítsen ehhez az előtaghoz. Ne keverje ezeket az utasításokat olyan kezelővel, amely saját útvonal-házirendet alkalmaz, mert a kettő nem fog egyetérteni abban, ki birtokolja a fő táblát.

Írja meg az útvonalat, a választót és az őrt

Válasszon olyan táblaszámot és prioritáspárt, amelyet semmi más nem használ, majd alkalmazza az útvonalat, a választót és az őrt ebben a sorrendben. Az alábbi számok példák, nem fenntartott értékek:

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

Az iif lo a helyi eredetű forgalomra korlátozza a szabályt, az ipproto tcp dport 25 pedig azonosítja a kapcsolat irányát; az ip-rule-referencia mindkét választót dokumentálja. Léteznek a jelenlegi kernelekben és iproute2-kiadásokban, és régebbi rendszeren a szabályt egyenesen elutasítják, ami világosabb hiba, mint egy betöltődő szabály, amely semmivel nem egyezik.

A következő prioritáson lévő unreachable szabály az őr. Nélküle a 51825 táblából hiányzó útvonal a szokásos alapértelmezésbe esik, és az alagút kiesésekor a levél a fizikai kapcsolaton hagyja el a gépet, ami pontosan az az eset, amelynek megakadályozására a házirend készült.

A forrás-címnek egyeznie kell

Az útvonal src preferenciája csak azoknak a kapcsolatoknak tölt ki forrást, amelyek nem kötöttek sajátot. Ez nem fordítás, és nem írja felül a kifejezett kötést, ezért a fizikai címhez kötött démon továbbra is arról a címről küld. Ha pontosan ezt tapasztalja, változtassa meg a démon saját beállítását, vagy tervezzen szándékos fordítási házirendet, mert a késői átfogó masquerade más megoldás más következményekkel.

Az átjárón a kliens peerjének engedélyeznie kell a forrást, amelyet ténylegesen fogad, azaz a 10.77.0.2/32-t, nem egy széles cél-előtagot. A kliens 0.0.0.0/0-jának minden átjáró-peerbe másolása összekeveri, melyik peer melyik forgalmat birtokolja. Az átjárónak továbbításra, a folyamot engedélyező tűzfal-házirendre és visszaútra is szüksége van, beleértve a kimenő fordítást, amikor a felső szakasz nem tud útvonalazni egy privát alagútcímet.

Ellenőrizze a visszautat, majd a tartósságot

Olvassa el a kereséseket, mielőtt bármiben megbízna, mert megmutatják, melyik táblát és melyik forrást kapja az egyes irány. Egy cél a 25-es porton és ugyanaz a cél a 443-as porton elegendő:

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

Az első keresésnek meg kell neveznie a wg0-t és a szándékolt forrást, a másodiknak meg kell tartania a szokásos felső kapcsolatot. Amikor az alkalmazás a saját címét köti, adja hozzá a from-ot azzal a címmel a kereséshez. Az a válaszirány, amely eléri a wg0-t, majd helyben eldobódik, az IPv4 fordított útvonal szűrésére utal, mert a csak kimenő portra vonatkozó szabály nem készteti a fordított keresést az alagút választására.

Ahol az aszimmetrikus útválasztás engedélyezett, az interfészre korlátozott laza mód a net.ipv4.conf.wg0.rp_filter=2 révén megfelelő lehet, és érdemes először ellenőrizni az all és az interfész értékeinek tényleges maximumát. Ne kapcsolja ki az ellenőrzést globálisan rövidítésként. Ezután adja át a táblát, a prioritásokat és az őrt annak, aki a konfigurációt birtokolja, és újracsatlakozás után nyisson friss kapcsolatokat, hogy megerősítse, a kiválasztás továbbra is tart. Ne feledje, hogy a helyi SMTP-figyelő válaszai forrásportként 25-öt hordoznak, nem célportként 25-öt, ami külön házirend-kérdés.