OpenVPN GCE: pievienojiet alias IP pirms maršrutu push

Push maršruts nepadara VM par next hop. Pievienojiet alias IP diapazonu, saskaņojiet to ar servera pool un izveidojiet VPC atgriešanās maršrutu pirms klientu testēšanas.

Klients zvana uz OpenVPN serveri Compute Engine VM, statusa logs rāda savienots, un ping uz resursdatoru VPC iekšienē joprojām nekur nenonāk. Instinkts ir pievienot vēl vienu push rindu, un tas nekad to neizlabo. Compute Engine izlemj, kur paketes dodas, pamatojoties uz savu maršrutu tabulu un adresēm, kas VM saskarnei faktiski ir, tāpēc tuneļa pool, kas VM nepieder, ir pool, uz kuru neviens nepiegādā.

Sekojiet neveiksmīgajai pakei, nevis konfigurācijas failam, un trūkstošās daļas parādīsies secībā.

Sāciet ar pakei, kas mirst

SYN atstāj klientu, nonāk tunelī un sasniedz VM kā iekapsulēta pakete uz galamērķi VPC iekšienē. OpenVPN to atkapsulē un mēģina pārsūtīt pa eth0, kur fabric pirms visa cita uzdod vienu jautājumu: vai šī instance pieder galamērķa adresei. Tuneļa pool, kas izgriezts no kāda cita apakštīkla, izgāžas šajā jautājumā, un pakete tiek izmesta pirms jebkura maršruta vai ugunsmūra noteikuma izskatīšanas.

Tātad virzienam no klienta uz VPC ir divas atsevišķas prasības, un neviena no tām nav push direktīva. VM ir vajadzīgs alias diapazons, kas aptver tuneļa pool, un tas ir tas, kas to padara par likumīgu šo adrešu īpašnieku. VPC ir vajadzīgs maršruts, kas nosauc VM kā next hop katram aizsargātajam prefiksam. Ja trūkst viena, pakete mirst citā vietā, kamēr klients redz to pašu klusumu.

Lasiet kļūmi šajā secībā, jo no klienta puses abi nosacījumi izskatās identiski. Tunelis, kas ziņo par savienojumu, kamēr nekas neatbild, ir topoloģijas problēmas pazīme, nevis slikta šifra pazīme.

Vai instance pieder tuneļa pool

Piešķiriet VM sekundāru diapazonu tā paša apakštīklā, pēc tam lieciet OpenVPN izsniegt adreses tieši no šī diapazona. Instancē, kuras primārā adrese ir 10.156.0.10/20, /28 alias atdala pool no adresēm, kas citām instancēm jau ir:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

Server direktīvai tad jāapraksta tas pats bloks. Tās pirmā adrese kļūst par tuneļa gateway, un pārējās adreses tiek izsniegtas klientiem. Šeit divi skaitļi apraksta vienu bloku, tīklu un tīkla masku, un tā ir pool sintakse, ko OpenVPN joprojām gaida.

server 10.156.1.0 255.255.255.240

Apstipriniet, ka adrese patiešām nonāca saskarnē, nevis tikai OpenVPN konfigurācijā. Fabric pārsūta to, ko ziņo NIC, nevis to, kam tic daemon. Viena komanda to izšķir:

ip -4 addr show dev eth0

Sekundāra adrese, kas nekad nesasniedz eth0, vai pool, kas pārklājas ar citu apakštīklu, vēlāk izpaužas kā periodiski zudumi, nevis kā starta kļūda. Daemons startē, klienti savienojas, un tikai daži galamērķi uzvedas nepareizi. Turiet alias diapazonu mazu, lai pool būtu viegli atpazīt maršrutu tabulā. Nekad neizgrieziet to no apakštīkla, ko cita instance jau izmanto.

Piešķiriet atgriešanās trafikam next hop

Atbilde no VPC resursdatora ir adresēta klienta adresei tuneļa pool, kas nepieder nevienam VPC zināmam apakštīklam. Bez maršruta uz šo pool atbilde apstājas pirmajā hop, kuram nav atbilstības, un pieprasījums var būt pilnīgi veiksmīgi izpildīts otrā galā.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

Tas pats maršruts ir vajadzīgs katram prefiksam, kas atrodas aiz klienta, nevis VPC iekšienē. Šiem prefiksiem ir vajadzīgs arī iroute ieraksts tā klienta ccd failā. Šis ieraksts ir servera puses uzskaite: tas pasaka serverim, kurš klients pieder prefiksam, un tas neko neinstalē pašā klientā.

Turiet push sarakstu sarunas klienta pusei, jo tas tikai pievieno maršrutus savienojošajai mašīnai. Push rinda VPC apakštīklam un VPC maršruts atpakaļ uz pool ir divas viena ceļa puses, un katra puse viena pati rada tuneli, kas nes pieprasījumus, bet ne atbildes.

Ugunsmūri, pārsūtīšana un starp tiem esošie hopi

VPC ugunsmūris novērtē atkapsulēto pakei, tāpēc ingress noteikumam ir jāielaiž tuneļa pool un jebkurš vietnes prefikss, kas šādā veidā sasniedz VM. Default-deny nostāja šeit klusi izgāžas: pakete tiek izmesta pēc atkapsulēšanas, un OpenVPN žurnāls rāda veselīgu sesiju.

Jebkurā Linux resursdatorā, kas pārsūta, nevis terminē, pārbaudiet, vai net.ipv4.ip_forward ir iespējots. Īpašumtiesību noteikums attiecas arī tur: mašīna, kas pārsūta apakštīklam, kura tai nav, izmet pakei tāpat kā VM. Izlasiet vērtību pirms tuneli vainošanas.

Kad neizdodas tieši viens prefikss

Daļēja kļūme ir visvieglāk lasāmais gadījums, jo viss pārējais ceļā jau ir pierādīts. Sāciet ar maršrutu sarakstu un izlasiet tā ieraksta galamērķa diapazonu un next hop, kam vajadzētu aptvert prefiksu, pēc tam izlasiet instances aprakstu un salīdziniet tā alias diapazonu ar pool, ko izsniedz serveris.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

Trūkstošs maršruts izpaužas kā next hop neesamība prefiksam, bet trūkstošs alias izpaužas kā saskarnē izmesta pakete; no klienta puses abi izskatās līdzīgi, un šajos divos izvados tie ir pilnīgi atšķirīgi. Ja ir abi, atlikušais aizdomās turamais ir tā klienta ccd iroute, kas pretendē uz prefiksu.

Pierakstiet četras vērtības blakus tunelim: alias diapazons, servera pool, push prefiksi, VPC maršruti. Novecojis alias salauž katru pool adresi, novecojis maršruts salauž vienu virzienu, trūkstošs push paslēpj prefiksu no klienta, un nepareizs iroute nosūta prefiksu nepareizajam peer. Nākamajai personai, kas pievienos apakštīklu, vajag visus četrus vienā vietā, un piezīme ir lētāka par vakaru.

Saistītie raksti