Kvifor ei kjeldeportregel øydelegg ein av SSH-veggane dine

To administrasjonsinngangar på éin vert, éin tenesteport og ein policyregel som skulle hjelpe begge. Regelen matchar kjeldeport 22, sender oppslaget til ein tabell som berre kjenner WAN-standarden, og VPN-inngangen sluttar å svare på nye innloggingar medan den direkte inngangen held fram å virke. Ingenting av dette er mystisk når veljaren blir lesen rett. Ein kjeldeport identifiserer ei teneste, ikkje vegen ein tilkopling kom inn på.

To inngangar, éin tenesteport

Verten har ei adresse på LAN-sida og ei VPN-adresse, og sshd lyttar på begge. Ei direkte økt og ei tunneløkt deler difor tenesteporten og skil seg berre i kva lokal adresse som tek imot tilkoplinga.

Denne skilnaden er nok til å velje ein svarveg, og det er nøyaktig skilnaden ein portbasert regel kastar bort. Begge øktene produserer svar der kjeldeporten er 22, så ein regel som matchar den porten, kan ikkje skilje dei. Han sender begge oppslaga til same tabell, og eitt av dei får eit svar som ikkje passar. Rettelsen er å matche attributtet som faktisk skil seg.

Å gje kvar inngang sin eigen port ville òg fungere, og å handsame det som eit krav er eit designval, ikkje ein eigenskap ved SSH.

Les regelen, deretter tabellen

Ein policyregel er ein ordna veljar, og den første som returnerer eit brukbart svar, avsluttar oppslaget. Les lista i rekkjefølgje og legg merke til kva regel som kan vinne.

Les deretter tabellen regelen peikar på, fordi ein regel som blir løyst med suksess, ikkje er ein regel som blir løyst nyttig. Ein tabell med berre ei standardrute sender svaret med VPN-opphav ut gjennom WAN-grensesnittet. Ei meir spesifikk rute i ein seinare tabell blir aldri konsultert, og difor endrar det så ofte ingenting å leggje til ein andre tabell. Den valde tabellen er det som må undersøkjast.

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

Dei to utdata forklarer saman resultatet; kvar for seg innbyr dei til ein feil konklusjon.

Avgrens regelen til flyten du meiner

Attributtet som skil dei to inngangane, er den lokale kjeldeadressa. Ein regel som matchar den adressa, sender berre tunneløktene til den private tabellen og lèt direkte økter bli på hovudtabellen.

Den regelen må parast med ein tabell som inneheld den private ruta og returvegen for det subnettet. Avgrens begge til administrasjonstrafikk i staden for kvar teneste på verten. Ein regel som fangar all trafikk frå den adressa, vil òg omdirigere alt anna verten sender derifrå. Smalt slår smart her, fordi neste person må lese det.

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

Viss begge inngangane blir omsette til éi lokal adresse, forsvinn den skilnaden, og designet treng tilkoplingsmedviten tilstand i staden.

Hald lyttar, løyve og svarval åtskilde

Tre separate ting må vere sanne før ei økt virkar: adressa finst, tenesta lyttar på henne, og svaret finn vegen tilbake. Ei ruteendring rettar berre det tredje.

Lyttarkonfigurasjonen er si eiga fil og si eiga omlasting, og fleire lyttadresser er normale. Autentisering er igjen eit tredje vedtak, og eit rutingsunntak gjev ingen tilgang. Hald vertsnøkkelverifisering, kontoautentisering og kjeldeavgrensingar på begge inngangane, og motstå freistinga til å svekkje dei andre kontrollane til tunnelen slik at éin administrasjonsveg virkar.

Hald ein gjenopprettingskanal som ikkje avheng av vegen du endrar, fordi ein feil her låser sjølve rettelsen ute.

Prov det med ei ny økt, ikkje ei gammal

Ein etablert terminal provar ingenting, sidan han slapp inn før endringa. Opne ei frisk økt gjennom kvar tiltenkt inngang.

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

Gjenta deretter VPN-gjenoppkoplinga og prøv igjen, fordi ei rute som overlever ei gjenoppkopling, ikkje er det same som éi lagd til i ein tabell som gjenoppkoplinga tømmer. Observer dei avviste kjeldene åtskilde frå dei tillatne, slik at eit blokkert forsøk ikkje gøymer seg bak ei fungerande økt. Lagre den lokale adressa, regelen og tabellen ved sida av resultatet. Viss du i staden deler portane, registrer det som eit driftsvedtak og ikkje som ei avgrensing i SSH.