Tappelüliti blokeerib VPN-serveri enne, kui ükski liiklus liigub
Millist etappi tappelüliti blokeerib: lõpp-punkti otsing, väline marsruut, tagasitee ja vananenud partnerite erandid — loendurite, mitte oletustega.
Tappelülitid ebaõnnestuvad suunas, mida inimesed ei oota: need on ehitatud liiklust blokeerima, kui tunnel on maas, ja tunnelit ehitavad paketid on ise liiklus. See on kogu viga. Reeglistik, mis viskab kõik, mis tunnelist välja ei lähe, viskab ka selle kätlemise, mis selle üles looks, seega klient proovib tsüklis uuesti ja viga omistatakse etapile, mida esimesena kontrollitakse. Enne tulemüüri laiendamist tehke kindlaks, milline kolmest etapist tagasi lükatakse: nimeotsing, väline pakett partnerini või vastus, mis tagasi tuleb.
Kuidas tunnel ja selle enda transport üksteisest sõltuvad
Lugege VPN-klienti kahe võrguseisundina, mis jagavad üht pistikupesa teed. Enne tunneli olemasolu avab klient füüsilisel adapteril pistikupesa ja saadab krüpteeritud kaadrid partneri aadressile ja pordile. Alles pärast selle vahetuse õnnestumist loob ta tunneliseadme ja paigaldab marsruudid. Tappelüliti on poliitika teise seisundi kohta, kirjutatud nii laialt, et kehtib mõlema kohta.
Liidesepõhised reeglid on tavaline vorm: lubage see, mis väljub läbi tun0 või wg0, visake ülejäänud väljundtee kõrvale. See sõnastus ei suuda vabastada kliendi enda ühendust serveriga, seega õige teostus lisab selle erandi selgesõnaliselt, ja seda teete ka teie, kui kirjutate reegleid käsitsi. Windowsi ja macOS-i rakendusepõhised reeglid väldivad osa sellest, sobitades liidese asemel protsessi, kuid protsess peab ikkagi välja pääsema enne, kui tunnel olemas on.
Kolm etappi nende toimumise järjekorras
Esimene etapp on lahendamine. Kui profiil hoiab otsesõnalise aadressi asemel hostinime, vajab klient DNS-vastust enne, kui saab midagi saata. Profiil, mis suunab DNS-i tunneli lahendajale, loob ummiku: lahendaja on kättesaadav ainult selle tunneli kaudu, mille otsing peaks võimaldama. Väljaspool tunnelit lahendamine või lõpp-punkti aadressi külge kinnitamine kõrvaldab ebamäärasuse.
Teine etapp on väline pakett, mis peab selles järjekorras üle elama marsruutimise ja seejärel tulemüüri. wireguard-tools teeb WireGuardi jaoks ära marsruutimise poole, märgistades oma paketid ja lisades poliitikareegli, et need jätaksid vahele äsja paigaldatud vaikemarsruudi; wg-quicki käsiraamatu leht kirjeldab seda reeglit ja tabelit, mida see kasutab. Ehitage see marsruutimine käsitsi uuesti üles või laske teisel tööriistal reeglid ümber kirjutada, ja märgistatud paketid võidakse saata tagasi tunnelisse, mille need peaksid looma.
Kolmas etapp on tagasitee. Vastuseta kätlemine ei ole tõestus väljuvast kõrvaleviskamisest; see sobib sama hästi serveri sissetuleva reegliga või NAT-seadmega, mis unustas vastenduse. Eristage neid enne, kui klienti puutute.
| 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 |
Kliendid logivad sümptomit, mille nad tuvastavad, mitte etappi, mis ebaõnnestus, seega on tabel tavaliselt logist kiirem.
Loendurid otsustavad logidest kiiremini
Linuxis, nft list ruleset või iptables -vnL OUTPUT prindib iga reegli kohta paketiloenduri. Ühenduge korra, laske sellel ebaõnnestuda ja lugege seejärel loendurid uuesti. Reegel, mille loendur on liikunud, on reegel, mille kätlemine tabas; kui mitte kusagil midagi ei liikunud, ei jõudnud pakett kunagi tulemüüri. Olen näinud reeglistikku omaenda kätlemist kõrvale viskamas ja seda ütlesid ainult loendurid.
Et eristada kunagi tulemüüri mitte jõudnud kunagi hostist mitte lahkunud, jälgige liidest ennast. ip -s link show dev wlan0 teatab saadetud paketid ja tcpdump -ni wlan0 udp port 51820 näitab kaadreid. Kui see jääb tasaseks, kui klient uuesti proovib, on viga netfilterist ülalpool: puuduv partneri marsruut, poliitikareegel, mis osutab seadmele, mida veel ei ole, või pistikupesa viga, mille klient alla neelab.
Testige erandeid dokumentatsiooni aadresside vastu, näiteks 203.0.113.10, et eksimus ei saaks kellegi teise hosti uurida.
Vananenud lõpp-punkti erand loetakse serveri rikkena
Kõige eksitavam versioon ilmneb pärast seda, kui partneri aadress on muutunud: dünaamiliste aadresside teenus liigutas selle, host ehitati uuesti üles või teie võrgu väljundaadress erineb. Erand nimetab endiselt vana aadressi, seega tabavad uue aadressi paketid kõrvaleviskamise reeglit. Sama konfiguratsioon töötas eile ja seetõttu alustavad inimesed serveri tõrkeotsinguga.
Hostinimi tulemüürireegli sees ei päästa teid. Nftablesis lahendatakse nimi reeglistiku laadimisel, seega see kinnitab aadressi, mis sel hetkel eksisteeris, ja vananeb nagu otsesõnaline. Kestev lahendus on erandit värskendada, kui lõpp-punkt muutub, ja hoida see kitsana: üks partneri aadress, üks transpordiport. Vahemik, mis on piisavalt lai, et aadressimuutust üle elada, on piisavalt lai ka selleks, et lasta välja kõrvalist liiklust.
Kui tappelüliti töötab serveri hostis
Sama sõltuvus on ka teises otsas ja seal on seda kergem märkamata jätta. Kui masin, mis toimib teie VPN-serverina, käitab ka tappelülitiga töölauaklienti või sülearvutist kopeeritud tulemüüriprofiili, kehtivad selle kõrvaleviskamise reeglid teenusele, mis tunneleid lõpetab. Kliendi kätlemisele saadetud vastused visatakse kõrvale, seega iga klient ei saa ühendust, samal ajal kui server näib terve ja selle tunneliliides seisab kasutuna.
See host vajab enne kõrvaleviskamist kolme kitsast luba: kuulamisport füüsilisel liidesel, tunneliliides dekrüpteeritud liikluse jaoks ja edasisaatmine tunnelist sinna, kuhu kliendid peaksid jõudma. Lugege paigaldatud komplekti käsuga nft list ruleset, iptables -S, või pfctl -sr , enne kui midagi muudate, ja pidage meeles, et salvestatud reeglistik elab üle taaskäivituse, seega elab sealne viga üle protsessi, mis selle tegi.
Taastamise järjekord, mis hoiab masina suletuna
Töötage profiilist väljapoole. Lugege partneri aadress ja port, mida klient kasutab, kinnitage, et hostinimi lahendatakse ilma tunnelita, seejärel lisage üks erand selle aadressi ja pordi jaoks ainult füüsilisel adapteril. Ühenduge uuesti ja jälgige saatmisloendurit; lõpetatud kätlemine on signaal, et teine etapp on parandatud.
Jätke ülejäänud kõrvaleviskamise poliitika testimise ajaks paigale. Kahjutu kontroll on proovida ühendust kõrvalise dokumentatsiooni aadressiga ja kinnitada, et see aegub endiselt, mis näitab, et tappelüliti töötab, mitte et see on välja lülitatud. Pingutage erandit, kui tunnel on stabiilne, ja ärge jätke kliendi binaarile püsivat kõike lubavat reeglit lihtsalt sellepärast, et see on mugav.
Kui tunnel tõuseb ja rakendus ikka ebaõnnestub, ei ole ülejäänud etapid see: jagatud DNS, MTU ja rakendusepõhine marsruutimine tekitavad igaüks ühendatud tunneli katkise liiklusega ja igaühel on erinev esimene kontroll.