Pokrećete VPN klijent preko SSH-a? Prvo fiksirajte vlastitu rutu

Priključite se SSH-om na build host, pokrenete na njemu VPN klijent i sesija prestane odgovarati. Ništa nije palo i ništa ne izgleda pogrešno konfigurirano na očit način. Klijent je instalirao zadanu rutu, pa odgovori prema vašoj radnoj stanici sada izlaze kroz tunel, gdje adresa vaše radne stanice nije usmjeriva. Zanimljiv je dio da je taj ishod bio predvidljiv, a popravak je jedna ruta zapisana prije nego klijent krene. Pretpostavimo poslužitelj s jednim mrežnim adapterom, gateway 192.0.2.254 i administratora koji se spaja s 203.0.113.9.

Zapišite put prije početka

ip route show default navodi trenutni gateway i sučelje, dok ip route get 203.0.113.9 pokazuje koje bi sučelje i izvornu adresu kernel koristio za vašu sesiju. Sačuvajte oba izlaza. Nakon što tunel krene, te dvije naredbe trebale bi i dalje opisivati fizički put, a ako opisuju tunel umjesto toga, sesija već živi na posuđenom vremenu.

Uspostavljena veza je ono što je važno, zato ne provjeravajte samo novom prijavom. Nova sesija može nakratko uspjeti kroz stanje koje stara više nema.

Fiksirajte adresu u vlastitoj konfiguraciji klijenta

Ruta dodana rukom nestaje nakon ponovnog pokretanja i utrkuje se s klijentovim vlastitim ažuriranjima tablice, zato stavite iznimku tamo gdje se tablicom upravlja. Pod OpenVPN ključna riječ net_gateway razrješava se u gateway koji je postojao prije tunela, pa route 203.0.113.9 255.255.255.255 net_gateway zadržava točno jednu adresu izvan njega. WireGuard zahtijeva drukčiji pristup jer wg-quick sam upravlja rutama: postavite Table = off i dodajte iznimku u PostUp, uz odgovarajući PostDown koji je uklanja. Oba oblika izražavaju istu namjeru i oba ograničavaju iznimku na jednu adresu umjesto da oslabe tunel za sve.

Za IPv6 ista ideja uzima prefiks jednog hosta, a slučaj omotanog transporta vrijedi zapamtiti: ako vanjska veza samog tunela živi na fiksnoj adresi, ta adresa mora ostati izvan tunela koji nosi, inače klijent usmjerava vlastiti transport u sebe.

Ili izbacite glavnu tablicu iz rasprave

Kada nekoliko usluga na hostu mora zadržati svoj uobičajeni put, prestanite uređivati glavnu tablicu i dajte klijentu njegovu vlastitu. Mrežni namespace s parom veth to radi čisto: klijentova zadana ruta živi u drugom stogu i samo procesi pokrenuti unutar njega koriste tunel. Policy routing dolazi na slično mjesto za jedno odredište, šaljući odgovarajući promet u namjensku tablicu čija zadana ruta još pokazuje na fizički gateway. Svaki od pristupa ostavlja glavnu tablicu hosta bez nove zadane rute, a upravo to svojstvo održava SSH u stanju da odgovara.

Oba su više mehanizama od jedne rute do hosta i oba vrijede kada više od jedne stvari na stroju mora preživjeti tunel.

Pretpostavite da fiksiranje može propasti

Ruta vezana za vašu trenutnu javnu adresu puca onog trenutka kada je vaš davatelj ponovno dodijeli. Udaljeni poslužitelj tada treba put koji ne ovisi o toj adresi: konzolu, drugo upravljačko sučelje ili jump host koji ostaje izvan tunela.

Dvije mjere zaštite koštaju deset minuta. Watchdog koji zaustavi klijent ako potvrdna prijava ne dođe u nekoliko minuta pretvara zaključavanje u odgodu, a druga SSH sesija držana otvorenom tijekom promjene dokazuje da iznimka radi dok je tunel gore. Sami keepalive ovdje ne pomažu, jer je put otišao, a ne miruje; oni samo olakšavaju primijetiti smrt.

Provjerite redom koji je važan

Spojite tunel, potvrdite da ruta do vaše adrese još izlazi kroz fizički gateway, zatim otvorite novu sesiju. Ako nova sesija radi, a stara ipak umre, uzrok je praćenje veza ili stateful firewall, a ne routing, što je drugačiji popravak.

Zapišite fiksiranu adresu i naredbu koja ju je dokazala u zapis o promjenama. Sljedećoj osobi koja pokrene klijent na tom hostu trebat će oboje, a adresa se do tada možda promijenila.