VPN on ühendatud, aga tulemüür blokeerib endiselt: kuidas teha kindlaks, milline

Tunnel töötab ja üks port ei toimi endiselt. Lugege tee läbi, seejärel poliitika igal kihil, ja muutke kitsaimat reeglit, selle asemel et üks kahest kontrollist välja lülitada.

Klient ütleb, et on ühendatud, ressurss keeldub endiselt, ja tavaline järgmine samm on midagi välja lülitada. Selle lause kaks kontrolli teevad erinevat tööd: VPN ehitab kaetud liiklusele tee, ja tulemüür otsustab iga ühenduse kohta, kas liiklus tohib läbi minna. Töötav tunnel keelduva poliitikaga näeb kasutaja toolilt täpselt välja nagu katkine tunnel, seega on ülesanne leida, milline kiht vastab. Siin on järjekord, mida ma järgin, koos lugemisega, mis ütleb teile, millal lõpetada.

Eraldage tee poliitikast

Alustage rikke kujust, sest see on tasuta info. Paketi mahaviskamine tekitab ajalõpu: klient proovib uuesti, midagi ei tule tagasi ja käsk ripub, kuni annab alla. Keeldumine tekitab keeldumise või lähtestamise: miski vastas ja ütles ei. Teenus, mis ei kuula, keeldub hosti enda peal, ilma igasuguse tulemüürita.

Need kolm tulemust osutavad erinevatele kihtidele. Ajalõpp tähendab, et kuskil viskab poliitika vaikselt maha, või et tee ei lahku masinast kunagi. Keeldutud tähendab, et jõudsid hostini ja selle virn või hosti tulemüür keeldus. Täielik vaikus, kui tunneli liides on üleval ja sihtkohta pole teed, tähendab, et tee on vale ja ükski tulemüürireegel seda ei paranda.

Lugege tee ühe läbimisega

Kinnitage, et tunnel katab sihtkoha, enne kui vaatate ühtki reeglit. Split-tunnel, mis kannab ainult kontori alamvõrku, ei suuna päringut teise vahemikku, ja siis näeb rike välja nagu tulemüüri blokeering, mis see pole:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Marsruudi väljund nimetab liidese, mille kaudu pakett lahkub, ja lähteaadressi, mida see kannab. Kui see liides on teie füüsiline võrgukaart, mitte tunnel, on probleem marsruutimises või tunneli lubatud vahemikes, ja see kuulub VPN-i seadistusse, mitte tulemüüri alla.

Üks VPN-ile omane lõks väärib eraldi kontrolli. WireGuardis on partneri AllowedIPs korraga marsruut ja krüptograafiline filter: pakett, mille lähteaadress ei kuulu partneri lubatud hulka, visatakse maha enne, kui ühtki tulemüürireeglit vaadatakse. Nii võib täiesti korrektne hosti tulemüür seista vaikse mahaviskamise taga, mis näeb välja nagu poliitika, ja parandus on võtme seadistusrida, mitte reegel.

Lugege poliitikat kihil, mis vastab

Kui tee on õige, käige poliitika hostist väljapoole läbi ja jälgige seda ühte kihti, mille loendurid liiguvad:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Kuulav pistik vastab teisele küsimusele kui reeglid. Kui pordil ei kuula miski, keeldub tuum ühendusest ja ükski sissetulev reegel pole asjakohane. Kui pistik on olemas ja ühendus kaugkliendist aegub, toimub kuskil teel mahaviskamine, ja reeglite loendurid ütlevad, kas see toimub siin.

Lülitage sisse logimine profiilile või ahelale, mida kahtlustate, selle asemel et väljastpoolt oletada. Üks logitud mahaviskamine, mis nimetab allika, sihtkoha ja pordi, tuvastab kihi ja reegli, ning tõestab ka, et pakett kohale jõudis, mida ükski kliendipoolne test tuvastada ei suuda.

Lugege lüüsi otsust, kui tunnel seal lõpeb

Koha-kohta või kaugjuurdepääsu lüüsil autendib VPN kasutaja ja poliitika volitab ressursi, ning need on eraldi load. Tunnelisse lubatud kasutajal ei ole automaatselt luba igasse sisemisse hosti, ja keeldumine tuleb sageli edastusreeglist, samal ajal kui tunnel ise on terve. Sama eraldus ilmneb IPsecis, kus liiklust valiv turbepoliitika erineb filtrist, mis selle läbi laseb, ja seetõttu on need dokumenteeritud erinevate mehhanismidena RFC 4301.

Kontrollige tagasiteed sama hoolikalt kui väljuvat. Olekupõhine filtreerimine peab vastust nägema, seega asümmeetriline marsruutimine läbi tunneli ühes suunas ja sellest mööda teises tekitab mahaviskamisi, mis näivad juhuslikena ja korduvad ainult mõnede klientide puhul. Kui liiklus jõuab lüüsini ja peatub, lugege edastusreegel ja tagasitee koos, enne kui midagi laiendate.

Lüüs on ka koht, kus NAT-i või maskeerimise reegel võib tegeliku allika peita. Kui sisemised hostid näevad lüüsi aadressi kliendi asemel, ei sobi nende hosti tulemüüri reeglid, mis peaksid kliendibasseiniga sobima, kunagi, ja parandus kuulub lüüsile, mitte igale serverile.

Muutke kitsaimat kihti, seejärel kontrollige

Vastustage ulatuslikku parandust. Hosti tulemüüri väljalülitamine, kõike lubava reegli lisamine või iga liidese usaldusväärsesse profiili surumine eemaldab iga kord kontrolli, mis oma tööd tegi, ja muudatus jääb juhtumist kauemaks. Allikavahemiku ja asjaomase pordiga piiratud reeglit on lihtsam üle vaadata, lihtsam eemaldada ja see jätab masina ülejäänud poliitika puutumata.

Kontrollige sama testiga, mis ebaõnnestus, samast kliendist, ja siis veel kord pärast taasühendamist, sest reegel, mis sobis enne tunneli uut läbirääkimist, võib pärast seda enam mitte sobida:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Enne kui asja sulgete:

  • Tee sihtkohta lahkub tunneli liidese kaudu ja lähteaadress vastab sellele, mida poliitika ootab.
  • Pordil kuulab miski, ja keeldumine või ajalõpp omistatakse nimetatud reeglile, mitte ei eeldata.
  • Lüüs edastab mõlemas suunas ja sihtkoht näeb allikat, mille jaoks teie reeglid kirjutati.
  • Ühtegi kontrolli ei lülitatud välja, et test läbiks, ja tehtud muudatus nimetab ühe allikavahemiku ja ühe pordi.

Seotud artiklid