Proč vaše veřejná služba Linuxu odpovídá přes VPN

Nic v socketu si nepamatuje, které rozhraní přineslo požadavek, takže výchozí trasa VPN s plným tunelem může zachytit odpověď, která patří do WAN. Služba příchozí rozhraní neignoruje; Linux směruje místně vytvořenou odpověď podle cíle a zásady zdroje. Pravidlo založené na zdroji může místo toho poslat jen odpovědi služby přes úplnou tabulku WAN a nechat běžný odchod v tunelu. Port zůstává otevřený, zatímco odpověď odchází špatnou cestou, a proto se příznak jeví jednostranně.

Mylná představa: odpovědi následují rozhraní, kterým přišly

Zdá se logické, že paket, který dorazí na eth0, má odejít na eth0. Bezstavové paketové filtry lze tak napsat a tcpdump na vstupní straně ukazuje požadavek přesně tam, kde se očekává. Směrování tak nefunguje pro provoz, který vytváří sám hostitel.

Jakmile služba připojení přijme, její odpověď je nový místně vytvořený paket. Jádro konzultuje pravidla směrování pro cíl a zdroj odpovědi a výchozí trasa VPN je zcela platná odpověď. Nic v socketu si nepamatuje, které rozhraní požadavek přineslo.

Proto se příznak jeví jednostranně: požadavky přicházejí, odpovědi mizí. Proto také přidání pravidla firewallu pro vstupní port nic nezmění. Paket není blokován na cestě dovnitř; je směrován jinam na cestě ven. Sledujte odpověď vyhledáním kvalifikovaným zdrojem a objížďka se ukáže.

Co jádro skutečně směruje: zdrojová adresa

Úchyt, který potřebujete, je místní adresa, kterou služba používá pro odpovědi. Na hostiteli s ilustrativní adresou eth0 192.0.2.10/24 a bránou 192.0.2.1 je tato adresa na rozhraní přítomná. Na cloudové VM může být veřejná adresa přeložena výše a v hostovi chybět, proto použijte adresu, kterou hostitel skutečně má.

Prohlédněte si současný stav, než rezervujete číslo tabulky nebo prioritu pravidla. Existující zásady mohou nové pravidlo zastínit a stará tabulka se stejným číslem už může nést nesouvisející trasy:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Poté vyberte tabulku podle zdroje. Pravidlo odpovídá odpovědím, které už nesou 192.0.2.10, tedy přesně místně ukončenému provozu, který chcete vyjmout. Předávaný provoz a pakety z jiných místních adres neodpovídají.

Postavte úplnou návratovou tabulku, ne polovinu výchozí trasy

Tabulka jen s výchozí trasou nestačí. Jádro stále musí vyřešit bránu a toto řešení potřebuje připojený prefix ve stejné tabulce. Tabulka, které tento prefix chybí, selže při řešení brány, i když její výchozí trasa vypadá správně. Přidejte obojí a poté namiřte pravidlo zdroje na tabulku:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Použijte skutečný prefix a bránu místo kopírování příkladu. Cloudové rozhraní nakonfigurované jako /32 s bránou na odkazu potřebuje jinou připojenou trasu a tabulka postavená ze špatného prefixu selže na prvním skoku. Atribut src uvádí preferovaný zdroj pro tuto trasu; nenahrazuje pravidlo zdroje.

Záleží i na pořadí. Široké pravidlo s nižším číslem priority se vyhodnocuje první, takže k pravidlu zdroje se musí dojít dřív než k jakémukoli pravidlu, které by tento provoz poslalo zpět do hlavní tabulky. Zkontrolujte priority pomocí ip rule show po přidání, ne jen při startu.

Ověřte vyhledáním kvalifikovaným zdrojem

Požádejte jádro, aby směrovalo testovací cíl z adresy služby. Odpověď by měla jmenovat eth0 a bránu WAN, ne tunel:

ip -4 route get 198.51.100.25 from 192.0.2.10

Poté vytvořte nové autorizované připojení a sledujte oba směry. Vyhledání, které vybere správnou tabulku, zatímco živé připojení stále selhává, ukazuje na filtrování reverzní cesty nebo pravidlo firewallu, ne na tabulku. Zkontrolujte tyto kontroly, než cokoli globálně vypnete.

Umístěte konečné trasy a pravidlo pod správce sítě, kterému rozhraní patří. Změny adres, obnovení DHCP a opětovná připojení VPN přepisují stav jádra a pravidlo přidané ručně zmizí nebo ukazuje na zastaralou bránu po další události.

Kde tato výjimka končí

Pravidlo vyjímá místně ukončený provoz z jedné zdrojové adresy. Nepokrývá porty publikované Dockerem, DNAT ani služby předávané přes hostitele, protože tyto pakety se směrují jako předávaný provoz a nikdy nenesou místní zdroj hostitele stejným způsobem. Takové návrhy obvykle potřebují značku nastavenou na vstupu a pravidlo, které značce odpovídá.

Také nezpůsobí, že se veřejná adresa hostitele objeví na rozhraní. Když tuto adresu vlastní NAT výše, odpověď stále musí odejít cestou, kterou tento NAT očekává, a proto musí tabulka WAN zrcadlit původní bránu a prefix, ne odhadovaný veřejný rozsah.

Uchovávejte výjimku zdokumentovanou s číslem tabulky, prioritou pravidla a přesnou zdrojovou adresou. Další změna VPN nebo rozhraní ji může tiše rozbít a poznámka, která tři hodnoty pojmenuje, se kontroluje rychleji než znovuobjevení příznaku ze zprávy zákazníka.

Pokud služba stále odpovídá špatnou cestou poté, co vyhledání kvalifikované zdrojem projde, porovnejte zdrojovou adresu živého socketu s adresou v pravidle. Služba vázaná na zástupnou adresu může zvolit jiný zdroj než testovanou adresu, a tento nesoulad je zbývající mezera.