De ce o regulă de port sursă rupe una dintre căile tale SSH

Două intrări de administrare pe un singur host, un singur port de serviciu și o regulă de politică menită să ajute ambele. Regula se potrivește cu portul sursă 22, trimite căutarea către un tabel care cunoaște doar valoarea implicită WAN, iar intrarea VPN încetează să răspundă la autentificări noi în timp ce intrarea directă continuă să funcționeze. Nimic din toate acestea nu este misterios odată ce selectorul este citit corect. Un port sursă identifică un serviciu, nu calea pe care a sosit o conexiune.

Două intrări, un singur port de serviciu

Hostul are o adresă pe partea LAN și o adresă VPN, iar sshd ascultă pe ambele. Prin urmare, o sesiune directă și o sesiune tunel partajează portul de serviciu și diferă doar prin adresa locală care primește conexiunea.

Această diferență este suficientă pentru a alege o cale de răspuns și este exact diferența pe care o regulă bazată pe port o aruncă. Ambele sesiuni produc răspunsuri al căror port sursă este 22, așa că o regulă care se potrivește cu acel port nu le poate separa. Trimite ambele căutări către același tabel, iar una dintre ele primește un răspuns care nu se potrivește. Corecția este să se potrivească atributul care chiar diferă.

A da fiecărei intrări propriul port ar funcționa și ea, iar tratarea acestui lucru ca cerință este o alegere de proiectare, nu o proprietate a SSH.

Citește regula, apoi tabelul

O regulă de politică este un selector ordonat, iar prima care returnează un răspuns utilizabil încheie căutarea. Citește lista în ordine și observă care regulă poate câștiga.

Apoi citește tabelul către care indică regula, deoarece o regulă care se rezolvă cu succes nu este o regulă care se rezolvă util. Un tabel care conține doar o rută implicită trimite răspunsul de origine VPN afară prin interfața WAN. O rută mai specifică într-un tabel ulterior nu este niciodată consultată, și de aceea adăugarea unui al doilea tabel atât de des nu schimbă nimic. Tabelul selectat este ceea ce trebuie inspectat.

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

Aceste două ieșiri împreună explică rezultatul; fiecare singură invită la o concluzie greșită.

Limitează regula la fluxul pe care îl ai în vedere

Atributul care separă cele două intrări este adresa sursă locală. O regulă care se potrivește cu acea adresă trimite doar sesiunile tunel către tabelul privat și lasă sesiunile directe pe tabelul principal.

Acea regulă trebuie împerecheată cu un tabel care conține ruta privată și calea de întoarcere pentru acea subrețea. Limitează ambele la traficul de administrare în loc de fiecare serviciu de pe host. O regulă care prinde tot traficul de la acea adresă va redirecționa și orice altceva trimite hostul de acolo. Îngustul învinge istețul aici, pentru că următoarea persoană trebuie să o citească.

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

Dacă ambele intrări sunt traduse pe o singură adresă locală, acea distincție dispare, iar proiectarea are nevoie în schimb de stare conștientă de conexiune.

Ține separate ascultătorul, permisiunea și selecția răspunsului

Trei lucruri separate trebuie să fie adevărate înainte ca o sesiune să funcționeze: adresa există, serviciul ascultă pe ea și răspunsul își găsește calea înapoi. O schimbare de rută repară doar al treilea.

Configurația ascultătorului este propriul fișier și propria reîncărcare, iar mai multe adrese de ascultare sunt normale. Autentificarea este din nou o a treia decizie, iar o excepție de rutare nu oferă acces nimănui. Păstrează verificarea cheii hostului, autentificarea contului și restricțiile de sursă pe ambele intrări și rezistă tentației de a slăbi celelalte controale ale tunelului pentru ca o singură cale de administrare să funcționeze.

Păstrează un canal de recuperare care nu depinde de calea pe care o schimbi, pentru că o greșeală aici blochează corecția însăși.

Demonstrează cu o sesiune nouă, nu cu una veche

Un terminal stabilit nu dovedește nimic, fiindcă a fost admis înainte de schimbare. Deschide o sesiune nouă prin fiecare intrare prevăzută.

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

Apoi repetă reconectarea VPN și încearcă din nou, pentru că o rută care supraviețuiește unei reconectări nu este la fel cu una adăugată într-un tabel pe care reconectarea îl golește. Observă sursele refuzate separat de cele permise, pentru ca o încercare blocată să nu se ascundă în spatele unei sesiuni funcționale. Salvează adresa locală, regula și tabelul lângă rezultat. Dacă împărți porturile în schimb, înregistrează asta ca decizie operațională și nu ca limită a SSH.