Kill switch estää VPN-palvelimen ennen kuin liikenne ehtii virrata
Minkä vaiheen kill switch estää: päätepisteen haku, ulompi reitti, paluupolku ja vanhentuneet vertaispoikkeukset — laskureilla arvausten sijaan.
Kill switchit epäonnistuvat suunnassa, jota ihmiset eivät odota: ne on rakennettu estämään liikennettä, kun tunneli on alhaalla, ja tunnelin rakentavat paketit ovat itse liikennettä. Siinä on koko vika. Sääntöjoukko, joka pudottaa kaiken, mikä ei poistu tunnelin kautta, pudottaa myös sen kättelyn, joka nostaisi sen, joten asiakas yrittää uudelleen silmukassa ja virhe kuuluu vaiheelle, joka tarkistetaan ensin. Ennen palomuurin laajentamista selvitä, mikä kolmesta vaiheesta hylätään: nimenhaku, ulompi paketti vertaiselle vai palaava vastaus.
Miten tunneli ja sen oma kuljetus riippuvat toisistaan
Lue VPN-asiakas kahdeksi verkkotilaksi, jotka jakavat yhden pistokepolun. Ennen kuin tunneli on olemassa, asiakas avaa pistokkeen fyysiselle sovittimelle ja lähettää salatut kehykset vertaisen osoitteeseen ja porttiin. Vasta kun tuo vaihto onnistuu, se luo tunnelilaitteen ja asentaa reitit. Kill switch on politiikka toisesta tilasta, kirjoitettu niin laveasti, että se koskee molempia.
Liitäntäpohjaiset säännöt ovat tavallinen muoto: hyväksy se, mikä lähtee tun0 tai wg0 kautta, pudota muu lähtöpolku. Tämä muotoilu ei voi vapauttaa asiakkaan omaa yhteyttä palvelimeen, joten oikea toteutus lisää sen poikkeuksen nimenomaisesti, ja niin teet sinäkin kirjoittaessasi sääntöjä käsin. Windowsin ja macOS:n sovelluskohtaiset säännöt väistävät osan tästä sovittamalla liitännän sijaan prosessin, mutta prosessin on silti päästävä ulos ennen kuin tunneli on olemassa.
Kolme vaihetta siinä järjestyksessä kuin ne tapahtuvat
Ensimmäinen vaihe on selvitys. Kun profiili tallentaa kirjaimellisen osoitteen sijaan isäntänimen, asiakas tarvitsee DNS-vastauksen ennen kuin se voi lähettää mitään. Profiili, joka osoittaa DNS:n tunnelin selvittäjään, luo umpikujan: selvittäjä on tavoitettavissa vain sen tunnelin kautta, jonka haku olisi määrä mahdollistaa. Selvittäminen tunnelin ulkopuolella tai päätepisteen kiinnittäminen osoitteeseen poistaa epäselvyyden.
Toinen vaihe on ulompi paketti, jonka on kestettävä ensin reititys ja sitten palomuuri, juuri siinä järjestyksessä. wireguard-tools hoitaa reitityspuolen tästä WireGuardille merkitsemällä omat pakettinsa ja lisäämällä politiikkasäännön, jotta ne ohittavat juuri asennetun oletusreitin; wg-quickin manuaalisivu kuvaa tuon säännön ja taulun, jota se käyttää. Rakenna reititys uudelleen käsin tai anna toisen työkalun kirjoittaa säännöt uudelleen, ja merkityt paketit voidaan lähettää takaisin tunnelille, joka niiden on määrä luoda.
Kolmas vaihe on paluupolku. Kättely ilman vastausta ei ole todiste lähtevästä pudotuksesta; se sopii yhtä hyvin palvelimen saapuvan liikenteen sääntöön tai NAT-laitteeseen, joka unohti kartoituksen. Erottele ne ennen kuin kosket asiakkaaseen.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Asiakkaat kirjaavat havaitsemansa oireen, eivät epäonnistunutta vaihetta, joten taulukko on yleensä lokia nopeampi.
Laskurit ratkaisevat lokia nopeammin
Linuxissa, nft list ruleset tai iptables -vnL OUTPUT tulostaa pakettilaskurin sääntöä kohti. Yhdistä kerran, anna sen epäonnistua ja lue sitten laskurit uudelleen. Sääntö, jonka laskuri on liikkunut, on sääntö, johon kättely osui; jos missään ei ole liikkunut mikään, paketti ei koskaan saavuttanut palomuuria. Olen nähnyt sääntöjoukon pudottavan oman kättelynsä, ja vain laskurit kertoivat sen.
Erottele ei koskaan saavuttanut palomuuria siitä, ettei koskaan lähtenyt isännästä, tarkkailemalla itse liitäntää. ip -s link show dev wlan0 ilmoittaa lähetetyt paketit, ja tcpdump -ni wlan0 udp port 51820 näyttää kehykset. Jos se pysyy tasaisena, kun asiakas yrittää uudelleen, vika on netfilterin yläpuolella: puuttuva vertaisreitti, politiikkasääntö, joka osoittaa laitteeseen, jota ei vielä ole, tai pistokevirhe, jonka asiakas nielaisee.
Testaa poikkeuksia dokumentaatio-osoitteilla kuten 203.0.113.10, jotta lipsahdus ei voi luodata jonkun toisen isäntää.
Vanhentunut päätepistepoikkeus luetaan palvelimen katkoksi
Harhaanjohtavin versio ilmaantuu, kun vertaisen osoite on muuttunut: dynaamisten osoitteiden palvelu on siirtänyt sen, isäntä on rakennettu uudelleen tai verkkosi lähtöosoite on eri. Poikkeus mainitsee yhä vanhan osoitteen, joten uuteen menevät paketit osuvat pudotussääntöön. Sama kokoonpano toimi eilen, ja siksi ihmiset aloittavat palvelimen vianetsinnästä.
Isäntänimi palomuurisäännön sisällä ei pelasta sinua. Nftablesissa nimi selvitetään, kun sääntöjoukko ladataan, joten se kiinnittää sen osoitteen, joka tuolla hetkellä oli, ja vanhenee kuin kirjaimellinen. Kestävä ratkaisu on päivittää poikkeus, kun päätepiste muuttuu, ja pitää se kapeana: yksi vertaisosoite, yksi kuljetusportti. Väli, joka on tarpeeksi leveä kestämään osoitteenmuutoksen, on tarpeeksi leveä myös päästämään asiaankuulumatonta liikennettä ulos.
Kun kill switch toimii palvelimen isännässä
Sama riippuvuus on toisessa päässä, ja siellä se on helpompi jättää huomaamatta. Jos kone, joka toimii VPN-palvelimenasi, ajaa myös työpöytäasiakasta kill switchillä tai kannettavasta kopioitua palomuuriprofiilia, sen pudotussäännöt koskevat palvelua, joka lopettaa tunnelit. Vastaukset asiakkaan kättelyyn pudotetaan, joten jokainen asiakas epäonnistuu yhdistämisessä, kun palvelin näyttää terveeltä ja sen tunneliliitäntä seisoo käyttämättömänä.
Se isäntä tarvitsee kolme kapeaa hyväksyntää ennen pudotusta: kuunteluportin fyysisellä liitännällä, tunneliliitännän salatulle liikenteelle ja välityksen tunnelista sinne, minne asiakkaiden on määrä päästä. Lue asennettu joukko komennolla nft list ruleset, iptables -S tai pfctl -sr , ennen kuin muutat mitään, ja muista, että tallennettu sääntöjoukko selviää uudelleenkäynnistyksestä, joten siellä oleva virhe elää kauemmin kuin sen tehnyt prosessi.
Palautusjärjestys, joka pitää koneen suljettuna
Työskentele profiilista ulospäin. Lue vertaisen osoite ja portti, jota asiakas käyttää, varmista, että isäntänimi selvitetään ilman tunnelia, ja lisää sitten yksi poikkeus tuolle osoitteelle ja portille vain fyysiselle sovittimelle. Yhdistä uudelleen ja seuraa lähetyslaskuria; valmistunut kättely on merkki siitä, että toinen vaihe on korjattu.
Jätä muu pudotuspolitiikka paikoilleen testauksen ajaksi. Vaaraton tarkistus on yrittää yhteyttä asiaankuulumattomaan dokumentaatio-osoitteeseen ja varmistaa, että se yhä aikakatkaistaan, mikä osoittaa kill switchin toimivan eikä olevan kytketty pois. Kiristä poikkeusta, kun tunneli on vakaa, äläkä jätä asiakasohjelmalle pysyvää kaiken sallivaa sääntöä vain siksi, että se on kätevää.
Jos tunneli nousee ja sovellus yhä epäonnistuu, jäljellä olevat vaiheet eivät ole tämä: jaettu DNS, MTU ja sovelluskohtainen reititys tuottavat kukin yhdistetyn tunnelin, jossa liikenne on rikki, ja kullakin on eri ensimmäinen tarkistus.