Waarom een bronpoortregel een van je SSH-paden breekt

Twee beheeringangen op één host, één servicepoort en een beleidsregel die beide moest helpen. De regel komt overeen met bronpoort 22, stuurt de opzoeking naar een tabel die alleen de WAN-standaard kent, en de VPN-ingang stopt met antwoorden op nieuwe aanmeldingen terwijl de directe ingang blijft werken. Niets daarvan is mysterieus zodra de selector goed wordt gelezen. Een bronpoort identificeert een dienst, niet het pad waarlangs een verbinding binnenkwam.

Twee ingangen, één servicepoort

De host heeft een adres aan de LAN-kant en een VPN-adres, en sshd luistert op beide. Een directe sessie en een tunnelsessie delen daarom de servicepoort en verschillen alleen in welk lokaal adres de verbinding ontvangt.

Dat verschil is genoeg om een antwoordpad te kiezen, en het is precies het verschil dat een poortgebaseerde regel weggooit. Beide sessies produceren antwoorden waarvan de bronpoort 22 is, dus een regel die op die poort past, kan ze niet scheiden. Hij stuurt beide opzoekingen naar dezelfde tabel, en een van beide krijgt een antwoord dat niet past. De oplossing is het attribuut te matchen dat werkelijk verschilt.

Elke ingang zijn eigen poort geven zou ook werken, en dat als eis behandelen is een ontwerpkeuze, geen eigenschap van SSH.

Lees de regel, dan de tabel

Een beleidsregel is een geordende selector, en de eerste die een bruikbaar antwoord teruggeeft, beëindigt de opzoeking. Lees de lijst in volgorde en let op welke regel kan winnen.

Lees dan de tabel waarnaar die regel wijst, want een regel die met succes wordt opgelost, is geen regel die nuttig wordt opgelost. Een tabel met alleen een standaardroute stuurt het antwoord van VPN-oorsprong via de WAN-interface naar buiten. Een specifiekere route in een latere tabel wordt nooit geraadpleegd, en daarom verandert het toevoegen van een tweede tabel zo vaak niets. De gekozen tabel is wat moet worden onderzocht.

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

Die twee uitvoer samen verklaren het resultaat; elk afzonderlijk nodigt uit tot een verkeerde conclusie.

Beperk de regel tot de stroom die je bedoelt

Het attribuut dat de twee ingangen scheidt, is het lokale bronadres. Een regel die op dat adres past, stuurt alleen de tunnelsessies naar de privétabel en laat directe sessies op de hoofdtabel.

Die regel moet worden gecombineerd met een tabel die de privéroute en de terugweg voor dat subnet bevat. Beperk beide tot beheerverkeer in plaats van elke dienst op de host. Een regel die al het verkeer van dat adres vangt, zal ook al het andere omleiden dat de host van daaruit stuurt. Smal verslaat hier slim, omdat de volgende persoon het moet lezen.

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

Als beide ingangen naar één lokaal adres worden vertaald, verdwijnt dat onderscheid en heeft het ontwerp in plaats daarvan verbindingsbewuste toestand nodig.

Houd luisteraar, toestemming en antwoordkeuze gescheiden

Drie afzonderlijke dingen moeten waar zijn voordat een sessie werkt: het adres bestaat, de dienst luistert erop, en het antwoord vindt de terugweg. Een routewijziging verhelpt alleen het derde.

De luisteraarsconfiguratie is een eigen bestand en een eigen herlaadactie, en meerdere luisteradressen zijn normaal. Authenticatie is opnieuw een derde beslissing, en een routeringsuitzondering geeft niemand toegang. Houd host-sleutelverificatie, accountauthenticatie en bronbeperkingen op beide ingangen, en weersta de neiging de andere controles van de tunnel te verzwakken zodat één beheerpad werkt.

Houd een herstelkanaal dat niet afhangt van het pad dat je wijzigt, want een fout hier sluit de fix zelf buiten.

Bewijs het met een nieuwe sessie, niet een oude

Een gevestigde terminal bewijst niets, want die werd vóór de wijziging toegelaten. Open een verse sessie via elke bedoelde ingang.

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

Herhaal daarna de VPN-herverbinding en probeer opnieuw, want een route die een herverbinding overleeft is niet hetzelfde als een die is toegevoegd aan een tabel die de herverbinding leegt. Observeer de geweigerde bronnen apart van de toegestane, zodat een geblokkeerde poging zich niet achter een werkende sessie verstopt. Bewaar het lokale adres, de regel en de tabel naast het resultaat. Als je in plaats daarvan de poorten splitst, noteer dat als een operationele beslissing en niet als een beperking van SSH.