Publiskais prefikss caur OpenVPN: izlabot atgriešanās ceļu

Novērojiet, kā tunelis paceļas un klients pingē otru pusi, un tad publiskā adrese, kas pieder aiz VPN, atbild no citurienes vai neatbild vispār. Šim simptomam parasti nav nekāda sakara ar šifru vai sertifikātiem. Pakalpojumu sniedzēja maršrutēts prefikss tiek piegādāts kā IP maršruts, un tā pārnešana caur OpenVPN nozīmē atjaunot šo maršrutu divos līmeņos un saglabāt avota adresi atgriešanās ceļā. WAN tiltot nav nepieciešams, un adreses pievienošana saskarnei nerada augšupējo maršrutu.

Prefikss vispirms ir jāmaršrutē uz jums

Jautājiet pakalpojumu sniedzējam, kā bloks tiek piegādāts. Prefikss, kas maršrutēts uz jūsu servera galveno adresi, ir kas cits nekā adreses, kuras sniedzējs sagaida sasniegt tieši WAN segmentā. Ar šeit aprakstīto dizainu darbojas tikai pirmais modelis.

Ja sniedzējs maršrutē 198.51.100.64/28 uz jūsu ieejas serveri, šī diapazona paketes nonāk serverī un tur apstājas, ja vien jūs tās nepārsūtāt. Ja sniedzējs tā vietā tiltu savieno diapazonu ar jūsu uplink, serverim par to jāatbild ar ARP, kas ir cita problēma.

Pārbaudiet piegādes modeli pirms OpenVPN aizskaršanas: no ārpuses pingējiet adresi blokā un novērojiet, kura saskarne to saņem. Ja nekas neienāk, nekāda tuneļa konfigurācija nepalīdzēs. Ja adrese atbild tieši WAN, sniedzējs tiltu savieno, nevis maršrutē, un tālāk aprakstītais dizains nav piemērojams.

Divi maršrutēšanas līmeņi: kodola maršruts un iroute

OpenVPN vajag prefiksu divās vietās. Kodolam jāzina, ka prefikss pieder tuneļa ierīcei, lai pārsūtītās paketes nonāktu OpenVPN, nevis noklusējuma maršrutā. OpenVPN jāzina arī, kurš autentificētais klients pieder prefiksu, un tas ir iroute ieraksts klientam raksturīgajā direktorijā.

Servera puses maršruts izskatās šādi, un prefiksam un maskai jāatbilst piešķīrumam:

ip route add 198.51.100.64/28 dev tun0

Klientam raksturīgā konfigurācija piešķir īpašumtiesības. Ievietojiet to CCD failā, kas nosaukts pēc klienta sertifikāta kopējā nosaukuma, un pārliecinieties, ka tieši šo direktoriju serveris patiešām lasa:

iroute 198.51.100.64 255.255.255.240

OpenVPN dokumentācija par maršrutētiem tīkliem apraksta abus līmeņus un to, kāpēc tie ir atdalīti. Kodola maršruts bez iroute sūta paketes tunelī bez īpašnieka, un OpenVPN tās izmet. iroute bez kodola maršruta atstāj paketes servera noklusējuma ceļā. Abas kļūdas no klienta puses izskatās kā salauzts tunelis.

Kur dzīvo pakalpojuma adrese

Deleģētais prefikss nav tas pats, kas paša tuneļa adreses. Ja vēlaties, numurējiet saiti no privātās telpas un ievietojiet publisko pakalpojuma adresi tur, kur pakalpojums patiešām darbojas.

Linux klientā, kas pakalpojumu pabeidz lokāli, pietiek ar vienu resursdatora adresi:

ip address add 198.51.100.70/32 dev lo

Ja prefikss tiek maršrutēts tālāk uz VM resursdatoru vai citu LAN, tā vietā konfigurējiet šo lejupstraumes ceļu un tā atgriešanās maršrutu. Katras bloka adreses piešķiršana VPN klientam nav nepieciešama un vēlāk rada konfliktus.

Saglabājiet publisko avotu atgriešanās ceļā

Atbildei no deleģētā prefiksa jāiziet caur tuneli un jāsasniedz sniedzēja maršruts. Ja attālais resursdators to sūta caur savu ISP, avota adrese izskatās viltota, un sniedzējs vai galamērķis to izmet. Risinājums ir uz avotu balstīts noteikums vai atsevišķa maršrutēšanas tabula, nevis plašāks NAT. Bez tā pakalpojums darbojas no tuneļa partnera un neizdodas no jebkuras citas vietas.

Ieejas serverī plašs masquerade noteikums ir ierastais vaininieks. Tas pārraksta publisko avotu uz servera galveno adresi, un klients nekad neredz īsto:

iptables -t nat -S POSTROUTING

Ierobežojiet NAT ar tiem privātajiem VPN klientiem, kuriem tas nepieciešams, un atstājiet deleģēto prefiksu neiztulkotu. Pēc tam pārliecinieties, ka serveris vispār pārsūta prefiksu, jo pārsūtīšanas ķēde ar noklusējuma aizliegumu to klusi izmet.

Pārbaudiet abus virzienus, pirms tam uzticaties

Pārbaude ir četri novērojumi, nevis viens. Pārliecinieties, ka ierodas sniedzēja maršruts, kodols sūta prefiksu tunelī, OpenVPN to attiecina uz pareizo klientu, un atbilde atgriežas ar nebojātu publisko avotu. Katram novērojumam ir sava komanda, tāpēc kļūme norāda uz slāni, nevis visu dizainu. Izpildiet tos šajā secībā pēc katras konfigurācijas izmaiņas.

Jautājiet kodolam, kuru ceļu izvēlas deleģētā adrese, un novērojiet tuneli, kamēr notiek pieprasījums:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Apgrieztā ceļa filtrēšana var atcelt pareizu maršrutu. Pārbaudiet efektīvo iestatījumu tunelī un uplink, un atcerieties, ka stingrais režīms noraida datplūsmu, kuras avots neatbilst saskarnei, pa kuru tā ieradās:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Visbeidzot, pārbaudiet kļūmes gadījumu. Apturiet tuneli un pārliecinieties, ka publiskais prefikss neizplūst pa parasto uplink. VPN atjaunošanai jāatgriež pakalpojums, nepaplašinot, kuras ostas resursdators atver.