Instants käivitub, paketipaigaldused õnnestuvad ja teenus teatab isegi töötavast olekust, kuid midagi ei ühendu. See muster on virtuaalsetes privaatserverites tavaline, sest külaline, kes jõuab mugavalt internetti, ei pruugi ikkagi suuta luua liidest, mida teie protokoll nõuab. Viis kontrolli eristavad hosti, mis suudab tunnelit teenindada, sellest, mis ainult näib valmis, ja esimene ebaõnnestuv kontroll selgitab tavaliselt kõike järgnevat. Igaüks on odav käivitada ja lõpeb otsusega, mitte märkusega.

Kinnitage liides, mida protokoll vajab

OpenVPN üle TUN-i vajab märgiseadet ja selle taga olevat tuumamoodulit; WireGuard vajab oma tuumatoetust või kasutajaruumi rakendust sobivate ootustega. Hallatavad konteinerid võivad jagada hosti tuuma, mis ei paljasta seadet kunagi, ja mõned platvormid keelavad tunneliliideste loomise täielikult, sõltumata sellest, mis on paigaldatud.

Testige võimekust, mitte lugege tugilehte, sest turundussildid muutuvad kiiremini kui tegelikud piirid. Ühe plaani jaoks kirjutatud funktsioonide loend ei pruugi kirjeldada tuuma, millel külaline tegelikult töötab. Kaks lühikest käsku vastavad küsimusele levinud protokollide puhul ja mõlemad koristavad enda järelt. Allolevad käsud ei loo midagi püsivat ja eemaldatakse kohe.

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

Keeldumine esimesel paaril tähendab, et TUN ei ole saadaval ja OpenVPN-i vaikimisi režiim ei saa käivituda; keeldumine viimasel real tähendab, et WireGuard-i tuumaliides puudub. Tuuma TUN/TAP dokumentatsioon kirjeldab seadet, mida esimene kontroll proovib. Kumbagi tõrget ei paranda VPN-paketi uuesti paigaldamine.

Pidage meeles, et sissetuleval teel on kaks omanikku

Pakkuja võrgureeglid ja külalise tulemüür on eraldi süsteemid ning liiklus peab üle elama mõlemad. Külalisele seotud kuulaja ei tähenda midagi, kui pakkuja turvagrupp pordi maha viskab, ja pakkuja avatud reegel ei tee midagi, kui külaline paketi tagasi lükkab. Kontrollige kuulajat, seejärel külalise reegleid, seejärel pakkuja paneeli, selles järjekorras, ja kinnitage nii protokoll kui ka pordi number. Otse pakkuja paneeli hüppamine on viis, kuidas inimesed avavad vahemiku, mida neil polnud vaja.

UDP on tavaline ohver: paljud platvormid lubavad TCP-d vaikimisi ja käsitlevad UDP reegleid eraldi kirjena. Kui instants asub pakkuja NAT-i taga, selle asemel et hoida avalikku aadressi, muutub pordiedastus pakkuja poolel kolmandaks konfiguratsiooniks, mida tuleb sobitada.

Planeerige tagasitee, mitte ainult väljumine

Täistunneli teenus vajab lubatud edastamist, kliendiliikluse tõlke- või marsruutimisskeemi ja tagasiteed, mis jõuab kliendikogumini. Kuulaja avamine ei anna neist ühtegi. Tunnel, mis luuakse, kuid ei kanna kasulikku liiklust, ebaõnnestub tavaliselt siin, mitte autentimisel. Käsitlege õnnestunud kätlust diagnoosi algusena, mitte selle lõpuna.

Kirjutage plaan kolme konkreetse otsusena: millise lähtevahemiku kliendid saavad, kuidas nende liiklus interneti poole väljub ja kuidas vastused tagasitee leiavad. Seejärel kinnitage, et tuum nõustub plaaniga, enne kui klienti testite, et vaikne lahknevus ei läheks kliendipoolse vea pähe.

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

Otsustage IPv6 küsimus selgesõnaliselt

IPv6 tuleb mitme mehhanismi kaudu, mis käituvad lüüsi jaoks erinevalt: aadress instantsil, marsruuditud prefiks või mitte midagi. Ainult marsruuditud prefiks lubab serveril anda klientidele aadresse tavalisel viisil. Eeldus, et hostil töötav IPv6 aadress tähendab kasutatavat kliendiprefiksit, on viga, mis ilmneb hiljem pooliku ühenduvusena. See on selline tõrge, mis elab üle iga testi, mis tehakse ainult IPv4-ga.

Kui pakkuja ei marsruudi ühtegi prefiksit, otsustage, kas tunnel on ainult IPv4 ja kas klientidele tuleks seda öelda. Dokumenteeritud puudumine on turvalisem kui osaline konfiguratsioon, mis saadab IPv6 sihtkohad ühendatud kasutajate jaoks vaikselt musta auku.

Tõestage seda välise kliendi abil

Kohalik teenuse olek kirjeldab ühte protsessi ühes hostis. Kasulik test on volitatud klient teises võrgus, kes ühendub profiiliga, mida kavatsete levitada, seejärel jõuab rakenduseni ja lahendab nime. Ühenduge ka korra uuesti, sest tunnel, mis töötab ainult esimesel katsel, ei täida nõuet, mis praktikas kõige rohkem loeb.

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

Hoidke testi kõrval töökohustused: ruumi uuendusteks, piiratud logid, haldusjuurdepääs, mis ei sõltu tunnelist, taastamiskonsool ja märkus selle kohta, mis juhtub kliendiprofiilidega, kui instants uuesti üles ehitatakse ja selle avalik aadress muutub. Kui vajalik liides või edastusmudel lihtsalt puudub, ei anna seda ükski kliendipoolne muudatus, ja aus järgmine samm on teine instantsitüüp, mitte rohkem konfiguratsiooni.

Seotud artiklid