Dalje e ndarë: pishina VPN në usb0, trafiku i portës në eth0

Klientët lidhen dhe autentifikohen, pastaj trafiku i tyre del nga lidhja e sipërme e gabuar, sepse rruga e vetme e parazgjedhur në makinë i përket vetë portës. Zëvendësimi i asaj rruge të parazgjedhur do të prishte përditësimet e makinës dhe aksesin e menaxhimit, prandaj përzgjedhja duhet të jetë më e ngushtë se «i gjithë trafiku». Forma e zbatueshme është një rregull politike i bazuar në adresën e brendshme burimore të pishinës së klientëve, që tregon një tabelë të dytë rrugëtimi që zotëron WAN-in alternativ. Prej andej lista e kontrollit ka të bëjë me plotësinë dhe sjelljen në dështim, jo me vetë rregullin.

Konfirmoni që adresa burimore mbijeton deri në vendimin e rrugëtimit

Një rregull politike që përputhet me një interval burimor aktivizohet vetëm kur paketa ende e mban atë burim në momentin e kërkimit. Trafiku i klientëve i përcjellë e bën këtë, për sa kohë që asgjë më lart nuk e ka rishkruar para rrugëtimit. Trafiku që gjeneron vetë porta nuk e bën, dhe pikërisht për këtë rruga e saj e parazgjedhur mund të mbetet aty ku është.

Këtu testet lokale mashtrojnë. Një curl i ekzekutuar në portë është një rrjedhë e krijuar lokalisht me adresën e portës, prandaj merr tabelën kryesore dhe nuk provon asgjë për rrugën e klientit. Testoni nga një klient i lidhur, ose gjeneroni trafik me një burim që i përket vërtet pishinës.

Filloni duke shkruar vlerat reale: prefiksin e pishinës, ndërfaqen e tunelit që e transporton, adresën dhe hapin tjetër të WAN-it të dytë, dhe numrin e tabelës që synoni të përdorni. Pastroni rregullat e vjetra nga çdo përpjekje e mëparshme përpara se të shtoni të reja, sepse rregullat e dyfishuara në prioritete të ndryshme prodhojnë dështime që duken të rastësishme.

Ndërtoni një tabelë të zgjedhur që është e plotë

Një tabelë nuk është një rrugë e parazgjedhur me një shok. I duhen mjaft rrugë që çdo kërkim të zgjidhet brenda saj, përfshirë rrugën e lidhur për nënrrjetin WAN që hapi tjetër të jetë i arritshëm. Për një pishinë 10.77.0.0/24 në tun1, një adresë WAN 203.0.113.20/24 me hap tjetër 203.0.113.1, dhe tabelën 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

Rregulli qëndron në një prioritet nën çdo rregull ekzistues që kap gjithçka, prandaj klientët që përputhen godasin fillimisht tabelën 600 dhe çdo gjë tjetër bie në tabelën kryesore. Referenca e ip-rule përshkruan plotësisht modelin e kërkimit të renditur dhe sintaksën e përzgjedhësit.

Pastaj mendoni për atë që tabela nuk përmban. Një destinacion që ka rrugë vetëm në tabelën kryesore, si një nënrrjet menaxhimi i arritshëm përmes eth0, nuk do të gjendet në tabelën 600 dhe nuk do të kthehet në kryesoren pasi atje të ekzistojë një rrugë e parazgjedhur. Nëse ato shtigje kanë rëndësi, shtojini ato në mënyrë eksplicite tabelës së zgjedhur, që zakonisht është përgjigjja e saktë për një tabelë daljeje VPN.

Mbani trafikun e vetë dëgjuesit jashtë politikës

Dëgjuesi i OpenVPN ka lidhjen e vet të jashtme, të transportuar përgjatë lidhjes së sipërme me të cilën klienti e arriti. Ai trafik duhet të mbajë rrugën e kthimit me të cilën erdhi, dhe një rregull i gjerë që mbulon adresën publike të serverit ose të gjithë ndërfaqen e tunelit mund ta tërheqë në tabelën alternative. Kufizoni rregullin në pishinën e brendshme dhe asgjë tjetër.

