Näin lukitset Linuxin lähdön niin, ettei mitään vuoda VPN:n pudotessa
Reititys ja suodatus ovat erillisiä päätöksiä. Lukitse lähtökoukku ja rajaa sitten päätepisteen, DNS:n ja hallinnan poikkeukset, joita tunneli tarvitsee yhdistääkseen uudelleen.
Kuvittele kotiliitännässä oleva mediakone, jonka pitäisi päästä internetiin vain tunnelin kautta. Kun tunneli putoaa, sovelluksen pitäisi pysähtyä eikä jatkaa hiljaa fyysisen liitännän kautta. Tämän käytöksen saaminen on palomuurin eikä reitityksen ongelma, ja ero on merkityksellinen, koska reitti voidaan korvata daemonin uudelleenkäynnistyksellä, kun taas suodatin pysyy siinä, mihin sen laitoit. Seuraavaksi käydään läpi, miten paketin polku todella päättää, ja sitten miten rajataan poikkeukset, jotka pitävät tunnelin yhdistymässä uudelleen.
Paikallinen lähtö on eri koukku kuin edelleenlähetys
Paketti, joka lähtee koneella olevasta sovelluksesta, kulkee lähtökoukun kautta; paketti, jonka kone reitittää toiselle isännälle, kulkee edelleenlähetyksen kautta. Käytäntö, joka mainitsee vain forward:n, rajoittaa jälkimmäistä ja jättää ensimmäisen täysin avoimeksi, ja siksi niin monet lähtölukot näyttävät oikeilta eivätkä tee mitään. Liitännän sovitus kuuluu samaan sääntöön: oifname "tun0" accept päästää läpi liikennettä, joka on jo reititetty tunnelin kautta. Reititys ja suodatus pysyvät myös erillisinä päätöksinä, joten yhteysreitti voi olla olemassa samalla kun suodatin hylkää paketin. Juuri tähän erotteluun luotat.
Yhdyskäytävä, joka välittää muiden laitteiden liikennettä, tarvitsee molemmat koukut. Vain lähdön lukitseminen suojaa koneen itsensä ja jättää jokaisen alavirran asiakkaan vapaaksi vuotamaan.
Kirjoita poikkeusluettelo päätepisteestä ulospäin
Aloita tunnelin päätepisteestä: yksi kohdeosoite tai pieni hyväksytty joukko, kuljetusprotokolla ja kohdeportti, esimerkiksi udp dport 1194 ip daddr 203.0.113.7 accept. Jos asiakas ratkaisee isäntänimen, alustava DNS-vaihto tarvitsee oman sääntönsä, joka rajataan ratkaisijaan ja porttiin 53, ei yleistä lupaa kyseisen ratkaisijan osoitteeseen. Jokaisen poikkeuksen pitäisi nimetä syy, jonka vuoksi se on olemassa. Lupa kaikelle UDP-liikenteelle VPN-porttiin kattaa paljon enemmän kuin se yksi todennettu palvelu, joka sinulla oli mielessä.
Alustava nimien ratkaisu on paikka, jossa lukot yleensä mätänevät. Ajastimella päivittyvä osoitejoukko tarvitsee määritellyn käytöksen, kun päivitys epäonnistuu, eikä se käytös voi olla yhteyden avaaminen, kunnes se onnistuu. Päivitä tunnelin kautta, kun tunneli on pystyssä, ja muuten palaa viimeiseen tunnettuun terveeseen päätepisteeseen.
Paikallinen hallinta tarvitsee saman kohtelun. Hallintaverkko ei ole luotettava vain siksi, että sen osoitteet ovat yksityisiä, ja sääntö, joka luottaa siihen, kutsuu toisen polun lukon ohi.
Liitännän sovitus ei todista tervettä tunnelia
Säännöt, jotka hyväksyvät kaiken liitännästä tun0 lähtevän, olettavat, että kyseisen liitännän paketti tuli tunnelista. Liitäntöjen nimet luodaan uudelleen, eikä nimi ole kryptografinen identiteetti. Vastapuoli voi myös olla poissa, kun liitäntä pysyy pystyssä, mikä tekee säännöstä erittäin vakuuttavan ei-minkään-tekemisen.
Yhteyksien seuranta lisää siihen liittyvän ansan. Laaja sääntö muodostetuille yhteyksille toistaa luvan, jonka vuo sai aiemmin, joten ennen tunnelin putoamista alkanut istunto jatkuu sen jälkeen. Rajaa tilaan perustuva hyväksyntä liitäntöihin ja osoitteisiin, joita todella tarkoitat, tai olet rakentanut lukon, joka avaa itsensä. Tulo- ja lähtösäännöt vastaavat myös eri kysymyksiin, ja toisen kovettaminen toisen jäädessä huomiotta jättää koneen tavoitettavaksi siihen suuntaan, jota et ajatellut.
Mikä selviää daemonin kaatumisesta
Suodatin, jonka asentaa skripti, joka ajetaan tunnelin nousemisen jälkeen, katoaa tunnelin mukana juuri sillä hetkellä, kun sitä tarvittiin. Lataa lukko käynnistyksen yhteydessä ja anna daemonin hallita vain omia poikkeuksiaan.
Oletusreitin poistaminen ei ole sekään korvike. Reitti on tilaa, jonka daemon omistaa ja kirjoittaa uudelleen, ja sen poistaminen voi viedä polun, jota tarvitaan uudelleenyhdistämiseen. IPv6 tarvitsee oman suunnitelmansa, koska naapurien löytäminen ja reitittimen ilmoitukset ovat linkkipalveluja, joiden on toimittava, kun tavallinen liikenne on estetty. DHCP kuuluu samaan luokkaan. Kirjaa nämä poikkeuksiksi, joilla on tarkoitus, sen sijaan että löytäisit ne myöhemmin katkoksina.
Palautumispolku ennen käyttöönottoa
Testaa lukkoa niin kuin se epäonnistuu: käynnistä ilman tunnelia, tapa daemon, vaihda päätepiste ja yhdistä uudelleen. Jokaisen tapauksen pitäisi pysäyttää sovellukset ja jättää palautumiskanava toimivaksi. Tee se konsolista, koska etäkuori on istunto, joka todennäköisimmin lukitaan oman sääntösi ulkopuolelle.
Tarkista sitten, mihin tavallinen sovellus vielä pääsee, vaarattomalla kohteella ja pyynnöllä, jonka voit varmistaa. Haluamasi tulos on hylkäys yhteydellä ja onnistuminen tunnelin kautta, ei monitulkintainen aikakatkaisu, joka voisi tarkoittaa kumpaa tahansa. Pidä sääntöjoukko saman omistajan alla kuin muukin palomuuri, sen sijaan että korvaisit koko taulukon komentotulkin skriptistä. Käytäntö, jossa jokainen lupa voi perustella itsensä, on arvokkaampi kuin pitkä sääntöjoukko, jota kukaan ei osaa selittää.