VPN prisijungta, bet ugniasienė vis tiek blokuoja: kaip nustatyti, kuri

Tunelis veikia, o vienas prievadas vis dar nepavyksta. Perskaitykite kelią, tada kiekvieno sluoksnio politiką, ir pakeiskite siauriausią taisyklę, o ne išjunkite vieną iš dviejų kontrolių.

Klientas sako prisijungęs, išteklius vis dar atmeta, o įprastas kitas žingsnis yra ką nors išjungti. Abi šio sakinio kontrolės atlieka skirtingą darbą: VPN nutiesia kelią uždengtam srautui, o ugniasienė kiekvienam ryšiui nusprendžia, ar srautas gali praeiti. Veikiantis tunelis su atmetančia politika iš naudotojo kėdės atrodo lygiai kaip sugedęs tunelis, todėl užduotis yra išsiaiškinti, kuris sluoksnis atsako. Štai tvarka, kurios laikausi, su skaitymu, kuris liepia sustoti.

Atskirkite kelią nuo politikos

Pradėkite nuo gedimo formos, nes tai nemokama informacija. Paketo numetimas sukelia laiko limitą: klientas bando dar kartą, niekas negrįžta, o komanda kabo, kol pasiduoda. Atmetimas sukuria atsisakymą arba nustatymą iš naujo: kažkas atsakė ir pasakė ne. Tarnyba, kuri neklauso, atmeta pačiame mazge, be jokios ugniasienės.

Šie trys rezultatai rodo skirtingus sluoksnius. Laiko limitas reiškia, kad kažkur politika tyliai numeta, arba kelias niekada neišeina iš mašinos. Atmesta reiškia, kad pasiekėte mazgą ir jo dėklas arba vietinė ugniasienė atsisakė. Visiška tyla, kai tunelio sąsaja įjungta ir nėra kelio į paskirties vietą, reiškia, kad kelias neteisingas ir jokia ugniasienės taisyklė to nepataisys.

Perskaitykite kelią vienu ėjimu

Patvirtinkite, kad tunelis apima paskirties vietą, prieš žiūrėdami į vieną taisyklę. Padalintas tunelis, kuris neša tik biuro potinklį, neperduos užklausos į kitą diapazoną, ir tada gedimas atrodo kaip ugniasienės blokavimas, kuris nėra toks:

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

Maršruto išvestis nurodo sąsają, per kurią paketas išeis, ir šaltinio adresą, kurį jis nešis. Jei ta sąsaja yra jūsų fizinė tinklo plokštė, o ne tunelis, problema yra maršrutizavime arba leistinuose tunelio diapazonuose, ir ji priklauso VPN konfigūracijai, o ne ugniasienei.

Vieni VPN būdingi spąstai nusipelno atskiros patikros. WireGuard programoje partnerio AllowedIPs yra ir maršrutas, ir kriptografinis filtras: paketas, kurio šaltinio adresas neatitinka leistino partnerio rinkinio, numetamas prieš patikrinant bet kurią ugniasienės taisyklę. Todėl visiškai teisinga mazgo ugniasienė gali stovėti už tylaus numetimo, kuris atrodo kaip politika, o pataisa yra rakto konfigūracijos eilutė, ne taisyklė.

Perskaitykite politiką tame sluoksnyje, kuris atsako

Kai kelias teisingas, pereikite politiką nuo mazgo į išorę ir stebėkite vieną sluoksnį, kurio skaitikliai juda:

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

Klausantis lizdas atsako į kitą klausimą nei taisyklės. Jei prievade niekas neklauso, branduolys atmeta ryšį ir jokia įeinančioji taisyklė nėra svarbi. Jei lizdas egzistuoja ir ryšys iš nuotolinio kliento baigiasi, kažkur kelyje vyksta numetimas, o taisyklių skaitikliai pasako, ar tai vyksta čia.

Įjunkite registravimą profiliui ar grandinei, kurią įtariate, o ne spėliokite iš išorės. Vienas užregistruotas numetimas, nurodantis šaltinį, paskirtį ir prievadą, identifikuoja sluoksnį ir taisyklę, taip pat įrodo, kad paketas atvyko, ko joks kliento pusės testas negali nustatyti.

Perskaitykite tinklų sietuvos sprendimą, kai tunelis ten baigiasi

Svetainės su svetaine arba nuotolinės prieigos tinklų sietuvoje VPN autentifikuoja naudotoją, o politika suteikia teisę į išteklių, ir tai yra atskiri suteikimai. Naudotojas, įleistas į tunelį, nėra automatiškai įleidžiamas į kiekvieną vidinį mazgą, o atsisakymas dažnai ateina iš perdavimo taisyklės, kol pats tunelis yra sveikas. Tas pats atskyrimas matomas IPsec, kur srautą atrenkanti saugumo politika skiriasi nuo filtro, kuris jį įleidžia, ir todėl abu dokumentuojami kaip skirtingi mechanizmai RFC 4301.

Patikrinkite grįžtamąjį kelią taip pat atidžiai kaip išeinamąjį. Būsenos filtravimas turi matyti atsakymą, todėl asimetrinis maršrutizavimas per tunelį viena kryptimi ir aplink jį kita sukelia numetimus, kurie atrodo atsitiktiniai ir kartojasi tik iš kai kurių klientų. Jei srautas pasiekia tinklų sietuvą ir sustoja, perskaitykite perdavimo taisyklę ir grįžtamąjį kelią kartu prieš ką nors plečiant.

Tinklų sietuva taip pat yra vieta, kur NAT arba maskavimo taisyklė gali paslėpti tikrąjį šaltinį. Jei vidiniai mazgai mato tinklų sietuvos adresą, o ne klientą, jų mazgo ugniasienės taisyklės, kurios turi atitikti klientų telkinį, niekada neatitiks, ir pataisa priklauso tinklų sietuvai, o ne kiekvienam serveriui.

Pakeiskite siauriausią sluoksnį, tada patikrinkite

Priešinkitės plačiam remontui. Išjungus mazgo ugniasienę, pridėjus leidžiančią viską taisyklę arba įstūmus kiekvieną sąsają į patikimą profilį, kiekvienu atveju pašalinama kontrolė, kuri atliko savo darbą, ir pakeitimas išgyvena incidentą. Taisyklė, apribota šaltinio diapazonu ir atitinkamu prievadu, yra lengviau peržiūrima, lengviau pašalinama ir palieka likusią mašinos politiką nepaliestą.

Patikrinkite tuo pačiu testu, kuris nepavyko, iš to paties kliento, o paskui dar kartą po pakartotinio prisijungimo, nes taisyklė, kuri atitiko prieš tuneliui vėl derantis, gali nustoti atitikti po to:

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

Prieš užverdami:

  • Kelias į paskirties vietą išeina per tunelio sąsają, o šaltinio adresas atitinka tai, ko tikisi politika.
  • Prievade kažkas klauso, o atsisakymas arba laiko limitas priskiriamas įvardytai taisyklei, o ne daromas prielaida.
  • Tinklų sietuva perduoda abiem kryptimis, o paskirties vieta mato šaltinį, kuriam buvo parašytos jūsų taisyklės.
  • Nė viena kontrolė nebuvo išjungta, kad testas praeitų, o jūsų pakeitimas nurodo vieną šaltinio diapazoną ir vieną prievadą.

Susiję straipsniai