Proč pravidlo zdrojového portu rozbíjí jednu z vašich SSH cest

Dva řídicí vstupy na jednom hostiteli, jeden služební port a pravidlo zásad, které mělo pomoci oběma. Pravidlo odpovídá zdrojovému portu 22, posílá vyhledávání do tabulky, která zná jen výchozí hodnotu WAN, a VPN vstup přestane odpovídat na nová přihlášení, zatímco přímý vstup funguje dál. Nic z toho není záhadné, jakmile se selektor přečte správně. Zdrojový port určuje službu, ne cestu, po které spojení přišlo.

Dva vstupy, jeden služební port

Hostitel má adresu na straně LAN a adresu VPN a sshd naslouchá na obou. Přímá relace a tunelovaná relace proto sdílejí služební port a liší se jen tím, která místní adresa spojení přijme.

Tento rozdíl stačí k výběru cesty odpovědi a je to přesně rozdíl, který pravidlo založené na portu zahazuje. Obě relace vytvářejí odpovědi se zdrojovým portem 22, takže pravidlo odpovídající tomuto portu je nemůže oddělit. Posílá obě vyhledávání do stejné tabulky a jedno z nich dostane odpověď, která nesedí. Oprava spočívá ve shodě s atributem, který se skutečně liší.

Dát každému vstupu vlastní port by také fungovalo, a považovat to za požadavek je designová volba, nikoli vlastnost SSH.

Přečtěte pravidlo, pak tabulku

Pravidlo zásad je uspořádaný selektor a první, které vrátí použitelnou odpověď, ukončí vyhledávání. Přečtěte seznam popořadě a všimněte si, které pravidlo může vyhrát.

Pak přečtěte tabulku, na kterou to pravidlo ukazuje, protože pravidlo, které se úspěšně vyřeší, není pravidlo, které se vyřeší užitečně. Tabulka obsahující jen výchozí trasu pošle odpověď s původem VPN přes rozhraní WAN. Konkrétnější trasa v pozdější tabulce se nikdy nekonzultuje, a proto přidání druhé tabulky tak často nic nezmění. Vybraná tabulka je to, co je třeba prozkoumat.

ip -4 rule show
ip route show table 100
ip route show table main

Tyto dva výstupy dohromady vysvětlují výsledek; každý sám o sobě vybízí k chybnému závěru.

Omezte pravidlo na tok, který máte na mysli

Atribut, který oba vstupy odděluje, je místní zdrojová adresa. Pravidlo odpovídající této adrese posílá do soukromé tabulky jen tunelované relace a přímé relace ponechává v hlavní tabulce.

Toto pravidlo musí být spárováno s tabulkou obsahující soukromou trasu a zpětnou cestu pro tuto podsíť. Omezte obojí na řídicí provoz, nikoli na každou službu na hostiteli. Pravidlo, které zachytí veškerý provoz z této adresy, přesměruje i všechno ostatní, co hostitel odtud pošle. Úzké zde vítězí nad chytrým, protože to musí přečíst další člověk.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

Pokud se oba vstupy přeloží na jednu místní adresu, tento rozdíl zmizí a design místo toho potřebuje stav, který zná spojení.

Držte posluchač, oprávnění a výběr odpovědi odděleně

Než relace začne fungovat, musí platit tři oddělené věci: adresa existuje, služba na ní naslouchá a odpověď najde cestu zpět. Změna trasy opraví jen třetí.

Konfigurace posluchače je její vlastní soubor a její vlastní opětovné načtení, a více adres pro naslouchání je normální. Ověřování je znovu třetí rozhodnutí a výjimka ve směrování nikomu nepřidělí přístup. Držte ověření klíče hostitele, ověřování účtu a omezení zdrojů na obou vstupech a odolejte nutkání oslabit ostatní kontroly tunelu, aby jeden řídicí tok fungoval.

Držte záchranný kanál, který nezávisí na cestě, kterou měníte, protože chyba tady zablokuje i samotnou opravu.

Dokažte to novou relací, ne starou

Zavedený terminál nic nedokazuje, protože byl přijat před změnou. Otevřete čerstvou relaci přes každý zamýšlený vstup.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Pak zopakujte opětovné připojení VPN a zkuste to znovu, protože trasa, která přežije opětovné připojení, není totéž jako trasa přidaná do tabulky, kterou opětovné připojení vyčistí. Sledujte odmítnuté zdroje odděleně od povolených, aby se zablokovaný pokus neskryl za fungující relací. Uložte místní adresu, pravidlo a tabulku vedle výsledku. Pokud místo toho rozdělíte porty, zaznamenejte to jako provozní rozhodnutí, nikoli jako omezení SSH.