Filtrimi i rrugës së kthimit meriton një vështrim për të njëjtën arsye. Kur përgjigjet ndaj klientëve dalin përmes usb0 ndërsa kërkesa erdhi përmes një lidhjeje tjetër, një cilësim i rreptë rp_filter mund të hedhë poshtë paketa që politika e rrugëtimit i konsideron të vlefshme. Kontrolloni vlerat efektive të sysctl në të dyja ndërfaqet përpara se të përfundoni që rregulli dështoi.

Rendi ka rëndësi edhe në raport me çdo gjë tjetër në makinë. Urat Docker, një VPN i dytë dhe çdo rregull paraekzistues nga një imazh ofruesi shtojnë prioritete, prandaj lexoni listën e plotë të rregullave në vend që të supozoni se prioriteti 100 është i vetëm.

Bëni që përcjellja dhe përkthimi të përputhen me rrugën

Rrugëtimi zgjedh një lidhje të sipërme; nuk jep leje për përcjellje. Kernel-i duhet të ketë të aktivizuar përcjelljen IPv4, dhe muri i zjarrit duhet të pranojë drejtimin nga klienti në WAN dhe trafikun e kthimit. Një tabelë e saktë me një zinxhir FORWARD që hedh poshtë rrjedhën prodhon të njëjtin simptom si një rrugë që mungon, prandaj të dyja kontrollohen në të njëjtin kalim.

Nëse WAN-i i dytë nuk do të rrugëtojë një pishinë private përsëri drejt jush, përktheni burimin në atë dalje. Për një ndërfaqe me adresë dinamike, zgjedhja e zakonshme është një rregull masquerade i ngushtë i kufizuar në pishinë dhe ndërfaqe:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Këtu shtrirja ka më shumë rëndësi se caku. Një rregull masquerade që përputhet me çdo ndërfaqe dalëse do të rishkruajë edhe trafikun që del saktë përmes eth0, dhe kjo i fsheh gabimet e rrugëtimit në vend që t'i rregullojë. Përkthimi ekzekutohet pas vendimit të rrugëtimit, prandaj nuk mund të rregullojë kurrë një paketë të dërguar në lidhjen e sipërme të gabuar.

Edhe kostoja e tunelit kërkon vëmendje kur shtigjet ndryshojnë. Nëse klientët negociojnë një MSS TCP të madh dhe WAN-i alternativ ka MTU më të ulët ose një tunel brenda, segmentet e mëdha ngecin ndërsa të voglat punojnë. Kufizimi i MSS në shtegun e përcjelljes e kthen atë në sjellje të parashikueshme në vend të një ngecjeje të herëpashershme.

Vendosni çfarë ndodh kur usb0 zhduket

Një tabelë bosh nuk është gjendje që mbyllet në dështim. Nëse rruga që përputhet zhduket, kërkimi vazhdon te rregulli tjetër, arrin tabelën kryesore dhe merr rrugën e parazgjedhur të eth0. Trafiku që duhej të dilte përmes WAN-it të dytë del në heshtje përmes të parit, që në një vendosje me rrugëtim sipas politikës është zakonisht rezultati që dëshironi më së paku.

Aty ku ky kthim pas është i papranueshëm, shtoni një rrugë terminale të qartë në tabelën 600, si një rrugë e parazgjedhur blackhole, ose hidhni pishinën në murin e zjarrit ndërsa ndërfaqja është e fikur. Secila prej tyre është një vendim që mund ta shkruani; heshtja nuk është.

Këmbëngulja është pika e fundit. Kushdo që zotëron të dyja lidhjet, qoftë menaxheri i rrjetit, një skript dërguesi apo cikli i jetës së lidhjes, duhet të rikrijojë rrugët dhe rregullin në çdo rilidhje pa shtuar dublikata. Verifikoni me një kërkesë nga një klient real dhe një kërkesë të veçantë nga porta, konfirmoni daljen e vëzhguar në të dyja, pastaj hiqni WAN-in e dytë dhe shikoni cili nga dy rezultatet që keni projektuar ndodh vërtet. IPv6 kërkon tabelën, rregullin dhe përkthimin e vet; rregulli IPv4 më sipër nuk thotë asgjë për të.