Tunelis darbojas, interneta nav: kur apstājas pāradresēšana

Klients pievienojas, tunelis pārraida pingus uz vārteju, un aiz tās nekas neatbild. Šis stāvoklis ir normāls vārtejai, kas vienmēr bija paredzēta tikai piekļuvei aizsargātiem tīkliem, un tas ir bojājums vārtejai, kas reklamēta kā pilna tuneļa izeja. Pirms mainīt noteikumus, apstipriniet, kāds pakalpojums tika solīts. Pēc tam izsekojiet vienu publisku pieprasījumu caur četrām vietām, kur tas var apstāties. Viens pieprasījums un viens pakešu ieraksts atrisina vairāk nekā lapa ar minējumiem.

Apstipriniet, vai izeja internetā vispār bija projektēta

Sadalītā tuneļa profils VPN ievirza tikai aizsargātos apakštīklus, tāpēc publiskā pārlūkošana turpinās pa vietējo saiti un nekad neskar vārteju. Pilna tuneļa profils tunelī instalē noklusējuma maršrutu, padarot vārteju atbildīgu par visu ceļu. Abi ir likumīgi risinājumi, un to sajaukšana rada bojājuma ziņojumu tur, kur tā nav. Izlasiet klienta izsludinātos maršrutus pirms jebko cita testēšanas, jo maršrutu tabula atbild uz jautājumu, ko pieprasījums parasti uzdod nepareizi.

Tas, ko klients instalē, ne vienmēr ir tas, ko profils paredz. Uzspiestu maršrutu var pārspēt vietējais maršruts ar zemāku metriku, un klients, kas saglabā LAN maršrutu, vienlaikus pievienojot noklusējuma maršrutu, uzvedas kā sadalīts tunelis šim apakštīklam.

Izsekojiet vienu publisku pieprasījumu

Izvēlieties vienu galamērķi un izsekojiet to no klienta uz āru. Klientā pārbaudiet, vai pakete patiešām izvēlas tuneli un kādu vietējo adresi tā izmanto kā avotu. Pēc tam pārbaudiet vārteju: vai pakete pienāk un vai tā atstāj publisko saskarni. Katra no šīm atbildēm noņem veselu cēloņu kategoriju.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Ja vārteja paketi nekad neredz, klienta maršruts vai tuneļa izvēle ir nepareiza. Ja tā pienāk un neiziet, problēma ir vārtejā, un darbojas trīs atlikušās pārbaudes.

Pārbaudiet pāradresēšanu, maršrutu un tulkošanu

Ar strongSwan piegādātās pāradresēšanas vadlīnijas attiecas uz jebkura tuneļa tipa vārteju: kodolam ir jāļauj pārvietot paketes starp saskarnēm, un lietojamam maršrutam jārāda uz internetu. Ugunsmūra politikai pēc tam jāatļauj satiksme, un avota adresei jābūt tādai, uz kuru publiskā puse var atbildēt. Privāta klienta adrese, kas pāradresēta uz internetu bez izmaiņām, nekad nesaņem atbildi.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Avota tulkošana ir ierastā trūkstošā daļa. Ar to vārteja pārraksta klienta avotu uz savu publisko adresi un seko plūsmai; bez tās atbildei nav kur iet. Mākoņplatformas pievieno otru robežu, kur instances maršrutu tabula vai drošības grupa var atmest satiksmi, ko pieļauj viesa ugunsmūris. Šo robežu ir viegli palaist garām, jo viesa sistēma no iekšpuses izskatās pareizi konfigurēta.

Apgrieztā ceļa filtrēšana asimetriskā iestatījumā arī var atmest derīgas paketes. Izlasiet šī noteikuma skaitītāju, nevis pieņemiet, ka viss ir kārtībā, jo stingrs iestatījums publiskajā saskarnē noraida satiksmi, kas pienāk pa citu ceļu, nekā paredz maršrutu tabula.

Atbildes ceļš un resolveris ir divas dažādas atbildes

Sekojiet arī atbildei, ne tikai pieprasījumam. Ja pieprasījums iziet tulkots un atbilde atgriežas tulkotajā plūsmā, pāradresēšana darbojas arī tad, kad lietotne joprojām cieš neveiksmi, un nākamā izmeklēšana pieder lietotnei vai DNS.

Vietne, kas atgriež HTTP kļūdu, ir pierādījums, ka pāradresēšana uz internetu darbojas. Vārds, kas netiek atrisināts, kamēr piekļuve pēc adreses darbojas, ir resolvera problēma, nevis NAT.

Pēc precīza labojuma vēlreiz pārbaudiet klientu un jebkuru apzināti ierobežotu privātu resursu. Piekļuves internetam piešķiršana nedrīkst klusi paplašināt piekļuvi katram tīklam, kas pievienots vārtejai.