Zakaj pravilo izvornega vrat razbije eno od vaših poti SSH
Ujemanje »sport 22« ne pove, kateremu vhodu SSH pripada odgovor. Omejite pravilo politike na upravljalni tok namesto na eno tabelo samo za WAN.
Dva upravljalna vhoda na enem gostitelju, ena storitvena vrata in pravilo politike, ki naj bi pomagalo obema. Pravilo se ujema z izvornimi vrati 22, pošlje iskanje v tabelo, ki pozna samo privzeto vrednost WAN, in vhod VPN preneha odgovarjati na nove prijave, medtem ko neposredni vhod še naprej deluje. Nič od tega ni skrivnostno, ko je izbirnik pravilno prebran. Izvorna vrata označujejo storitev, ne poti, po kateri je prišla povezava.
Dva vhoda, ena storitvena vrata
Gostitelj ima naslov na strani LAN in naslov VPN, sshd pa posluša na obeh. Zato si neposredna seja in tunelska seja delita storitvena vrata in se razlikujeta le v tem, kateri lokalni naslov sprejme povezavo.
Ta razlika zadostuje za izbiro poti odgovora in je natanko tista razlika, ki jo pravilo, temelječe na vratih, zavrže. Obe seji ustvarjata odgovore, katerih izvorna vrata so 22, zato pravilo, ki se ujema s temi vrati, ju ne more ločiti. Pošlje obe iskanji v isto tabelo in eno od njiju prejme odgovor, ki se ne prilega. Popravek je ujemanje z atributom, ki se resnično razlikuje.
Dajanje lastnih vrat vsakemu vhodu bi prav tako delovalo, in obravnavati to kot zahtevo je oblikovalska izbira, ne lastnost SSH.
Preberite pravilo, nato tabelo
Pravilo politike je urejen izbirnik in prvo, ki vrne uporaben odgovor, konča iskanje. Preberite seznam po vrsti in opazite, katero pravilo lahko zmaga.
Nato preberite tabelo, na katero kaže to pravilo, ker pravilo, ki se uspešno razreši, ni pravilo, ki se razreši koristno. Tabela, ki vsebuje samo privzeto pot, pošlje odgovor s poreklom VPN ven skozi vmesnik WAN. Bolj specifična pot v poznejši tabeli se nikoli ne upošteva, in zato dodajanje druge tabele tako pogosto ne spremeni ničesar. Izbrana tabela je tisto, kar je treba pregledati.
ip -4 rule show
ip route show table 100
ip route show table main
Ta dva izhoda skupaj pojasnjujeta rezultat; vsak sam zase vabi k napačnemu sklepu.
Omejite pravilo na tok, ki ga imate v mislih
Atribut, ki ločuje vhoda, je lokalni izvorni naslov. Pravilo, ki se ujema s tem naslovom, pošlje le tunelske seje v zasebno tabelo, neposredne seje pa pusti v glavni tabeli.
To pravilo je treba seznaniti s tabelo, ki vsebuje zasebno pot in povratno pot za to podomrežje. Omejite obe na upravljalni promet namesto na vsako storitev na gostitelju. Pravilo, ki ujame ves promet s tega naslova, bo preusmerilo tudi vse drugo, kar gostitelj pošlje od tam. Ozko tu premaga pametno, ker mora naslednja oseba to prebrati.
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
Če se oba vhoda prevedeta na en lokalni naslov, ta razlika izgine in zasnova namesto tega potrebuje stanje, ki se zaveda povezave.
Ohranite poslušalca, dovoljenje in izbiro odgovora ločene
Preden seja deluje, morajo veljati tri ločene stvari: naslov obstaja, storitev posluša na njem in odgovor najde pot nazaj. Sprememba poti popravi le tretjo.
Konfiguracija poslušalca je njena lastna datoteka in njeno lastno ponovno nalaganje, in več naslovov poslušanja je običajnih. Preverjanje pristnosti je spet tretja odločitev in izjema pri usmerjanju nikomur ne dodeli dostopa. Ohranite preverjanje ključa gostitelja, preverjanje pristnosti računa in omejitve vira na obeh vhodih ter se uprite skušnjavi, da bi oslabili druge nadzore tunela, da bi ena upravljalna pot delovala.
Ohranite obnovitveni kanal, ki ni odvisen od poti, ki jo spreminjate, ker napaka tukaj zaklene samo popravek.
Dokažite to z novo sejo, ne s staro
Vzpostavljen terminal ne dokaže ničesar, ker je bil sprejet pred spremembo. Odprite svežo sejo skozi vsak predvideni vhod.
ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30
Nato ponovite ponovno povezavo VPN in poskusite znova, ker pot, ki preživi ponovno povezavo, ni enaka poti, dodani v tabelo, ki jo ponovna povezava izprazni. Opazujte zavrnjene vire ločeno od dovoljenih, da se blokiran poskus ne skrije za delujočo sejo. Shranite lokalni naslov, pravilo in tabelo poleg rezultata. Če namesto tega razdelite vrata, to zapišite kot obratovalno odločitev in ne kot omejitev SSH.